• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Sitebuilder Showing Blank....

O

osmoswebnow

Guest
Dear SIB

Thank you for the prev post ... I would like to try it ... but till then --> *sigh*

Before I could read it, I tried upgrading my libxml2 library and compiled php for the published site. There was nothing done with php for sitebuilder.

Now when I go to my sitebuilder page at http://66.197.244.25 it shows blank. When I run, phpinfo and check.php on that server, it renders correctly.

Why is the site builder not rendering the pages..?

me :(
 
I have checked the sitebuilder_error LOG file and here are the last few lines of the file:
PHP Warning: XSLTProcessor::importStylesheet() [<a href='function.XSLTProcessor-importStylesheet'>function.XSLTProcessor-importStylesheet</a>]: Attribute template onclick: failed to compile $action in /usr/local/sitebuilder/include/SB/XMLView.php on line 96
PHP Warning: XSLTProcessor::importStylesheet() [<a href='function.XSLTProcessor-importStylesheet'>function.XSLTProcessor-importStylesheet</a>]: Undefined variable in /usr/local/sitebuilder/include/SB/XMLView.php on line 96
PHP Warning: XSLTProcessor::importStylesheet() [<a href='function.XSLTProcessor-importStylesheet'>function.XSLTProcessor-importStylesheet</a>]: compilation error: file /usr/local/sitebuilder/resources/styles/GUI/Controls.xsl line 455 element td in /usr/local/sitebuilder/include/SB/XMLView.php on line 96
PHP Warning: XSLTProcessor::importStylesheet() [<a href='function.XSLTProcessor-importStylesheet'>function.XSLTProcessor-importStylesheet</a>]: Attribute template class: failed to compile $titleClass in /usr/local/sitebuilder/include/SB/XMLView.php on line 96
PHP Warning: Unknown: No stylesheet associated to this object in /usr/local/sitebuilder/include/SB/XMLView.php on line 113
PHP Fatal error: Method SB_Views_Wizard_Overview::__toString() must return a string value in /usr/local/sitebuilder/htdocs/index.php on line 49


I am unable to figure out what is the actual problem that is causing this. Your help will be highly appreciated Sir!
 
The check.php on the sitebuilder php gives perfect result. Here is the result when I run the script:

OK : supported version of PHP found (5.1.X or newer)
OK : extension sitebuilder3 in state on found
OK : extension pdo in state on found
OK : extension pdo_mysql in state on found
OK : extension sqlite in state on found
OK : extension dom in state on found
OK : extension libxml in state on found
OK : extension xml in state on found
OK : extension xsl in state on found
OK : extension spl in state on found
OK : extension pcre in state on found
OK : extension session in state on found
OK : extension simplexml in state on found
OK : extension ftp in state on found
OK : extension openssl in state on found
OK : extension mbstring in state on found
OK : extension soap in state on found
OK : extension gd in state on found
OK : extension ctype in state on found
OK : extension zlib in state on found
OK : extension curl in state on found
OK : extension mysql in state on found
OK : setting magic_quotes_gpc in state off found
OK : setting magic_quotes_runtime in state off found
OK : setting open_basedir in state off found
OK : setting safe_mode in state off found
OK : setting zend.ze1_compatibility_mode in state off found
OK : supported SQLite version 2.x found
OK : SQLite UTF-8 encoding found
OK : GD library PNG support found
OK : GD library GIF support found
OK : GD library JPG support found
OK : GD library WBMP support found
OK : supported GD library version 2.0.1 (or newer) found


Unable to get any idea on what's the cause ...?
 
The place for published sites and SB location is the same?
We had already seen some strange problems as described in your comment with libxml & libxslt (primary on FC2 and CentOS). And these problems in most cases are because of bugs in libxml. I can only suggest you to downgrate libxml (down to working version).
 
Thnks for your reply sir!

Sitebuilder is using PHP installed by sitebuilder installation team. The phpinfo for it could be found at:
http://66.197.244.25/phpinfo.php

The Published sites are using the initial PHP we had on server. Its PHPinfo can be found at:
http://osmosweb.com/phpinfo.php

And osmosweb is the published site before this blankout took place Sir!

Can you please check the phpinfo of both the php's and guide me to the best version of libxml I should downgrade to? Also is there any particular way the downgarde should be done so that both the php's pick up the new libraries?

Thnks once again for the help sir..
 
Investigation of http://66.197.244.25/phpinfo.php says thae that you didn't change anything in PHP for SB. That's good. Take a closer look on XSL extension info:
* libxslt Version - 1.1.11
* libxslt compiled against libxml Version - 2.6.16

I see that at http://osmosweb.com/phpinfo.php another info about XSL extension:
* libxslt Version - 1.1.9
* libxslt compiled against libxml Version - 2.6.23

PHP for SB is compiled against shared libxml, libxslt libraries. Don't know how about your PHP for published sites (may be compiled statically).

Try to execute from command line:
> ldd /opt/php51/lib/xsl.so
Take a look on libxml and libxslt libraries in the output.
Than try ldd execute on PHP apache module that is used for published sites. Something like this:
> ldd /usr/local/apache/libexec/libphp5.so
And again take a look on libxml and libxslt libraries in the output (if present).
In the simple case if you see different libraries (and both of them are shared) and assuming that second libraries are normal, so you can make symlinks to normal libs replacing broken ones. Another way can be a downgrate of libxml/libxslt. I cann't say exactly version of libxml cause problems appeared in microversions and depends on many other factors. So only experiments with different versions can help you.

But these are only simple cases. There can be performed many tricks and hacks to make it working. It's not easy thing to really help you only with discussion on the forum. But in the other hand if a one have a root access to your server this task can be performed in an hour (or even in the several minutes). That's why I highly recommend you to contact support.
 
Problem Solved

Hello,

I am happy to report that SWSOFT support has been very helpful in helping me solve various problems.

As per Support, the issues were :

1) Incompatible version of LIBXML for problems that were appearing in the backend

2) Modules were not rendering on the client site, because SQLITE was not compiled with UTF8 ...

Lastly, for all those who do continue to face various issues, I would recommend that you should contact Support. They are extremely helpful, and greatly knowledgeable about various things. The monies involved in fixing these issues, in my case, was pretty small in terms of the business value returned ...

Thanks to all who tried to help on this forum. And to acknowledge the support, we will come back to all here, with a packet of goodies pretty soon.

Cheers, all
Sanjeev Sarma
 
Back
Top