So I know you have probably heard this a million times and I know Joe is on the road and has little bandwidth. You gotta do what you gotta do. I know he has it in the works to update to PHP 5.2.14 or whatever it is. I know you probably don't want to update to 5.3.3 because of incompatibility issues. I also know that you want to stay away from providing packages like this. This is all cool with me.
However, I think it would be great, and maybe even necessary, to have the option to have 5.3.3 for scripts that do require it. I cannot figure out any way to have such an option because I am afraid it will break things. I am not sure I want to try to manually change or update anything this major, especially since it has fcgi and all that jazz built into it. I just don't have time to deal with this sort of stuff and I feel as though having the option to choose the PHP version right inside the control panel should be something that should naturally be available on a server these days.
Would it be possible to somehow have an option in Virtualmin that gives the user, and optionally we could limit this choice to only admins or resellers, the ability to choose which PHP version runs on a Virtual Server? And also, what about MySQL, Apache, etc. Is there even some way to run multiple versions of those on the same server? Would such an option even be required when switching PHP versions?
Otherwise, what about making a true bleeding edge repo? Something that could have PHP 5.3.3 and MySQL 5.1 or 5.5 or whatever works properly together and the latest Apache, or whatever other packages are necessary when using these updated true bleeding edge packages.
Or is it even possible to use Fedora packages on CentOS? Because my Fedora is running PHP 5.3.3, MySQL 5.1.50 and Apache 2.2.16.
Either way, I really wish there was a simple, reliable, compatible way to be able to at least run PHP 5.3.x on my server. Having the ability to switch versions on a site to site basis would be also ideal but I think it is probably easier and better to make PHP 5.2 scripts work with PHP 5.3 than it is to make PHP 5.3 scripts compatible with 5.2.
What are your thoughts?
Ryan
Comments
What applications require 5.3 but don't work with 5.2.x?
Submitted by rrhode on Fri, 10/08/2010 - 15:38 Comment #2
Well I am sure there are some out there by now and I would imagine there will soon be a whole lot more of them. Don't you think so?
But specifically when I am developing applications I want to run on my Virtualmin server I am finding it harder and more time consuming to try to make them run in 5.2 and they seem to just work in 5.3. More specifically at the moment I am trying to send an object to a class in an external file in a Joomla template and it is not working for me. It is stripping off some objects within the object but it works perfectly fine in 5.3.3. I am sure I will figure it out eventually but that is just an example.
When I have modified 5.2 code to run in PHP 5.3 on my test machine it hasn't been very hard to do at all. Of course there are applications out there somewhere that require 5.3 to run but I don't know of any specifically that I use. Or anything that would be installed by Virtualmin yet. I am just saying, wouldn't it be a good idea to have an option to be able to switch between versions? If it's possible, why can't it be an option? There are so many other options in Virtualmin I don't know why an extremely useful option like this doesn't exist already. Is it just too time consuming to make? Is it just not worth the effort?
There is actually already code in Virtualmin for handling version selection (to switch between version 4 and 5, from back when there were still applications that needed 4).
But, packaging multiple versions of PHP 5 for simultaneous installation would be a nightmare, and I can't think of any benefits to doing so for the vast majority of our users (the reason the bleeding edge repo exists is primarily for one application in our Install Scripts: Magento requires 5.2+, and nothing else does). The number of apps that even works with 5.3 is not particularly huge; and I'm unaware of any that require 5.3 at this point. I won't have a problem with bumping to 5.3, once most of the applications in our Install Scripts work with it (especially the big/popular ones). At the moment, I believe there are still a few big ones that would balk at having 5.3, but I haven't looked in a couple of weeks, so things may have gotten better. Since we can't fix the applications that don't work with PHP 5.3, we have to provide a version that works with as much of our Install Scripts as possible.
In short: I'm all for going to 5.3 in bleed. But, we need to confirm that all of the major apps run unmodified and without any known issues on that version (the really big ones are: Wordpress, Drupal, Joomla, Magento, Mambo, phpMyAdmin, MediaWiki...probably a few others). If you'd like to help us track down whether those have all been updated (usually finding the changelog entries where they claim compatibility is enough, though I want to test a bit, too), that'd speed things along. ;-)
Submitted by rrhode on Fri, 10/08/2010 - 14:48 Comment #4
Oh I see, that makes sense then. Well I don't like nightmares and I don't know very many people who do, though I am sure some do.
I would love to help test though. It seems to be a specialty of mine to find anything that has a remote possibility of being broken and break it unintentionally. I would love to try and break some things intentionally for once.
Joomla
I know for a fact that Joomla works fine in 5.3. I am using it as we speak and I remember when it didn't work in 5.3.
Changelog entries:
16-Sept-2009 # [#18008] Additional PHP 5.3 Issues
11-Sept-2009 # [#17150] Patch to solve PHP 5.3 issues
Drupal
Drupal also works fine when I installed it in 5.3.3.
Changelog entries:
Drupal 6.17, 2010-06-02 - Better PHP 5.3 and PHP 4 compatibility
Drupal 6.14, 2009-09-16 - Added support for PHP 5.3.0 out of the box.
I can't even find the Wordpress changelog for its latest version.
Magento Support was added in 1.4 alpha2 http://www.magentocommerce.com/boards/viewthread/68572/#t196262
Mambo Who uses Mambo anymore anyway? Last commit on their SVN from 10 months ago says # more work fixing fs#461 running Mambo on PHP 5.3.
phpMyAdmin I have been using 3.3.7 on PHP 5.3.3 and it has been working fine.
Changelog Entries: - bug #3027557 [PHP] split() deprecated in PHP 5.3 (backport fixes from master)
MediaWiki
Changelog Entries: (bug 18170) Fixed a PHP warning in Parser::preSaveTransform() in PHP 5.3 (bug 20296) Fixed an PHP warning in Language::getMagic() in PHP 5.3
The thing is, even if all these do work with 5.3, some of the modules/extensions/plugins will still need updating. That is going to be the big problem I think. That is usually the problem I am finding. However, I also notice that generally there are patches or posts available explaining how to update them if they don't work.
Submitted by bigwombat on Fri, 10/08/2010 - 14:53 Comment #5
Yes, Drupal core supports PHP 5.3. However, a "large percentage" of the community modules do not. So the general consensus is to deploy using PHP 5.2 unless you are using a limited set of modules which support PHP 5.3.
bigwombat brings up a good point (and one that some other users have expressed concerns over in the past when I've talked to them about bumping to 5.3; this is not the first ticket discussing 5.3, BTW). It concerns me, directly, since we use the bleed packages on Virtualmin.com...and we run Drupal with a ton of modules. I'm guessing the state of Joomla modules is roughly the same.
As an aside, Mambo is actually more popular than you'd think. Not as popular as Joomla, by any means, but it's definitely not an obscure or niche CMS, and we have several pretty heavy users among our customer-base (Mambo's original creator is also a long-time Virtualmin user). So, it would be good to make sure Mambo and modules aren't going to break by bumping bleed up to 5.3.
But, it's actually looking reasonably promising. The core of all of the big applications look pretty good, and module authors tend to follow as the core goes. I'll do some research on Drupal and the modules we use; if the really big ones like Ubercart have been brought up to date, then I'd bet a lot of the smaller ones have, too.
I don't know what threshold ought to be...it is bleeding edge, and intended to be right at the edge of what works for the majority of users (and has big "buyer beware" stickers all over it), so we're not going to wait for everything under the sun to fall into line. But, we can't just go breaking thousands of users websites, either.
Submitted by rrhode on Sat, 10/09/2010 - 06:21 Comment #7
I completely understand what you are saying. It is something I have been concerned about and from my experiences the modules/extensions and things are the things that don't work. Also I am not necessarily asking for PHP 5.3. I am asking for the ability to allow us to somehow choose between versions. Clearly it is too much work to be able to add an option right in the control panel to be able to switch on the fly. I just had a nightmare that a huge giant record breaking snake was eating all the goats, sheep, dogs and little kids in the neighbourhood and it was slinking through our back yard while I was on the phone with a telemarketer. I still don't know why I stayed on hold so long with them. I think it was just because it was a cute sounding girl. Who knows what she was like in real life though. But see, even nightmares aren't completely bad. But would it be too much work to have a separate repo for users to be able to choose? You could have a cutting edge repo (the one you have now) and a bleeding edge repo (one with updated PHP versions and whatever else required). If you wanted you could even have a 'I've just been cut by a sharp edge, I bled out, and now I'm dying' (to go along with the theme) repo for the risk takers who could test things like these modules for you so you would already know when to migrate versions to the bleeding edge repo.