php safe mode at FQ

[jack]

I'm going nuts trying to get a Wordpress plugin working that apparently works fine at other hosting companies (Shopp, and eCommerce plugin). It fails to activate and generates no erros on the php logs, cgi logs, Apache logs -- nada, so we have nothing to go on to debug the problem.

The plugin author's latest straw to grasp is it may have something to do with FG's handling of safe mode. I recall reading somewhere that it is unique to FQ, but can't find any information here or iota.net -- is there a writeup somewhere I can check out and/or pass along to them?

At their request, I recently had php upgraded to php 5, and looking at the php info it looks like my local setting for php safe_mode is off -- am I reading this right?

Jack

[Terra]

Yes, PHP's safe_mode is turned off as it is not needed due to our exclusive PHP SecureMode(TM)... There is a lot of information regarding its functionality within our forums...

Before I go further with any speculation, I will need to know which domain and also the steps required to recreate the problem...

[jack]

I searched the forums for "php safe_mode" but didn't find a description of how it works or how to make use of it.

My domain is highsierradesign.com -- primarily used for test and development.

The problem is when I load the Shopp Wordpress plugin, it loads, is recognised, I can even see its files under the plugin edit feature, but when I click on 'activate', it wanders off and generates a blank page. Other plugins work fine, and supposedly. the Shopp plugin works on other hosting services. I've checked the error logs and come up with nothing...

I have numerous WP sites up and running here, done lots of customization and used many plugins -- occasionally running into some plugin conflicts that were easily resolved, but never had a problem anything like this.

The developers are pulling their hair out as well given the absence of any errors logged, but since they have never seen this problem with any hosting service before, it's getting embarrasing. I'm a terminal fan of FQ, and I'll give up this plugin before I move, but it's become a critiacl requirement now.

Any hints on how to debug this?

Jack

[Terra]

You would search the forums for either SecureMode or Secure_Mode...

This will get you started:
http://www.aota.net/forums/showthread.php?s=&threadid=14277

Please send the admin login details to the Service Desk as I will need access to the 'activate' routine...

[jack]

Thanks, just did.

[Terra]

I was able to get the plugin activated by briefly disabling ZendOptimizer (ZO) in your Apache/PHP engine...

I'm not sure why ZO was segfaulting and there is no easy way to tell due to it being a closed source black box... The segfaulting is why you didn't see any errors, because it crashed before it gets to the logging phase...

At this point, the Shopp plugin was activated... After which I've enabled ZO again, and the Shop links on the front page appear to be working properly... The ZO segfault may only occur during the 'activate' phase, but I won't know that until you start filling the Shopping area with items...

Go ahead and work with it, and let us know if you have any further errors/blank pages...

[jack]

Wow!! Thank, thank you!!!

I guess I need to learn a bit more about ZO -- I'm sure the Shopp authors will be all over this, since they've expressed an interest in making sure it works on FQ. Hopefully, with this information they can track down why they run afoul of ZO when so many others obviously don't.

I really don't want to have to take that step myself, but I'm curious -- can anyone disable/enable ZO other than deities of the Babylon 5 universe such as yourself?

Jack

[Terra]

ZO is loaded via the core PHP configuration (ini) file and can only be done at root level access... It is a dynamic module that binds to the PHP engine, sort of like how a DLL works on Windows or a .so Shared Library works on *nix...

Our ZO version is 3.2.2 and I've found that this version has caused the least amount of problems... We cannot use the 3.3.x series because it is compiled and linked against glibc 2.3.x...

[jack]

Terra,

I've had a request from the Shopp developers for the version number of ZO that is used on my server - they're looking into the problem.

So far, I've exercised a fair number of features in the package with no further problems. Now the question is... how will I install in on the live site, which runs on another server? I can't keep asking you guys to trun ZO off and on for me!

Jack

[Terra]

Now the question is... how will I install in on the live site, which runs on another server? I can't keep asking you guys to turn ZO off and on for me!
I don't mind doing that if it gets it activated and operational... We'll just have to go through the same steps until a permanent fix is found...

I just wish that ZO wasn't closed source, because it has really caused me a lot of grief over the years trying to debug the PHP engine itself... The crash backtraces and breakpoints become useless once the processing path courses its way through ZO...

[jack]

Thanks, that's a pain just for this one plugin... Word from the Shopp developers is they will try to reproduce the problem at their site, but they're not too optimistic about correcting anything by modifying their code, since this is the only instance (and the only hosting service) where they've seen this happening.

Meanwhile, I found a 3 year old bug report on a Zend forum that sounds a bit too familiar: "Major Zend Optimizer 3.2.2 Bug - random segmentation fault causing 404/no output [message #8147]" it at http://www.zend.com/forums/index.php?t=msg&th=2992

Have you had many other problems with ZO like this??

Thanks again... Jack

[Terra]

I'm going to do a quick bump of ZO from 3.2.2 ==> 3.3.0a

Please retest it and let me know if the activation works properly now...

Thanks!

[jack]

Fantastic!!! I deactivated and activated with no problems!!! You're a genius..

Thanks again for staying on top of this...

Jack

[Terra]

That is good to hear!

I had to take a really big hammer to get it to work, and time will tell if I've just traded in one set of ZO problems for another... :)