Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Branching off of #360605: PHP 5.3 Compatibility, give Drupal 5 PHP 5.3 support...
This patch does a couple of things:
- Replaces the deprecated ereg with mb_ereg
- Removes the not-required passed by referenced parameters on block_user, comment_user, node_user, system_user, user_user and watchdog_user
- Since Drupal 5 uses parse_ini_file,
on
causes problems with the INI parsing. This is easily solved by wrapping the INI description strings that use "on" in quotations.
Comment | File | Size | Author |
---|---|---|---|
#33 | drupal5-n853064-32.patch | 1.42 KB | DamienMcKenna |
#32 | drupal5-n853064-32_ugly.patch | 939 bytes | DamienMcKenna |
#29 | 853064-drupal_5_install_php_support-29.patch | 1.41 KB | DamienMcKenna |
#27 | 853064-drupal_5_install_php_support.patch | 478 bytes | greg.harvey |
#19 | d5.form_.inc_.patch | 575 bytes | mvc |
Comments
Comment #1
RobLoachWas also missing
function theme_status_report(&$requirements)
.Heine also brought up the issue that mbstring is not a requirement of Drupal 5, so mb_ereg might not be available on some environments.
Comment #2
RobLoachThe solution is to stick with ereg, but ignore the deprecated warning.
Comment #3
MTecknology CreditAttribution: MTecknology commentedI 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.
Comment #4
Druid CreditAttribution: Druid commentedEven better, if you're changing code anyway, replace
ereg()
calls withpreg_match()
calls. You need to change the search pattern (first parameter) to include delimiters such as /, e.g.,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
Comment #5
Damien Tournoud CreditAttribution: Damien Tournoud commented*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.
Comment #6
MTecknology CreditAttribution: MTecknology commentedDruid: 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...
Comment #7
Damien Tournoud CreditAttribution: Damien Tournoud commentedNo, 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.
Comment #8
MTecknology CreditAttribution: MTecknology commentedI 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.
Comment #9
RobLoachThe hook_user() by ref stuff needs work. Can't edit user accounts.
At this point, I'd consider Drupal 5 like Windows 98 ;-) .
Comment #10
RobLoachComment #11
RobLoachuser_module_invoke(), not user_invoke_all() :-) .
Comment #12
andrewfn CreditAttribution: andrewfn commentedThis is an excellent patch.
It would be great if this could be committed before Drupal 7 comes out and D5 is no longer officially maintained.
Comment #13
Harry SlaughterI'm testing out patch #11 as well. Will report back if I find any issues :)
Thanks for this.
Comment #14
Bèr Kessels CreditAttribution: Bèr Kessels commentedI 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).
Comment #15
greg.harvey+1 R&TBC here. Applied to my last remaining D5 site cleanly and seems to have fixed everything without side-effects. =)
Comment #16
buddaPlease 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
Comment #17
Bèr Kessels CreditAttribution: Bèr Kessels commentedIs there anything the community can do to get this applied? More tests? Evaluating specific edge-cases? Anything else?
Comment #18
Heine CreditAttribution: Heine commentedWhy @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).
Comment #19
mvc#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)
Comment #20
quaestor CreditAttribution: quaestor commentedHas 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
Comment #21
Heine CreditAttribution: Heine commentedRestoring issue parameters.
Comment #22
llv95dno CreditAttribution: llv95dno commentedHi!
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.
Comment #23
greg.harveyOk, 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.
Comment #24
DamienMcKennaAlong 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?
Comment #25
DamienMcKennaFrom 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".
Comment #26
RobLoachInstead of just completely dismissing this, it would be great if you suggested a way around this particular issue, or uploading a new patch without that change in it. I needed PHP 5.3 support for Drupal 5, so I put time into the patch. Being constructive is a helpful thing in the open source world. Thanks.
If we're doing this, then we should re-base this issue to a documentation change to state that PHP 5.3 is not supported in the readme, like you suggested.
Not even sure if that change is really needed.
Comment #27
greg.harvey@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. ;-)
Comment #28
jbrown CreditAttribution: jbrown commentedPHP 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)
Comment #29
DamienMcKennaHere's a patch that changes the wording to say "5.2.x or lower, 5.3.x and higher is not supported".
Comment #30
RobLoachWe could probably also update the hook_requirements() call to warn if they're on PHP >= 5.3.
Comment #31
jhodgdonIn 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.
Comment #32
DamienMcKennaUpdated.
Comment #33
DamienMcKennaFYI here's a version of the previous patch that shortens the PHP URL to make the wrapping less ugly.
Comment #34
jhodgdonLooks 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.
Comment #35
andrewfn CreditAttribution: andrewfn commentedI 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?
Comment #36
DamienMcKenna@andrewfn: It's a simple conflict between a) changes in the underlying language, b) Drupal policies.
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.
Comment #37
jhodgdonRight. 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.
Comment #38
thinkyhead CreditAttribution: thinkyhead commented@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.
Comment #39
jhodgdon7.0 is out tomorrow, 5.x is obsolete, won't fix, sorry.
Comment #40
DamienMcKennaI 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."
Comment #41
jhodgdonAll you need to do is convince drumm to commit the patch. :)
Comment #42
DamienMcKennaI just sent the following to drumm:
Fingers crossed..
Comment #43
drummSure, committed. But I don't think we'll be doing another release. There have been no other commits since 5.23.
Comment #44
DamienMcKenna@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!
Comment #46
terrychild CreditAttribution: terrychild commentedHi 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
Comment #47
crystaldawn CreditAttribution: crystaldawn commentedPatch @ #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).