Alter INSTALL.txt to be clear PHP 5.3 is not compatible with Drupal 5

I tried out your second patch and the errors went away and life was happy. I really wish that this could be pushed to D6. Just hiding something that's an actual issue seems like a rather bad idea.

Even better, if you're changing code anyway, replace ereg() calls with preg_match() calls. You need to change the search pattern (first parameter) to include delimiters such as /, e.g.,

ereg($mask, $file)
preg_match("|$mask|", $file)

ereg('^<\?xml[^>]+encoding="([^"]+)"', $data, $match)
preg_match('/^<\?xml[^>]+encoding="([^"]+)"/', $data, $match)

ereg("[^\x80-\xF7 [:alnum:]@_.-]", $name)
preg_match("/[^\x80-\xF7 [:alnum:]@_.-]/", $name)

In the first case, I don't know for sure what's in $mask. More information at http://us.php.net/manual/en/migration53.deprecated.php

*sob*

I'm tired of explaining: no API change in frozen versions, no new dependency on multibyte. Both preg_match() and mb_ereg() are no go.

Plus, there is nothing wrong with ereg() per se. It is not even scheduled for removal anymore.

Druid: Interesting..
I already proposed a patch to Pressflow for this: https://code.edge.launchpad.net/~kalliki/pressflow/ereg-wrapper/+merge/3...

I think the solution is pretty clean. Is there any significant difference between using mb_ereg or preg_match aside from the syntax? I'm way too tired to actually figure out what makes one better than the other. If there is then maybe I'll try to sneak that in before Mr. Strauss reviews it again.

And now... G'night Mr. Sun coming up oh so shortly...

No, ereg() and preg_match() are *not* compatible. They use two completely different regular expression engines, and you cannot convert losslessly one to the other. Moving to preg_match() would be an API change, that's why we did it for Drupal 7, but cannot do it for neither Drupal 6 nor (even more) for Drupal 5.

#2 is on the right track: the correct solution is to ignore those silly deprecation warnings. But it is not the correct way to do that. Please study what has been done for Drupal 6 in the other thread and just backport that. More or less, it involves removing E_DEPRECATED to error_reporting() and hiding it in the error handler.

I didn't ask if they were compatible. I asked if there is anything that made one better than the other.

The correct solution is never to just ignore something. I'll agree that in this case the warnings mean very little but ereg() is deprecated whether they decided to keep it around longer or not. If you simply ignore errors, warnings, and other issues, you'll wind up with software like Microsoft Windows.

I also agree with this not being valid for D5, D6, or even D7. At best it would be a change for D8.

This is an excellent patch.

• I have compared it with my own earlier patch at http://drupal.org/node/360605#comment-2273386 and it covers all the problems that I had patched, plus several more and is well written.
• I have installed the patch on six servers and all are working well with no issues.

It would be great if this could be committed before Drupal 7 comes out and D5 is no longer officially maintained.

I'm testing out patch #11 as well. Will report back if I find any issues :)

Thanks for this.

I have tested the patch with a rather complex Drupalsite (80+ modules) and it applies perfectly. xdebug reports no errors (except for a gazillion notices). I crawled the site and saw no interesting new notices in the error logs appear, that were not there before the patch.

For those googling for information: the incompatibility caused several child pid 8691 exit signal Segmentation fault (11) errors. These only occurred when hook_menu was cached, not when the cache was just cleared.
This patch fixes that error.

Patch applies well. And looks alright (coding standards wise).

+1 R&TBC here. Applied to my last remaining D5 site cleanly and seems to have fixed everything without side-effects. =)

Please please please can we get this in for the next 5.x update that rolls out. or just make it a version on its own as PHP 5.3 is becoming more common on hosts, and 5.x sites need somewhere to live still.

+1 for RTBC

Is there anything the community can do to get this applied? More tests? Evaluating specific edge-cases? Anything else?

Why @ereg when E_DEPRECATED should be ignored by the error_handler?

Removing references from the user hooks is wrong. Remember, D5 still has to support PHP 4. Also, it is simply hiding the error. Do something about the caller(s).

#11 helped me a lot, but I also needed to patch form.inc using the same solution as was used in theme.inc to get date_api 5.x-2.8 working (see #905690: php 5.3 does not allow call_user_func to pass reference, causes WSOD in 5.x version)

Has anyone else run into issues with all roles being selected when saving a user?

After the host was upgraded to PHP 5.3, in addition to all the errors already mentioned, I found that users were being saved with all roles selected regardless of which roles were actually selected by the user. I upgraded to Drupal 5.23 and applied the #11 patch but the issue remains. I've dug into the issue enough to fix my site with a 2 liner modification in the user.module but I'm not proud of the change. If anyone else is having a similar issue, I'll dig in deeper and submit a proper patch.

From the look of the problem, only sites that have additional roles that would be affected.

Thanks

Restoring issue parameters.

Hi!

I experience the same problem (host upgraded to PHP 5.3) after upgrade to Drupal 5.23 and applying #11 patch, with users being saved with all roles selected regardless of which roles were actually selected. It would be most helpful if anyone was able to submit a patch that could fix this issue.

Ok, I retract #15. Actually, I think this patch is dangerous. Drupal 5 does not support PHP 5.3 and probably never will. There are "fixes" in this patch that break things badly elsewhere. Do not use.

Edit: for example: #995550: References dropped from user_user() breaking user edit form.

Along with opening up a glaring bug when editing or adding users (see above), wouldn't removing the pass-by-reference on the *_user functions constitute an API change?

From another POV, given there several of the originally proposed changes for PHP 5.3 compatibility are breaking Drupal 5, couldn't a note just be added to the Drupal 5 README.txt file to explain that PHP 5.3.x is not supported? I mean, it's three years old and Drupal 7 is just about to be released at which point official support for D5 drops. I'd vote for taking a hard stance that if you're going to stick with the old & unsupported version of Drupal you shouldn't be complaining about having to use an old & unsupported version of PHP.

I'd vote to mark this "Closed: Won't Fix".

@Everyone, I want to be crystal clear that the current version of the patch is not to be applied under any circumstances. Didn't mean to offend anyone, but that is the case! I should've checked the patch more carefully before applying it, I blame myself for that and it cost me 2 days of bug-hunting. Least I can do is make sure other people avoid the pit. =)

@Rob, I invite you to read my issue tracker. I am constructive and have contributed *a lot* of patches over the years, so spare me the lecture. If you intend to spend more time on this, go right ahead. My constructive advice would be this: the patch is too big to be easily reviewed and if folk are serious about continuing the effort to make Drupal 5 work with PHP 5.3 then it should be broken down in to smaller sub-issues/cases so they can be properly reviewed, applied and tested individually.

But I won't be doing that because I agree with Damien, I don't see the benefit of patching an obsolete version of Drupal to work with the latest PHP. I will never work with Drupal 5 again, this was my last Drupal 5 job ever and I know that. No one should be using it any more, it won't be maintained in a matter of weeks. I'm sorry if you disagree, but that's my opinion.

So here you go, documentation change. I've even provided that patch, just to show I'm not as evil as you think I am. ;-)

PHP 5.2.15 has actually been released: http://www.php.net/archive/2010.php#id2010-12-09-1

Doc should really say:

Drupal requires a web server, PHP4 (4.3.5 or greater) or PHP5 (5.3 and above is not supported)

Here's a patch that changes the wording to say "5.2.x or lower, 5.3.x and higher is not supported".

In this phrase:
or PHP5 (5.2.x or lower, 5.3.x and higher is not supported)

This is a nitpick, but the grammar, punctuation, etc. is not correct here and I found it unclear. It should probably say:

or PHP5 (through 5.2.x only; 5.3.x and later versions are not supported)

or something like that. At a minimum, is -> are since to me 5.3.x refers to versions, which is plural.

Updated.

FYI here's a version of the previous patch that shortens the PHP URL to make the wrapping less ugly.

Looks reasonable to me, from a grammar, style, punctuation, and clarity perspective. I cannot vouch for the accuracy of the statements in the patch, so I'll leave the setting of RTBC to someone more up on the requirements for Drupal 5.

I have a problem understanding what we are doing here. When I build a website for a client, should I tell them upfront that it will likely die in 2-3 years because the Drupal it is build on has become unsupportable? This might be acceptable for large clients, but many of my clients are non profits and cannot afford frequent redesigns.
There is a difference between a version of Drupal becoming unsupported (so it no longer gets security patches and the client takes a risk) and a site dying horribly in a mass of php errors which is what is now happening.
The major server distributions (CentOS/RHEL 5.6, CentOS/RHEL 6.0, Ubuntu 10.04) are all now on php 5.3. The hosting for more than half of my clients has moved to php 5.3. Most of them can't afford the cost of re-building the site on Drupal 6 so I have no option but to apply the patches.
For the last 4 months I have been running with patch #11 plus http://drupal.org/node/744764 with no problems on any of the sites. It would be really helpful if @greg.harvey could explain your warnings in #23
My big concern is that we are positioning Drupal as a tool that is only suitable for large clients when we say things like "no one should be using Drupal 5 any more". If I were launching a site today, I probably started designing it a few months ago, and so it would be using Drupal 6. Should I be honest with my client and tell them that as soon as Drupal 8 comes out their site may be toast?

@andrewfn: It's a simple conflict between a) changes in the underlying language, b) Drupal policies.

• Drupal 5 was written to be compatible with PHP 4.3.5 & newer (i.e. including 4.4.x) and PHP 5. Unfortunately, PHP changed a few things in 5.3, including deprecating the ereg functions, so that warnings will be given when using Drupal 5 under PHP 5.3.
• On the Drupal side of things, there's a policy of not making any API-level changes after a .0 release, i.e. there will not be any API changes allowed for Drupal 5 to make it compatible with PHP 5.3 (or PHP 6 if it's ever finished).
• The patches above to change Drupal to adjust the code are done under the best of intentions but they a) cause bugs, b) break API compatibility (preg_* and ereg* functions are not 100% compatible).
• With Drupal 7 due in roughly a week (January 5th, 2011), your clients should be made aware that on that day Drupal 5 will no longer be officially supported.
• There's nothing to say you can't hack up your own fixes and make patches that work for you, but we've at least shown why the patches above are not suitable for inclusion in the official release (they break stuff).

FYI, this is like complaining that your software built for Windows XP doesn't work 100% correctly on your new Windows 7 machine, or your car don't work right with ethanol-based fuels - either don't upgrade anything, upgrade everything at once, or deal with having to hack it.

Right. If you want to keep running Drupal 5 on PHP 4.x or whatever PHP/MySQL server it was running on, it should keep running (though without security updates). If you want to upgrade to PHP 5.3 or otherwise modernize the server, we can't guarantee that an old version of Drupal will continue to work.

Again: we still need a review of the technical accuracy of the statements in the patch in #33.

As a note, http://drupal.org/requirements agrees with this patch.

@andrewfn: It should be added that although definitely a detail-intensive process, upgrading a site to the next higher version of Drupal should be an expected part of an active site's development cycle as new versions become available. Last year I did an upgrade for a very active site from 4.7 to 5.x then to 6.x, keeping careful notes and building up a set of steps from trial-and-error, till I was certain I could do the whole upgrade on the real site all in one go. The process included substitutions for dead modules, plus new custom modules and themes. Whew! But bringing the site up to date made it better in virtually every way and both client and users are very happy to have the best platform available to build on going forward.

7.0 is out tomorrow, 5.x is obsolete, won't fix, sorry.

I still think it's worth sealing the D5 repository with a commit that says D5 won't run on PHP 5.3, to officially tell people that "no, it won't work correctly, stop trying to."

All you need to do is convince drumm to commit the patch. :)

I just sent the following to drumm:

Good evening to you.

I know it's late with D7 due tomorrow, but I think it is a perfect time to commit a patch (http://drupal.org/node/853064) that says D5 is incompatible with PHP 5.3. As you can see from the thread, the proposed fix for the incompatibilities added major bugs of its own, so the simpler solution that we proposed was to just update the README.txt file to say that D5 was only compatible with PHP 5.2.x and older.

Having worked on several D5 sites, and having one small client that's clinging to their site for fear it evaporate, closing off this "route of escape" will help cement the line in the sand on D5 support.

If you have any questions, or any wording changes would you prefer be made, I'll be around on IRC (dmckenna, usually in #drupal-seo) or just reply to the thread and I'll do what I can to help.

Thank you again for the many years of selfless work you've put into the community, especially maintaining D5.

Damien McKenna

Fingers crossed..

Sure, committed. But I don't think we'll be doing another release. There have been no other commits since 5.23.

@drumm: thanks. I'm less worried about another release and more just wanted to ensure that the D5 code in CVS had it in, as a final say on the matter.

Thanks again for your work over these past several years!

Hi All

For what it's worth - by following the instructions in the link below I've managed to get an old Drupal 5 site to run on Debian 6.0 Squeeze using php 5.2 and fastcgi.

The other Drupal 6 and 7 sites on the same machine use php5.3 shipped with Debian 6.0.

http://blog.davejamesmiller.com/2011/03/how-to-install-php-5-2-fastcgi-o...

Cheers

Patch @ #11 seems to work with 5.x (dev). A couple hunks dont apply, but it does get the install working well enough to limp along until the client can upgrade to D7. After patching, all I needed to do was modify the .info files and put some " around the descriptions for the word 'on' and everything seemed to function well enough. I dont use the modules that it found failures in, so I dont care about those personally. Others may want to see what the update patch will do with the 5.x(dev) release file which is slightly newer than 5.23. Well, here you go. It does work. Modify the poll/comment module yourself if you need them and you should be set.

For anyone who cares, this was the patch output on a 5.23 install:

[root@webserver public_html]# patch -p0 < drupal5php53_3.patch
patching file includes/common.inc
Hunk #1 succeeded at 24 (offset -1 lines).
Hunk #2 succeeded at 595 (offset -1 lines).
patching file includes/file.inc
Hunk #1 succeeded at 642 (offset -1 lines).
patching file includes/module.inc
Hunk #1 succeeded at 378 (offset -1 lines).
patching file includes/theme.inc
Hunk #1 succeeded at 167 (offset -1 lines).
patching file includes/unicode.inc
Hunk #1 succeeded at 134 (offset -1 lines).
patching file modules/block/block.module
Hunk #1 succeeded at 588 (offset -1 lines).
patching file modules/comment/comment.info
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file modules/comment/comment.info.rej
patching file modules/comment/comment.module
Hunk #1 succeeded at 449 (offset -1 lines).
patching file modules/drupal/drupal.info
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file modules/drupal/drupal.info.rej
patching file modules/node/node.info
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file modules/node/node.info.rej
patching file modules/node/node.module
Hunk #1 succeeded at 1005 (offset -1 lines).
patching file modules/poll/poll.info
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file modules/poll/poll.info.rej
patching file modules/system/system.module
Hunk #1 succeeded at 324 (offset -1 lines).
Hunk #2 succeeded at 1863 (offset -1 lines).
patching file modules/upload/upload.module
Hunk #1 succeeded at 814 (offset -1 lines).
patching file modules/user/user.module
Hunk #1 succeeded at 259 (offset -1 lines).
Hunk #2 succeeded at 463 (offset -1 lines).
Hunk #3 succeeded at 1042 (offset -1 lines).
Hunk #4 succeeded at 1506 (offset -1 lines).
Hunk #5 succeeded at 1546 (offset -1 lines).
Hunk #6 succeeded at 2460 (offset -1 lines).
Hunk #7 succeeded at 2487 (offset -1 lines).
patching file modules/watchdog/watchdog.module
Hunk #1 succeeded at 72 (offset -1 lines).