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.
By MarkMorley on
Hello folks,
A customer of mine is using Drupal on their site and it broke when we upgraded PHP from 4.3.9 to 4.3.10.
I'm not familar with Drupal myself, and it appears that the client is using an older version (4.3.0). A complete upgrade to 4.5.1 may not be feasbile for them at this time due to budget and time constraints.
The error they get is in the menu.inc file where it complains about a foreach() loop. The problem is that the $_list array is not being initialized, so the foreach loop complains about an invalid argument. Backtracking through the code I have determined that the menu() function is not being called at all by any of the modules. But there are no other errors anywhere.
Reverting to 4.3.9 allows it to run fine again, but this isn't a valid solution (4.3.10 includes bug and security fixes).
Any thoughts? Ring any bells? Is a complete upgrade to 4.5.1 the only way to go?
Thanks in advance for any assistance you can give,
Mark
Comments
More info
Can you give the watchdog details? Line numbers and specific errors.
I looked at the changlog for PHP 4.3.10 and there might be one or two things wrong. Serialization they have been playing with since 4.3 and have not gotten right yet. Or it maybe an array initialization problem.
They have also optimized the foreach() construct for speed which comes from PHP5 so any variable or object tricks in the loop might be causing the problem. I just love saying "I told you so".
---------------------------
info for Drupal installation
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
www.hivemindz.com
Thanks for the reply. Ok,
Thanks for the reply.
Ok, here's what we see when trying to load the main page of the site when 3.9.10 is in place:
Looking at the entries in the watchdog table I see these for the same access attempt (duplicate lines deleted):
That's all there is.
Mark
4.4 guy
I only came in on version 4.4 so I am not familiar with the code from that far back. But this looks like a change in PHP configuration rather than the code. Do you have magic quotes on in one version and off in the other?
---------------------------
info for Drupal installation
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
www.hivemindz.com
Nope, exact same php.ini
Nope, exact same php.ini file, same compilation options, same Apache config. Only difference is the PHP source code itself. There are many other clients on the same server too, and none of them have been affected by the PHP upgrade.
Mark
PHP version problem for anyone using a hosting service
I just had the same problem today. Two sites down and no real fix in site. Seems if you're using a hosting service and they upgrade PHP, your drupal site is dead in the water. If they won't revert for you, your only option is to line up a new host that will be sticking with an older version of PHP and then migrate your sites over. I should hear back from my host tomorrow am as to whether they can revert, but it looks unlikely. :-(
In this case I am the
In this case I am the hosting provider. I've temporarily reverted to PHP 4.3.9 for this client on the particular server they are using, but it's simply not possible to NOT upgrade to 4.3.10. It contains many bug fixes, several of which are fairly critical security issues. Any hosting site that doesn't upgrade to 4.3.10 is opening themselves up to several potentially serious problems.
Mark
Trouble with 4.5.1
I am also having problems with PHP 4.3.10 and Drupal 4.5.1. A fresh install of drupal works in my environment, but my current installation does not. In my case, all pages are blank. The apache error log shows:
PHP Fatal error: Call to undefined function: user_access() in /home/evanh/web/blog.evanheidtmann.info/includes/common.inc on line 1914I've done a little research, and it appears that modules aren't being loaded. What can I do to try to pin this down and fix it?
Whoa!!
Whoa! I can't keep up.
The Drupal developers will have to get in on this. I did warn them that this would happen as PHP 4 moves closer to being PHP 5.
Testing this stuff is a pain when you have to switch back and forth between PHP versions.
I have not pin pointed it yet but I am sure this has to be a serialization problem. serialization is the only thing I could find that has changed and Drupal uses extensively.
Edit--------------------
Found that in each case the failure of modules loading and the menu failures stem back to the foreach(). Though this was not a bug fix someone did fiddle with the foreach() construct:
"Backported Marcus' foreach() speedup patch from PHP 5.x."
which probably created a bug. :(
or possibly foreach() is double checking the datatype and failing on finding false arrays?
---------------------------
info for Drupal installation
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
www.hivemindz.com
I'll install PHP 4.3.10 to
I'll install PHP 4.3.10 to investigate this.
Update: compiled PHP 4.3.10 but I can't reproduce these problems with CVS HEAD.
Maybe it's a combo
Maybe it's a combo of two items being that it only happens on an upgrade and not on a new install. Possibly something being returned from the cache or another database table is stopping the arrays from initiallizing.
Or items serialized with 4.3.9 cannot be unserialized with 4.3.10
Has nayone tried emptying the cache after the upgrade?
---------------------------
info for Drupal installation
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
www.hivemindz.com
Clearing the cache
Doesn't work as far as I can tell :-(
Mark
Clearing the cache does not help
I can confirm that clearing the cache does not help. I did a "DELETE FROM cache;" and the behavior continues.
from another thread
It would seem that unserialize is the culprit here. As there was a security flaw in the previous version of unserialize, the newer version seems to protect against the flaw but also may be ignoring strings created with the previous version.
http://www.hardened-php.net/advisories/012004.txt
---------------------------
info for Drupal installation
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
www.hivemindz.com
Initializing that particular
Initializing that particular array seems to be the obvious solution.
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.
--
Drupal services
My Drupal services
PHP upgrades are rolling out fast
would appear that many hosts are getting on this. Just got an email from www.lunarpages.com stating:
"We are upgrading to PHP version 4.3.10 and Zend Optimizer to version 2.5.7."
- gil -
Xoops and others are suffering
Other CMS's are suffering from the same syptoms. A few are foreach() problems and all are previous installs being killed by the upgrade to PHP 4.3.10
http://www.xoops.org/modules/newbb/viewtopic.php?topic_id=28638&forum=20...
http://forums.invisionpower.com/lofiversion/index.php/t158132.html
http://www.xoops.org/modules/newbb/viewtopic.php?viewmode=thread&topic_i...
Apparently this has something to do with the Zend optimizer not being upgraded along with PHP. This is causing the reoccurence of a perviously fixed foreach() bug. To a minor MySQL errors and unserialize are also happening. Hosts should be warned not to upgrade unless they are going to install or upgrade Zend Optimizer.
http://bugs.php.net/bug.php?id=30914
---------------------------
info for Drupal installation
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
www.hivemindz.com
Spreading like a wildfire
This is spreading like a wildfire with so many hosts upgrading. It's the wrong time of year also with so many going on holiday. A good part of the internet will be effected as it is PHP on the whole and not just CMS's. There should have been prior warning from the PHP developers and Zend!
http://forum.mamboserver.com/printthread.php?t=25240
---------------------------
info for Drupal installation
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
www.hivemindz.com
Problem solved?
After researching similar problems with Xoop, Mambo, and others, I have learned a couple of things and solved our particular problem for now.
Many of the problems with the 4.3.10 PHP update seem to be caused by people who are not updating Zend Optimizer when they update PHP.
In our case, we don't use Zend Optimizer at all. But we happen to use PHP Accelerator. Disabling PHP Accelerator allows me to update to 4.3.10 and the customer's Drupal site seems to be working just fine.
One of the "fixes" in 4.3.10 involves backporting the foreach() code from PHP 5.0 and this in turn seems to be incompatible with Zend Optimizer, Turck MMcache, PHP Accelerator, etc. In the case of Zend Optimizer there is an update available that fixes the problem. I am not aware of any similar fixes for the others, except to disable them.
Mark
I had turck-mmcache
I had turck-mmcache enabled. I disabled it and now one of my two sites is working. I installed it from backup tarball and sql-dump and now it's working great.
However, my other site was reporting 404 errors for almost every page. I fixed it by clearing the cache again.
In short, disabling accelerators and optimizers worked for me! Thanks so much!
EDIT: I'm now getting lots of unserialize errors on E_NOTICE level. I don't see anything in my logs if I turn off logging of E_NOTICE errors. I also don't know if these were happening before the upgrade.
php 4.3.10 and Zend
Mark said:
The experience on my host seems to verify this. www.lunarpages.com upgraded today, both php and zend, and so far I'm seeing no problems.
- gil -
mb_strpos / strpos messages
Another solution is to exclude mb_string.so from extensions.ini (at least in my case where drupal broke after upgrading php to 4.3.10). As noted earlier, there is no mb_strpos on the mentioned code line, but for some reason php overloads strpos with mb_strpos. Dropping the module caused at least my problems with drupal to disappear :)
Use eAccelerator
This problem happens only if you use a PHP accelerator, like mmCache.
The latest version of eAccelerator, a fork of mmCache, works correctly with PHP 4.3.10.
Cheers,
Marco
--
Marco
or latest mmcache
I upgraded to PHP 4.3.10 and Turck-mmCache-2.4.6 without any problems.
Just a "me too" - broken posting
I moved my site from one server to another. The new server is running PHP 4.3.10 and I see several unserialize() errors in my Apache error_log file:
I'm running Zend 1.3.0 (extension 20021010). I'm running Drupal 4.5.1 in this case.
This doesn't appear to be a catastrophic issue for me, but something that keeps bumping up my error_log size.
I have a similar error.
I am getting the same error...
Notice: unserialize(): Error at offset 16 of 18 bytes....
On my site the drupal system continues to run anyway. Also, the functionality seems to be working so I have crossed my fingers and hoped it keeps working.
Cause of Unserialize() error
I ran into this error with a fresh install of CivicSpace (a Drupal distribution), but not when i did a fresh install of Drupal. I tracked the problem down to a bad variable DB entry. In the case of CivicSpace, there was a problem with the initial DB setup. I documented the problem in this thread.
I solved the problem by inserting this line:
printf("\nvv+: +%s+ -%s- <br>", $variable->value, unserialize($variable->value));
at line 51 of bootstrap.inc. This will (somewhat ungracefully) dump the contents of the PHP variable $variable->value to the screen ("quoted" by plus signs "+"), along with the return value of the unserialize () function call ("quoted" by hyphens "-"). When examining the output in relation to the generated errors, i noticed that the semi-colon which was at the end of every value had been moved left one character; effectively it was transposed with a quotation mark. Because of this, the result of the unserialize () function call was an empty string.
While that may not be what's causing your problem, it should put you on the road to figuring out what is causing it. With the extra output, you can compare data which causes no error with that which does, as i did, and perhaps track the problem down that way.
Hope this is helpful.