Search results

Confirmed. Thanks!

Well it has been a while and we still need this to deploy PHP 5.6. It's not like the version was a surprise, it could have been added long ago. Any idea when the next release will be?

Replacing the PHP 5.4 bundled *.c and *.h files with those in the 6.2 download works without issue. Thanks.

As has already been discussed elsewhere on these forums and in this thread, the LSAPI (6.2) provided for download on your website does not work with PHP 5.4. It does work fine for PHP 5.3. The bundled LSAPI with PHP 5.4 works fine but that is only version 5.5. Edit: I do see now that you...

They simply need to provide download links for the latest version of LSAPI that is compatible with PHP 5.4, just as they do for PHP 5.3. This really isn't asking much. Having to go through their web console, build PHP, and then grab the files from their build directory shouldn't be necessary.

[solved] We really need a version of LSAPI that we can use to manually compile PHP 5.4 with. Not everyone wants to use the web console to compile their PHP.

Agreed. This continues to be an issue which needs some sort of permanent resolution. Ideally it would be nice if we could configure the suexec capable extensions. Otherwise at the very least we would need: php52 php53 php54 But even then more would need to be added in a timely fashion as...

Thanks for the update foliovision. I can confirm that the updated 4.1.5 addressed the restarts. Now on to testing and hoping that 4.1.6 doesn't have any more problems.

We did a force re-install on our servers to address this bug and we immediately started getting a bunch of unexpected signal 11 notices. We've reverted to 4.1.4 in the mean time. Anyone else?

Perfect. Works like a charm. Thanks!

Thanks, that helped me narrow down this issue. The --with-libxml-dir=/opt/xml2 doesn't seem to be working as one might expect. ldd reports /usr/lib64/libxml2.so.2. Using your build matching PHP from the WHM plugin doesn't have this issue, ldd reports /opt/xml2/lib/libxml2.so. Even a fresh...

I'm still trying to identify where in the code exactly the PHP scripts are dieing but a simple example that does not work is phpSysInfo using disp=static in the URL (it defaults to disp=dynamic if you have java script enabled).

That's exactly the problem. If you use what cPanel creates, which is now libxml 2.7.8, any script attempting to uses xsl does not work under LiteSpeed as noted. The only work around is to manually build libxml 2.7.7 and rebuild libxslt using this older libxml.

With PHP (5.2.17 and 5.3.8) built for LiteSpeed using libxml 2.7.8 and libxslt 1.2.6, scripts attempting to use the XSL support display a 503 forbidden error page. The following shows up in stderr.log: 2011-10-10 13:41:17.711 [STDERR] lsphp5test:<snip>: symbol lookup error...

We've actually gotten more of these with 4.1.4 whereas we didn't have an issue with the latest 4.1.3. So far 4.1.4 has just been a big lose with this and the SSI issues. Edit: Now see that the OP is using 4.1. Regardless, I'd be weary of 4.1.4 being an improvement. Go 4.1.3 IMO.

This is ridiculous. Why must you repeatedly break SSI functionality. Now include file is exhibiting this very same behavior on 4.1.4. Switching back to the updated 4.1.3 resolves this.

Fixed indeed. Thanks.

This is driving me nuts. Why can't we keep something as simple as SSI working between updates? 4.1.3 breaks multiple include virtuals. For example in a single page our client had: <!--#include virtual="includes/nav.shtml" --> <!--#include virtual="includes/services_nav.shtml" -->...

This bug still exists as described in my reply immediately above. Yet another customer discovered it on their site and I've confirmed it as well.

Great, thanks!