See https://twitter.com/Ustima/status/403186681529896960

Oops. Almost broke #drupal6 support for PHP4. *Again*.

A patch for Drupal 7 got backported to Drupal 6 with some php5-isms in it and was in needs review for a while. Nobody noticed.

Why do we support PHP4? Especially for security issues it feels foolish to make Drupal secure on a platform that itself is inherently insecure.

Potential impact

In theory there might be people using php 4. According to some statistics from a web scraper usage of PHP 4 is less than 2.7% of the sites running php. This indicates that the potential for impact is very small.

Proposal

In the next release of Drupal 6 (December 18th? January? Beyond?) we change something to make it stop working on php4. And then we can stop worrying about our backports.

  • Tweet from @drupal?
  • Post to groups.drupal.org/core?
  • Module developers should start adding a php=5 to their .info files? and can feel free to start using php 5.x specific features

We would need to also update requirements and php requirements.

Comments

Issue summary:View changes

Is there any possible way that updates.drupal.org could help us with this? Like do we maintain any record of the sites update status module pings are coming from so we could pull data like this http://wordpress.org/about/stats/ ?

I think it would be very reasonable to add in some ability to do analysis like that (including php version, webserver type/version, and host OS version). I don't think we currently get enough info to know what version of php someone is running.

Darn. Had to ask. :)

Anyway, seems according to http://php.net/eol.php that PHP 4 was EOLed approximately 5 years ago. Those WordPress stats, which encompass ~20% of the web, esp. the cheapest of cheap shared hosting, seem to imply that it's pretty dead.

I'd recommend doing it a few months out, e.g. January at least. Also bumping this kind of change to next year changes it from a "Drupal is dropping PHP4" thing to "Drupal is dropping PHP4 in 2014", which IMHO is a much catchier soundbite.

+1 - This seems like a reasonable approach.

+1 from me, too. The WP numbers, as well as http://w3techs.com/technologies/details/pl-php/all/all, seem to imply this is only going to affect a very tiny subset of sites.

I'd only move the date out a bit, say, to Jan 15 (Drupal's birthday ;)) because if someone is trapped in this situation, it's kinda shitty to give them a huge unplanned migration for the holidays. :P~

EDIT: oops. I thought Jan 1 was being proposed. Nevermind then. :)

I can imagine some sites out there still running PHP 4. I can't imagine them upgrading to the latest core release in a timely manner each time. So even if we break it, they've got the choice to stay on an older release or change their hosting.

However I don't think it's worth breaking PHP 4 support on purpose - we can just not care about it, but if it's possible to run Drupal 6 on PHP 4 for another year, then that doesn't make much difference.

The reason to break it is so we can stop thinking about it. As long as it works people will want to keep it working.

I'm not insistent on that point.

I'd only move the date out a bit, say, to Jan 15 (Drupal's birthday ;))

Drupal 6.0 came out Feb. 13, 2008, so if we're willing to wait till February's release window, that will have meant 6 years of 6x support prior to raising requirements.

However I don't think it's worth breaking PHP 4 support on purpose

Per #1498574-129: [policy, no patch] Require PHP 5.4 and #2135203: Compile a list of all known PHP 5.4 incompatibilities D6 and D7, we will need to break PHP 4 support at whatever time we want to commit the first fix to a PHP 5.4 incompatibility that is impossible to do without PHP 4 choking. Semi-separate issue perhaps, but just mentioning it, especially if that influences opinions on whether February isn't soon enough.

I think it would be very reasonable to add in some ability to do analysis like that (including php version, webserver type/version, and host OS version). I don't think we currently get enough info to know what version of php someone is running.

Funny… In the shower this morning, I had the same idea. Also useful to track would be ini_get('memory_limit'), the database driver used and version of the database server, and whether the server is a shared host, a VPS or a standalone server - though I have no idea how we'd programmatically determine that.

For better or for worse, that kind of information would be quite useful for providing real-world data to influence future decisions about the direction of both core and contrib projects.

module.info files can have a php line. https://drupal.org/node/231036

Anyone with enough grep-fu to come up with a low-water mark for all of D6 contrib?

Title:[Policy] Stop supporting for PHP 4[Policy] Stop supporting PHP 4

Fixing title grammar...

I imagine the majority of Drupal 6 modules specify no PHP version and thus claim to work on PHP 4.4, but in practice would run on 5.4 or 5.4 just fine. I don't think the number of modules that specify a version will tell us much that is useful.

Issue summary:View changes

Actually, grepping contrib seems super relevant to know if modules require a specific a php version number.

Here's the frequency of a specific version provided by webchick which is for all modules using a "If a 7.x branch exists, use that, if not 6, if not 8" method of getting the files (with dev checkouts used unless it is missing but a stable version exists within the major version number). https://gist.github.com/webchickenator/6bb4262e54fec7c772a3

I did some analysis of the 11,877 modules in the allmodules of gdta. I specifically downloaded only the 6.x versions which totals 7,158. I grepped the info files and extracted those that require at least 5*. There are 758 projects that have at least one submodule that matches that description, so about 10% of them specifically say that they require PHP5*

I then compared those to the 500 most popular modules for 6.x. So, here's the list of projects that have one module that requires 5* in order from least to most popular by usage:

  • uc_bank_transfer 5 1826 1826
  • quiz 5 1838 1838
  • mailsystem 5 1936 1936
  • charts_graphs 5 1951 1951
  • plugin_manager 5 1963 1963
  • disqus 5 2107 2107
  • uc_addresses 5 2167 2167
  • advagg 5 2224 2224
  • dbtng 5 2232 2232
  • faceted_search 5 2232 2232
  • cas 5 2240 2240
  • options_element 5 2267 2267
  • potx 5 2345 2345
  • fontyourface 5 2425 2425
  • views_datasource 5 2580 2580
  • css_gzip 5 3264 3264
  • htmlmail 5 3306 3306
  • htmlpurifier 5 3612 3612
  • translation_overview 5 3946 3946
  • feedapi 5 3981 3981
  • parser_ical 5 4060 4060
  • javascript_aggregator 5 4369 4369
  • views_groupby 5 4648 4648
  • video 5 4739 4739
  • apachesolr 5 4838 4838
  • chart 5 6671 6671
  • oauth 5 7151 7151
  • ldap_integration 5 8154 8154
  • service_links 5 8293 8293
  • twitter 5 8428 8428
  • node_import 5 9251 9251
  • notifications 5 10048 10048
  • dqx_adminmenu 5 10064 10064
  • flag 5 10074 10074
  • views_fb_like 5 10179 10179
  • views_periodic_execution 5 10529 10529
  • masquerade 5 11147 11147
  • fb 5 11510 11510
  • feeds 5 12890 12890
  • job_scheduler 5 14161 14161
  • autoload 5 15815 15815
  • admin 5 19137 19137
  • mollom 5 19268 19268
  • ubercart 5 20425 20425
  • mimemail 5 23316 23316
  • l10n_update 5 25503 25503
  • emfield 5 27876 27876
  • calendar 5 37589 37589
  • views_bulk_operations 5 40650 40650
  • rules 5 43119 43119
  • xmlsitemap 5 52639 52639
  • webform 5 84914 84914
  • imageapi 5 132391 132391
  • filefield 5 142810 142810

So, filefield at 142,810 and webform at 84,914 and xmlsitemap and rules and...even if we assume 90% overlap in those sites that becomes a pretty large percent of the 206,090 sites running Drupal6.x.

Not that we really needed yet more evidence but...there it is.

(P.S. for anyone interested, here's how to find 500 most popular 6.x projects: select pu.nid, pu.count, mn.field_project_machine_name_value from project_usage_week_project pu inner join field_data_field_project_machine_name mn on pu.nid = mn.entity_id where tid = 87 and timestamp = 1384646400 order by count desc limit 500;)

Next steps

I proposed some next steps in the issue summary about how we can let people know this change is coming. Anything else we should do? Do any of those not make sense?

Assigned:Unassigned» Gábor Hojtsy

Would be good to get Gabor, the D6 maintainer, on board with this, so assigning to him for feedback. He was -1 in #2136029-9: Decide if and how to extend D6 security support 6-24 months past an 8.0 release, but that comment was comparing PHP 4 and PHP 5.3, whereas I think here we're only suggesting raising to 5.2, to match D7.

Yeah I think making any change in Drupal 6 land may result in who knows what unexpected side effects, but if this is the community decision, we'll communicate it as such.

I agree with catch and Gábor - please do not break PHP 4 support on purpose unless there's a really good reason. The numbers suggest we're talking about a potentially significant number of affected websites.

I think we should just be honest in documentation; presumably nobody on the security team actually tests patches against PHP 4 anymore, but we do read through them and look for obvious problems (like calling a function that is only available in PHP 5). So far it doesn't seem like there have been any serious issues in practice, so why waste time and cause problems by pushing out a major change like this?

I read through #2135203: Compile a list of all known PHP 5.4 incompatibilities D6 and D7 and so far I don't see anything there that would require dropping PHP 4 support.

@David_Rothstein:

The numbers suggest we're talking about a potentially significant number of affected websites.

Which numbers? I don't see any sources of data that suggest a significant number and, as catch pointed out in #8, these people are not the kind of people who will be upgrading Drupal 6 core in lockstep with the official releases.

Yeah, I'm also confused about what numbers. WordPress is a project with far more marketshare than we have, with far less technical of an audience, who generally runs on far shittier hosting than your average Drupal site does, and even for them PHP 4 is a non-issue these days.

I used the numbers from the issue summary: 2.5% of PHP sites on PHP 4 multiplied by 200,000 (known) sites running Drupal 6 = 5000 sites.

There are a number of reasons WordPress would be expected to have lower PHP 4 usage than the Internet as a whole: (a) the average WordPress site is pretty new (certainly much newer than the average Drupal 6 site), (b) WordPress dropped support for PHP 4 over 2 years ago (shortly after Drupal 7 did) so the only WordPress sites still on it are ones that literally never update, (c) WordPress is more likely to be hosted on large-scale managed hosting than Drupal is, and those environments typically make it very simple (like press-a-button simple) to update your PHP version. Custom hosting is where it gets more complicated.

as catch pointed out in #8, these people are not the kind of people who will be upgrading Drupal 6 core in lockstep with the official releases.

I don't necessarily agree with that. People still on PHP 4 might be there because (a) they have lots of custom code they don't have time to rewrite for PHP 5, or (b) they are in a hosting environment that they don't control. Not necesarily because they don't ever want to update anything.

I've certainly been in the situation of (b) but still had good reason to keep Drupal core up to date. That was a while ago, and I don't manage the particular sites anymore, but it wouldn't surprise me if they were still on PHP 4... however, these are also Drupal 5 sites :)

Another option here would be that, assuming extended Drupal 6 security support happens (still a big assumption), dropping PHP 4 support for Drupal 6 could happen in conjunction with the Drupal 8.0 release, rather than at a random time beforehand... That way at least people get that support for as long as they originally thought they would.

However, I still don't see the point of deliberately forcing PHP 4 incompatibility in the code, unless there's a specific reason to.

I agree that there's no compelling reason to forceably break PHP 4 compatibility just to prove a point. That said, ignoring PHP 4 compatibility for Drupal 6 is something we should probably have done a while ago.

Assigned:Gábor Hojtsy» Dries
Status:Active» Needs review

I don't necessarily agree with that. People still on PHP 4 might be there because (a) they have lots of custom code they don't have time to rewrite for PHP 5, or (b) they are in a hosting environment that they don't control. Not necesarily because they don't ever want to update anything.

There are 82,000 Drupal 6 sites on the latest point release, and over 100k sites on a release more than 18 months old.

I'd personally be extremely surprised if a large number of those 82,000 sites are running on PHP 4, but announcing a cut of date for PHP 4 support very publicly may or may not flush them out to comment.

Since Gabor is OK with this in principle, I think it's time to assign to Dries.

This is how I'd summarise the discussion:

Mostly agreed:
Drop PHP 4 support from Drupal 6 at some point.

Not agreed:
When to drop support (asap? when 8.0 comes out?)
Whether to arbitrarily break PHP4 so that 6.x can't run on it at all, to force people to upgrade.

For the record I think setting a date like 31st January 2014 would be better than when 8.0 is released, since we haven't even figured out what 6.x support looks like in general when 8.0 is released, and that doesn't give people a time frame to make the change if they need to.

I'm not really into intentionally breaking PHP4 support on 6.x, but if we happened to do so when PHP4 support is dropped as a side-effect of another fix I wouldn't mind either.

Assigned:Dries» Gábor Hojtsy
Status:Needs review» Reviewed & tested by the community

Sounds like the data gathering done shows that this is a reasonably safe thing to do, as long as we give people a heads-up about it.

I say we stop supporting PHP4 on March 1, 2014. This gives people more than 3 months to migrate.

I disagree with intentionally breaking PHP 4 support outside the version requirement change, however we should set the new minimum PHP version to PHP 5.2.4 (the same as Drupal 7) at that time.

This policy change will need to be announced on http://groups.drupal.org/core, @drupal, the Drupal project page, the Drupal.org home page, and the Drupal requirements page. Probably makes sense for Gábor to do that as the Drupal 6 maintainer.

Assigned:Gábor Hojtsy» Unassigned
Status:Reviewed & tested by the community» Fixed

Drupal.org front page post: https://drupal.org/node/2159315
Groups.drupal.org/core post: https://groups.drupal.org/node/390343
Change to system requirements for now: https://drupal.org/node/270/revisions/view/6707063/6785841
Change to PHP requirements page: https://drupal.org/node/1783062/revisions/view/6707069/6785863

I'm not sure there is a way that makes sense to announce this on the Drupal project page.

I also don't have access to @drupal to post, so help welcome for that :) Probably post the front page link (https://drupal.org/node/2159315) there.

Thanks, Gabor!

I used the form at https://association.drupal.org/node/18708 to request a tweet go out soon and then again once per month until March 1st.

Tweets scheduled on @Drupal. Thanks for using the form!

I run a D6 site on a dedicated machine running PHP 5.2.6 and I tried to bring up a D8 test site and failed for having too old a PHP. We are porting to D7 which runs fine on this PHP, but are now considering going direct to D8 and skipping D7 because porting a complex site to it is very hard and don't want to have to do another port any time soon.

I think it is possible to have both the current PHP and one new enough to run D8 on the site and use some .htaccess hack to determine which PHP to use.

It would be useful to know what PHP is the newest that will run a D6 site Perhaps mine would run on a newer version.

yktdan: The plan is to have a Migrate-based process for moving from D6 straight to D8 rather than the increasingly-unreliable in-DB upgrade scripts. Work on that is in progress. It may not be done by 8.0, but it will be done, as will a Migrate-based D7->D8 transition. If you're not dying for some D7 feature I'd recommend waiting.

If you have the bandwidth to help make that happen, more strong hands are always welcome: https://groups.drupal.org/imp (It might really help to use your existing site as a migration guinea pig, actually.)

I think his actual question was more around how to run competing PHP versions on the same hosting environment. That sounds like a question best directed to your host, though many of them allow you to have different PHP versions in different docroots, so you could leave your D6 site running at ~/www/d6 (PHP 5.2.6) while you build out your D8 site at ~/www/d8 (PHP 5.4.2), and flip the domain once the migration is complete.

Actually both answers are interesting. So yes I will contact host to see how to do dual PHP versions.

We have 3 volunteers who run the site, but none of us are strong PHP coders, all dabble. But definitely interested in making migration run smoothly as we have given up on making update work. The hangups have been views, og (with panels) and ubercart to ecommerce. Views is mostly understood - the upgrade process leaves them broken and each has to be fixed up (not hard -just tedious). Also need to go mobile at the same time (obnoxiously fixed width theming). I am following IMP.

Status:Fixed» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.