By thinkyhead on

Drupal 6 and PHP 5.3: The Docs

I've been re-reading the Drupal "System Requirements" page and ruminating over my recent home-sprints, where I've updated my own modules for the latest Drupal and backported any new code to earlier versions of Drupal. I'm keeping some of my Drupal 5 modules alive simply because it's easy to do, and it makes an interesting reference point to see the evolution of Drupal across different releases.

One comment in particular got my attention, because in practice the "requirements" for Drupal 6 are not quite the reality.

Drupal 6 and PHP 5.3: The Reality

Drupal 6 is not officially supported running under PHP 5.3. However, Pantheon is just one service I know of which supports Drupal 6 under PHP 5.3, and it also works very well on my laptop. PHP 5.4 is definitely stingy about undeclared variables, properties, and array keys, and throws a lot of warnings, so I consider it unsupported. But it's not too far off! I haven't seen too many places where it just functions wrongly. Well, I'm about to once again try switching to PHP 5.4 and see how badly my modest Drupal 6 site chokes. I also tried PHP 5.5 recently and that was definitely out of reach for my Drupal 6 installation. But not too far...

Drupal 5 and PHP 5.3: Doable

I've been maintaining a humble install of Drupal 5.x on my laptop and patching it as-needed to run under PHP 5.3 (e.g., making an _ereg() function to replace ereg(), etc.). At this point it hasn't exhibited any major quirks, but I don't have very many modules added. The changes that came with PHP 5.3 are minimal enough that any old-school sites (and I know a few) running under Drupal 5 should be pretty easy to patch on a per-module-add basis. (Still, woe to them who get hit by unpatched security flaws in legacy software.)

Patching as We Go

From my experience playing around with the codebase of Drupal, I feel like a concerted effort by people like myself who have sandbox installs running on their desktop, and who can easily switch PHP versions on the fly, could pretty quickly bring both legacy core and legacy modules into compliance with the latest PHP. Perhaps I overestimate the talents of the community, but I know that I can pretty quickly patch a module, especially when I really need one. And when it comes down to it, is there such a significant percentage of the Drupal codebase broken that it would be too daunting or near impossible?

Drupal 6 Lives On

I'm not as concerned about Drupal 5 staying up to date, since upgrading to Drupal 6 is relatively easy. But upgrading from Drupal 6 to Drupal 7 on a very complex site is frankly beyond the budget and skill level of many Drupal developers, and so a great number of perfectly functional Drupal 6 sites are hanging in a holding pattern, and will be doing so for a long time to come. So my main concern is the complexity of dealing with upgrades from Drupal 6 to 7 and 8, and being able to perform those upgrades on the same server with the same version of PHP running for the old and new site. I'm also concerned, as a person who enjoys laptop staging and playing with Drupal on the laptop, with the ease of maintaining multiple versions of Drupal in a modest user environment where saving a few gigs can be very nice.

Drupal 5 and PHP 5.4

At this point Drupal 5 modules are mostly disappearing from the project pages. However releases are still posted on the release pages. An automated tool based around Drush can be built to test all those old modules and flag the ones needing a patch for deprecated PHP features. The "Coder" module provides a great starting point, and could be extended to enforce PHP version compliance. I mention D5 only in-passing. It would make an interesting academic test case for such a patching effort, but is hardly necessary, because upgrading from Drupal 5 to Drupal 6 is relatively easy.

Drupal 6 and PHP 5.4

Drupal 6 module development has slowed way down but even now a fair number are still active as Dev releases. I would encourage all developers of D6 modules not to end-of-life them until they've been patched for compatibility with PHP 5.4, and I'd even go one further and suggest they do a side-release using the new array syntax and other useful features. Until Drupal 6 sites have all gone away, some enterprising soul really should maintain it and keep it alive for future PHP versions. There doesn't need to be any formal support for it at drupal.org, but it would be nice to be able to download from somewhere a set of .patch files that apply to all the popular D6 modules that would make them all work with PHP 5.4. Perhaps some curated Drupal core project would be willing to take the lead on this.

Worth an Effort?

This is just a hope and wish at this point, but I would like to hear what the community thinks of keeping Drupal 6 viable for a while, even while at the same time working to make the upgrade process from Drupal 6 to 7 and 8 as painless, and as automated, as possible. There are still quite a few pitfalls in making these upgrades, and I have yet to do one that didn't require me to write a custom module full of conversion code, plugins for field migration module, and long BASH scripts to dump selective tables and rows from the old database. All of this adds a lot of time and cost which most developers are disinclined to swallow.

Were it cheap and easy to transition data, themes, and modules from Drupal 6 to 8 such a sideways effort would hardly be required, and perhaps time and energy is best spent on shepherding everyone over to Drupal 8. Unfortunately, in my experience, the disparate PHP requirements for Drupal 6, 7, and 8 is one of the bigger barriers to making this transition, adding more cost and complexity for all of us, and yet this seems the most straightforward to overcome, at least surely for core and the 100 most popular modules. I cannot imagine that the changes from 5.3 to 5.4 are so major that a "compatibility module" cannot be built in PHP to at least ease the transition.

Anyway, what are the thoughts of the community about this kind of effort? Who thinks it's worth a GitHub? Who thinks it's a waste of time? What are your own experiences with your Drupal 6 sites, the prospect of upgrading them, and your client's appreciation for the need of an upgrade?

⋅ Categories: Drupal 5.x, Drupal 6.x, Drupal 7.x, Drupal 8.x

Comments

nevets’s picture

nevets commented

Drupal 6 views module does not work under PHP 5.4, it not only produces a lot of errors, for the views with problems they no longer produce any output.

thinkyhead’s picture

thinkyhead commented

Views is a perfect example of a relatively small (by some standards!) code-base that, if patched, would save a lot of headaches, and ought to require only a small (by some standards!) amount of time by one or two developers to fix up for PHP 5.4. Backporting the D7 version of Views would of course be the most useful way to go, if someone wants to get slightly ambitious. Of course this also means patching a lot of modules built around views. Such modules ought to be much easier to patch than Views itself.

The biggest problem I can see here is, clearly, if Drupal 6 is kept limping along, and even if it's given a Herculean effort to patch a very many modules, it will tend to lend false confidence that Drupal 6 sites are as secure and up to date as Drupal 7 or 8, and developers may feel too confident that the next D6 module they add is working fine when it's not. Not all changes in the PHP language are straightforward to work around, and some may not even throw any warning but behavior could subtly change. All of these are considerations, but in some sense they are also considerations in any install involving a dozen third-party modules. We rely on users catching bugs in the most popular modules by sheer volume. On that front, I think we'll have enough volume of active D6 sites for a while, enough to keep patching those 100 most popular modules for a while, so long as those issues are known and tracked someplace.

I haven't switched over to PHP 5.4 lately, but I wouldn't mind banging my head against patching Views module and see just what it involves. I feel like it should only take a few hours —maybe a day or two at most— to get some Views 3 views with a slew of built-in and CCK fields to render in PHP 5.4 without issue. If a single coder can accomplish this sort of thing, it seems imperative to disseminate the work, if only as a headache-saver for others.

rooby’s picture

rooby commented

I think this is a great conversation to have and it would be good to get it some more visibility and input from some key Drupal players.

Since Drupal 6 is still technically supported for a while longer (and possibly in a reduced manner even for a while after Drupal 8 arrives) and PHP 5.2 and 5.3 are officially unsupported this is an important issue.

I think it would be good to aim for PHP 5.5 support since most hosts (in my personal experience) are now discontinuing 5.2/5.3 and are using 5.4/5.5 and some very popular distros are shipping with 5.5 as the default, eg. ubuntu 14.04, OS X Yosemite.

Some info on PHP support periods:
PHP 5.4: Security updates only until September 2015 - https://php.net/archive/2014.php#id2014-09-18-2
PHP 5.5: Bug/security fixes until June 2015 then security fixes only until June 2016 - http://php.net/archive/2013.php#id2013-06-20-1 and https://wiki.php.net/rfc/releaseprocess#releases_cycle

5.5 would cover us for quite a while to come.

cvillian098’s picture

cvillian098 commented

How big is the impact if Drupal 6 is still supported but PHP 5.3 still isn't?

rooby’s picture

rooby commented

Well it means that if security flaws are discovered in PHP < 5.4 then those aren't fixed and become a possible way that your system can be compromised.

It's up to the site administrator as to whether they think this is a big bad issue or something they can live with.

rooby’s picture

rooby commented

The main issue is who will do the work.

It's most likely that people will just fix bugs and (maybe) post back patches as they encounter problems, which is good but there is no way the community can claim any sort of 5.4 or 5.5 support level with such a system.

Maybe some sprints for major modules would help, or some other sort of general community push to try to encourage maintainers to get their modules compatible.

I don't have the answer I'm just spit-balling.

steinmb’s picture

steinmb commented

I do not think supporting Drupal 6 core on PHP 5.4/5.5 would be very difficult. For what it is worth. I have D6 sites on on PHP 5.4/PHP 5.5 and core work just fine (as far as I know). Patches fixing any issues should at least be accepted by the D6 maintainer(s), though I do not know if we have an official stand on this? D6 will stick around for quite a long time though the application stack is getting modernized around/under it.

3 part modules is another story. Maintainers should at leas welcome patches that silence warnings/fixes issues. As mention in a comment above, Views is one great/bad example on this. It works (more and less) on PHP 5.5/5.4 but it huff and puff a lot. Work have been done (by me and more) providing patches to Views that addresses. I have also asked, if a we could have 6.x major that could contain PHP 5.4/5.5 fixes, but up to now have they been quite unwilling and/or very busy. I know that about all of them are very busy getting views in D8 core ready, so even getting patches for views 7.x have proved to be difficult/slow. So do we want prolonged D6 support do we have to step up as co-maintainers. At least on some of the important 6.x modules that are minimum maintained.

@steinmb

abdobasha2004’s picture

abdobasha2004 commented

yes that is true, in many cases some servers are not ready for a php version for a security or mod added, so it is always better to support older versions.

BigMike’s picture

BigMike commented

thinkyhead,

Thank you very much for this post. About a week ago my WHM/cPanel updated itself and locked me out of phpMyAdmin unless I upgrade to MySQL database of 5.5 or higher. I've been ignoring it but yesterday I needed to get into our database and finally had cPanel update us to SQL 5.5.

Process went perfectly smooth and things seemed entirely normal until I went to edit a node and received a WSOD. Reloading a different page gets this error:

warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'node_page_edit' not found or invalid function name in /home/SITENAME/public_html/includes/menu.inc on line 350.

Line 350 of my menu.inc is within the function menu_execute_active_handler() as follows:

345  if ($router_item = menu_get_item($path)) {
346    if ($router_item['access']) {
347      if ($router_item['file']) {
348        require_once($router_item['file']);
349      }
350      return call_user_func_array($router_item['page_callback'], $router_item['page_arguments']);
351    }
352    else {
353      return MENU_ACCESS_DENIED;
354    }
355  }
356  return MENU_NOT_FOUND;

After pulling out most of my hair and having a pretty crummy evening I discovered that during the SQL upgrade the server automagically updated it's PHP from our longstanding 5.2-branch to now 5.3.29.

Looking up call-user-func-array(), indeed it has changed in PHP 5.3+
See http://php.net/manual/en/function.call-user-func-array.php

Can anyone shed some light on how to patch this for now? We are still using D6 because a few modules we need and that I've contributed to are not ready for D7 yet (should be ready this winter).

I did a dump on $router_item and call-user-func-array() is working for
node_page_view, drupal_get_form, and statistics_node_tracker page_callback's but not working for node_page_edit or node_add.

Anything that uses drupal_get_form is fine, which so far I've tested creating and editing both blocks and taxonomy and both function as expected.
So for kicks I intercepted 'node_page_edit' and changed it to 'drupal_get_form' and now my node edit pages load -- no longer white screen of death -- but have a ton of other errors and nothing useful is outputted to the screen.

We also get an error on our Clone page (Clone module v6.x-1.3),

warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'node_form' not found or invalid function name in /home/SITENAME/public_html/includes/form.inc on line 421.

which in form.inc is...

419  // If $callback was returned by a hook_forms() implementation, call it.
420  // Otherwise, call the function named after the form id.
421  $form = call_user_func_array(isset($callback) ? $callback : $form_id, $args);

Dumping $callback here and it's an ordinary string of value "node_form".

So I need to figure out how to manipulate call_user_func_array() for use under PHP 5.3.x. There are a few tips on the php.net site but so far I can't figure it out.

Any help is GREATLY appreciated! Our website is http://www.marlincrawler.com and most things are working as they should. Not being able to edit content isn't the end of the world as we can do that in the DB, but we need to be able to create content and not having this feature is a critical issue for us.

Regards,
BigMike

rooby’s picture

rooby commented

Check out the error messages on google, there are a lot of hits and they might help you out.

For example: https://www.google.com.au/#q=warning:+call_user_func_array%28%29+expects...

You might find drupal.org issues, stack exchange pages, blog posts etc. that may help.

This post is for discussing the overarching issue of Drupal 6 on new PHP versions, not debugging individual errors.

BigMike’s picture

BigMike commented

Thank you for the reply. Sorry for thread jacking. I've already searched Google for a few hours. Still trying to figure this out.

Mike

rooby’s picture

rooby commented

If you haven't already, post your question to http://drupal.stackexchange.com/ as well as the drupal.org support forum.

If you have multiple questions though break them up, don't put them all into one big question or you're less likely to get people answering.

BigMike’s picture

BigMike commented

Thank you again for the advice. Posting to SE now!

Regards,
BigMike

iantresman’s picture

iantresman commented

Can modules:

  1. Be tested automatically for compatibility with PHP 5.4 (or even PHP 5.x)
  2. Display an icon showing their compatibility status?

This might encourage maintainers to make the necessary tweaks. A link to a page suggesting what might need to be done, may save maintainers a lot of time.

drupalinthailand’s picture

drupalinthailand commented

Hello,

Maybe someone here can help me to fix this short code ? My shop ADD TO CART big button does not work anymore with php5.6:

https://www.drupal.org/node/2679094#comment-10913792

Thanks again.