You could try restarting Apache while tailing /var/log/httpd/error.log. It might give you some clues as to why the Zend Optimizer extension isn’t loading. Also, double check your php.ini file and make sure all the zend paths are correct.
Try stracing php -v and figure out which php.ini file it’s looking at. The webserver always uses /etc/php.ini, whereas the command line php -v usually uses /etc/php-cgi.ini or /etc/php-cli.ini if they exist.
I really doubt it’s an issue with the SRPM, but not impossible.
on the System Services -> Web Server page in NodeWorx? If so, this is the reason:
To generate the content for that popup, we execute “php -i” on the server and use that output. Since we executed “php -i”, that means the php info was run as a CGI script, so it uses /etc/php-cgi.ini.
In order for us to properly use mod_php (which uses /etc/php.ini), we’d have to request a page running on the Apache server running on port 80. Since there is no reliable place for us to put that page, exec’ing “php -i” was the only reliable way to get the phpinfo() contents.
But I’m still a little confused- do I need to keep both updated php-cgi.ini and php.ini updated?
For instance, my test install of Moderbill today looked at php.ini and wanted me to change the memory_limit setting, which I had already done in /etc/php-ini.
If ModernBill uses the php binary for any reason (i.e., a php script it calls from the command line or cronjob), then you will need to update the /etc/php-cgi.ini file. If ModernBill uses mod_php (i.e., a php page served up by Apache), then that would use the /etc/php.ini file.
Without know exactly what all ModernBill does, it would be hard for me to say which php.ini file you should use. You could probably symlink one to the other, if you didn’t care that the php binary would also use the same ini file.