php 5.2.14 drew blood

Hi, I've resisted upgrading to php 5.2.x because of the implications and potential challenges of going to the "bleeding edge." However, my case for doing so has been mounting for some time, so I just recently attempted it. I followed the instructions listed here:,virtualmin_bleeding_edge_pack... and then used the install package updates feature on the System Information page. The upgrade seemed to go just fine. The sys info reported the newer version, and VirtualMin was clearly still working without a hitch. However, both of my php websites (driven by a CMS called Concrete5) started to misbehave. The CMS would give me page not found responses when I tried to access the home page of a given site. I had also installed the latest version of phpMyAdmin, and while I could access the login page, once I logged in, I would get a "The requested URL /cgi-bin/index.php was not found on this server." error. I noticed the file path it complained about. It clearly didn't mention any part of /public_html/phpMyAdmin.

I have since used a backup to revert to a previous state, but at this moment, my life would be much simpler if I could just get php 5.2.14 installed AND have my php sites working properly. I realize that accessing the bleeding edge repos is likely outside of the support agreement, but I have to ask if you have any ideas, or if there are any resources I can access to make this work. I've already invested way to many hours in trying to resolve a snowballing issue.

Thanks for your time.

  • jalen.


Howdy -- yeah, not all PHP applications work with every PHP version or mode of operation. Determining what does and doesn't work is dependent on the application you're running, and may require some trial and error.

One thing you may want to try is to set "cgi.fix_pathinfo=0" in your $HOME/etc/php.ini file. In PHP 5.2.10+, that does fix some issues that arise, especially issues like you described above.

Outside of that -- one thing you might consider is setting up a test server in a Virtual Machine somewhere. I run the free "VirtualBox" on my desktop, for example. That would allow you to test things such as this, without any concern of it being a live server. Once you get things working, you'd know exactly what changes had to be made on the live server.

Thanks for your idea. I tried it and it didn't fix the problem. The interesting thing is that I know that the CMS is compatible with 5.2.x, because the installation script indicates that php 5.2.x is preferred. Also, I can run a hand written script from a specific URL within the same domain. Yet both Concrete5 and phpMyAdmin are not wanting to work.

Do you have any other ideas as to how I can diagnose the problem. I've tried looking at the access logs (for errors, or to see what the offending url is).

While the application may support PHP 5.2.14, it may be having trouble with the specific mode it's running under.

That is, it's possible that running in CGI mode could cause problems, and mod_php may work perfectly -- or vice-versa.

While you do lose some security benefits in doing this, you may want to see if mod_php works correctly for you.

Sorry for my ignorance, but how would I switch between these modes (CGI vs. mod_php) to see if one of them works?

You'll want Server Configuration -> Website Options : PHP script execution mode. :)

Oh... duh! And here I was thinking I'd need to dig into etc/php.ini...


That did the trick! Yay! Thanks so much.

  • jalen.