PHP 5.2 requirement

You really probably need a better host or consider changing platforms. You really, really ought to get with the current platform and try to find a 5.2 solution.

That said however, as far as I know the current version does not truly require 5.2. You can remove the requirement line from the filefield.info file and it will work for the most part. However, please do not submit any help requests regarding running on an unsupported platform. FileField will continue to require 5.2 by default.

We're caught with this situation as well.

It is just not an option for us to move off of PHP 5.1.x, but we are dependent on using FileField.

Editing the filefield.info does work. But we have it on our radar that there are risks. So far, we have not reviewed the code, or noticed any problems. Should a break occur, our plan is to try and refactor the module; and as a last resort, disable the feature that are impacting.

We are truly hoping there is no PHP 5.2 dependency. However, our dev team is ok with supporting (only if and when needed) a PHP 5.1.6 version. If there are others who could benefit from this, we are willing to share this work as project. (Not sure if forking this module into a new project just for the PHP version is the best way to go. Any other ideas are welcomed.)

Again, we are not doing this unless we notice a PHP 5.2 dependency.

There are RPMs of PHP 5.2 for RHEL all over the internet and otherwise compiling from source is really easy as well. I also use php 5.2 on RHEL, both 5.2 and 4.7.

No argument here. If you can move to PHP 5.2, go for it! It can be done for RHEL and Centos, and there are no technical issues finding the RPMs. Unfortunately, we have contractual terms with our client that prevents us from upgrading. It's out of our hands, and all we can do is mitigate any PHP 5.1 related problems.

We think there might be others in a similar situation as us, and we're just planning ahead. Again, just planning. We don't want to do anything unless we are impacted by a real issue. But our primary concern is people NOT submitting tickets related to PHP 5.1 due to it being unsupport in this module. That is why, we are proposing that maybe forking the project is one way to go...

I'm stuck in the same situation. RHEL and no official packages (get the fuck with it, RH!!!). We're testing on of the unofficial packages, but we can;t just migrate out whole server overnight. It'll be a month or more before we can get it upgraded. Frankly, this should have been branched so that there is a PHP 5.1.x branch available on the project page for us unlucky souls to continue using in the meantime. This module is too critical to too many sites to not have that option readily available.

I'd be fantastic to have a 5.1.6 version. We cannot chage PHP at this moment for various reasons.

I second the request for PHP 5.1.x compatibility.

The widespread CentOS 5 platform is committed to PHP 5.1.6. Even for my own server running CentOS 5 an upgrade to PHP 5.2.x is cumbersome and requires the integration of non-standard repositories with dubious security policies.

Have you checked if PHP 5.2.x functionality is even required for FileField? A short preliminary test of 6-x.3.0-beta3 showed no issues on PHP 5.1.6.

Also note that other modules, such as Date API, go to great lengths to provide pre-PHP-5.2.x compatibilty.

Ok, so how should we proceed? Let's review. From post #1 ("FileField will continue to require 5.2 by default"), we sadly acknowledge that this module will not support php 5.1. And, should you have the ability to upgrade your php, you'll follow posts #3 and #6, and you're problem is solved.

This leave the remainder -- us folks who are using FileField AND php 5.1.x.

I suggest a new module. The code will parallel the FileField module, except we'll check-in an .info file without the PHP version. Issues related to php 5.1.x would go into this new modules issue tracker.

I believe a new module has the following BIG benefit. Let's say (hopefully), that FileField 6-x.3 moves out of beta with no true PHP 5.2 dependency. That's great, and our new module is just an clone it. But then subsequent development adds a PHP 5.2 dependency and releases a version (6-x.4). Our new module will try to refactor this version, and release it working for PHP 5.1. Of course, there might be a delay in when this release is available. And it might not be possible. But the benefit is that at least a working version 6-x.3 is available for the PHP 5.1 install base.

Naturally, if the new module cannot resolve true PHP 5.2 dependencies, then functionality will start diverging. But at least you have options. You might not need the new features php 5.2 introduced, so you can continue running with our new module. Or, if you do need the features, you can now accurately assess the cost of upgrading PHP.

Lastly, i think it should be clear, if RHEL/Centos ever move to PHP 5.2, then interest in our new module will disappear.

I asked Earl Miles (merlinofchaos) for his opinion on this, as he's the only developer I know that regularly deals with CentOS (he uses it on his development box) and is very knowledgeable in Drupal (quite obviously). A little background here also: this requirement has been in place since I became maintainer for FileField (now a little over a month), so I neither put it in place or know why it was put in place to begin with. I also was not aware RedHat was being so ridiculous and charging more for access to a secondary update stream which includes 5.2, and that 5.1 is the default for all RHEL/CentOS users.

The widespread CentOS 5 platform is committed to PHP 5.1.6. Even for my own server running CentOS 5 an upgrade to PHP 5.2.x is cumbersome and requires the integration of non-standard repositories with dubious security policies.

My consultation revealed the same thing. It's possible to upgrade but it's an annoyance and not entirely possible for users who don't have access to their own server configurations. It's not so much that the repositories are dubious (I'm sure they offer no warranty on their packages, much like Drupal itself or any other GPL software), but it does void the reason most people are using Red Hat to begin with.

Have you checked if PHP 5.2.x functionality is even required for FileField? A short preliminary test of 6-x.3.0-beta3 showed no issues on PHP 5.1.6.

As I mentioned in the first comment, there is no actual 5.2 dependency afaik.

So. Conclusion: We should reduce the requirement down to 5.0 for the next release of FileField. I'd really prefer not to support PHP4 since my tests currently won't run on PHP4. However, no one here is asking for PHP4 support. :-) If users can confirm there are no issues with PHP 4 and are willing to patch my tests then I'd be fine with removing the PHP requirement entirely.

Please open a new issue for any problems caused by this changes. Thanks everyone for your input.

I just want to add that I have been using the latest FileField and ImageField releases on PHP 5.1 for some months (yes, I hacked the .info file) and noticed no problems at all. So this change seems safe. Thanks!

The php 5.2 requirement was inherited from imageapi IIRC.

There are some issue with PHP 5.1's handling of Resources as object properties with pass by reference updates. I believe these issues are patched in Redhat's PHP 5.1.6. However, a pure PHP 5.1 installation will lost the resource reference of an image object.

There were also several issues with early versions of filefield that could be resolved by updating to PHP 5.2, hence the requirement. I didn't research it too heavily I just accepted that php 5.2 resolved the issues.

Same problem here. One just have to have in mind, that in industrial enviroments upgrading is never that easy, and most of the time, this is not due to the technics, but to financial issues and even more often a non-technical decider provides you with a provider you don´t like. Generally, I think that forking always is a bad solutions if you look towards the future. It just helps out for the moment. The modules always should dependent on the lowest possible requirements. At best, at the same requirements than the corresponding core module. So, I would suggest to "downgrade" the module to php 5.1 and upgrade the requirements at a time when they are really needed.
In general, it would also help to have an easy "requirement tracking" for all modules, so that one could deliberately downgrade to the best module fitting his own restrains.
By the way, at least for us we could have less problems, if in the module descriptions would have been written that php 5.2 is required. It states only "php 5". We did confirm the customer, that his current system does not need any upgrade, and now it does. Could anyone please upgrade that statement in the module description?

temmermon, RC1 (the latest release) only requires PHP 5(.0.0). That's what we concluded in #10.

sorry, read this as a suggestion only. Will be more careful in reading next time.