Fix all known PHP 5.4 incompatibilities on D6 and D7 that are critical or would prevent a migration to D8

#1543434: strict warnings with PHP 5.4.x
#1833170: strict warning: Non-static method view::load()
Well, there are thousand more of these issues, but as chx wrote before, it is not possible to fix. Php4 don't know of the static keyword.

I'm sorry but I can't help it.. if there is, do you think there's *any* chance they could find their way into this issue and let us know? :)

From a testing perspective:
D6 running on PHP 5.4: https://qa.drupal.org/pifr/test/600313
D7 running on PHP 5.4: https://qa.drupal.org/pifr/test/600308

Get real. Thanks.

Eighteen months ago:
https://drupal.org/comment/6061922#comment-6061922

Hmmm. :)

@chx, the goal of this issue is to allow migrate to work for D6 to D8 on the same environment, which would mean ensuring D6 ran on 5.4. It's the result of 15+ minutes of discussion with Dries, effulgentsia, Moshe, and myself. If you think it's not possible, please explain why rationally and ideally suggest a workaround.

Migrations need access to a database and the files folder, why would we need a "working instance" of the D6/7 site?

Of course it's not possible! Who is going to spend hours and hours clicking around in D6 to make sure nothing is broken? (Our beloved manual testbot has more important duties these days, like, Lily. Or D8 commits. Or one of the billion other things webchick does.) And what D6 install at that -- you would need to make the entire D6 contrib space 5.4 compatible if you want this and that's just sheer madness. If you think, oh we will just deal with the most important modules, don't forget that the 20% that 80% of the sites use is a different 20% for everyone.

One workaround would be to tell D6 people to migrate on a local host where they either set up two PHPs or provide a module (I would call it insecure) which would run queries from the HTTP request (could be IP restricted for some minimal security). Install that on D6 and migrate to a new server without needing to mess with MySQL, firewall and such.

the goal of this issue is to allow migrate to work for D6 to D8 on the same environment, which would mean ensuring D6 ran on 5.4.

To slightly rephrase, it just means that the functionality that migrate uses runs on PHP 5.4 without fatal errors or data corruption. Does that make it much easier?

To slightly rephrase, it just means that the functionality that migrate uses runs on PHP 5.4 without fatal errors or data corruption. Does that make it much easier?

Yes, exactly.

What? This contradicts the issue summary:

It would suck for D6 site owners to need a 2nd server / hosting account, or a server / hosting account that allows multiple simultaneous PHP versions, in order to migrate from D6 to D8 while still keeping their D6 site live until the migration is done.

emphasis mine.

If you don't want to keep the D6 site live then what are we even talking about? Migrate will do everything and you don't need a D6 site running

I think the goal really is "Make sure Migrate works as expected for D6 users in light of the 5.4 requirement." How do we let those D6 users on shared hosting do their site migrations without taking the site down for days? That's the question we should try to answer.

The Views issue linked is about E_STRICT. I don't think we care about E_STRICT for sites that are in the progress of migrating.

It probably is an issue for 6.x support past 5.3 eol but even then...

Do we really want to divert attention from D7/D8 back to D6 to make this work? Do we expect contrib devs to divert attention from their D7-D8 ports to see if there are major issues with D6 bugs? Or, more realistically, expect they stop ignoring the bugs related to their D6 module versions?

We don't currently have test coverage for D6 - this has been the reason I've been given for dropped patches related to D6.

I wonder what's changed?

Are we willing to divert D.O resources from D7/D8 and go back and build that test coverage for D6? Or are we going to invest in a vast human army and do that manually?

Or are we committing to breaking thousands of D6 sites so they've got no choice but to upgrade?

Bob can buy a second account for a few dollars for a single month it takes to experiment. We already spent more than all of those dollars in developer time debating this. D6 is dead, leave it dead and move on.

There was 24 hours of downtime upgrading d.o for 8.x7.x For sites that absolutely can't manage two environments to upgrade they'd likely have some downtime and more likelihood of unrecoverable errors with hook_update_N() anyway.

We have no idea how many functional bugs there are with 6.x contrib and 5.4. Those exist already so I think it's ok for them to get flushed out.

If there's unresolvable issues with this, then I don't think the following workflow is that bad:

1. Get new hosting and set up 8.x

2. Do the migration from 6.x

3. Update DNS and shut down the old hosting.

There's also the option to upgrade to 7.x then skip to 9.x next time, where we know we have reasonable test coverage on 7.x

Absolutely. That's what I suggest. Drupal 6 is absolutely, totally dead, if we poke at it, we will break it, guaranteed. Then we will need to make another release fixing the bugs in the release-for-PHP-5.4... The time we spend on all this is an absolute waste.

The safest way to migrate from DX -> DY is to do it off of your live server. We tell people that every time they ask. Leaving a PHP 4 server with Drupal 6 in place until the D8 site is "ready" seems entirely reasonable to me, as does freezing content for a day or two while switching over. I don't think anyone expects a D6->D8 upgrade to be simple point and click, certainly not in production. (At least no one who has lived through a core upgrade, ever.)

So yes, the target here should be "make sure the migrate strategy is still stable with the 5.4 requirement for D8", not "Drupal 6 is bug-free on 5.4."

That said, we probably should try to make sure D7 runs smoothly on PHP 5.4, since that's a much shorter jump version-wise.

I cross posted with chx in #21 but yes exactly.

So I think this issue boils down to two things:

1. Document a cheap and reliable way for someone on a very restricted shared hosting account with only enough knowledge to install and configure a Drupal site to do a migration, if they don't want to risk running 6.x on 5.4 or if their site actually breaks with 5.4. This boils down to "Set up a completely new 8.x site on a different server then point the migration configuration at the 6.x site)." It might also include niceties like https://drupal.org/project/maintenance_helper which lets you keep the 6.x site 'live' but frozen. (Side note, Drupal.org probably could have used that too).

2. Critical Drupal 7 bug reports for failures on 5.4 - since we're supposed to support 5.4 (and 5.5, and probably 5.6 too) with 7.x anyway, that's nothing new really.

By the way, making real Drupal 6 sites run on PHP 5.4 requires making custom modules and themes run on PHP 5.4.

Are there real issues here, or is this a theoretical concern? So far it seems like the main known issues are E_STRICT warnings and the like (for Drupal 6), which isn't a big deal and could also be fixed by #1954296: Restore original D6 behaviour to prevent logging E_STRICT warnings.

There's already a partial list of PHP 5.4 issues at https://drupal.org/project/issues/search/?issue_tags_op=%3D&issue_tags=P... (across all Drupal projects) and it doesn't look that bad. Especially because some of them (like #1525176: Using array_diff_assoc() for multilevel arrays in DrupalDefaultEntityController->cacheGet()) aren't even PHP 5.4-only bugs, but rather functional bugs which exist on other PHP versions too (but PHP 5.4 is just noiser about them).

Tagging, since 5.4 and 5.5 are closer than 5.3 and 5.4, I believe.

Since 16 December 2013 I'm running several Drupal 6.24 sites on PHP 5.4.

All are simple websites with 2 running internationalization (6.x-1.10) with 6 languages. The contact form uses CAPTCHA 6.x-2.4, Contact save 6.x-1.5 and Webform 6.x-3.18.

The rest is pretty much standard stuff.

So far i see the following PHP errors

webform - https://drupal.org/node/2157759
i18n - https://drupal.org/node/2157743

No idea yet what i'm facing upgrading Drupal 6.24 to the latest Drupal core.

For testing i used a host that allowed switching between PHP versions using a .htaccess switch between PHP 5.2 - 5.3 - 5.4.

Anyhow - so far so good. It would be great if Drupal 6.x would support PHP 5.4 because there's no pressing reason for me to upgrade to Drupal 7. Also one of the sites uses a theme that's unsupported in D7.

Until there's documented critical issues with PHP 5.4 on 6.x/7.x, doing this.

Hi, I'm Bob.

Well, not really, but I'm in a situation pretty similar to the Bob described in #14. My site runs on 6.15. I haven't updated it in two years - basically was just going to let it run until my hosting ran out then shut it down. I spent quite a bit of time building it 3-4 years ago and it has been running smoothly ever since. Couple of hundred people still use it regularly. Life distracted me, which is why I haven't been paying too much attention.

Anyway, as I have let some members know that the site will likely be put down in the not-too-distant future I have been urged to reconsider and even to expand the site. Seems I have some loyal users who see a future and are committed (or at least they claim to be committed) to marketing it to a larger group.

So, I've started looking into a migration to Drupal 8.

I do want to keep the current site live until the new site is ready. I moved once from Drupal 5 to 6 and remember that being a major headache because I built the D6 site on a LAMP stack and had to adjust what seemed like a million configuration items once I actually moved the files to the shared server. I was hoping to reduce the frustration/complexity this time by building the new site on my shared server and basically just redirecting my url when the time comes. But if I'm reading this thread correctly, it seems like that might not be possible.

Of course, I don't expect major work to be performed on D6 just for my benefit. My question at this point is, would those of you who have more expertise than I suggest:

1. I develop on a LAMP stack again, or
2. I edit my HostGator htaccess file so as to upgrade to 5.3/5.4/5.5 (which one, all are offered?) and see if my current site still works ok?

From what I'm reading, it sounds like upgrading to php 5.4 might not break my current site, but then again it might. I suppose I could upgrade, test a little, then downgrade again if it breaks, but I would be curious to hear your expert opinions.

Thanks.

@intent: If you have the option, stick with 5.3 and disable the STRICT messages.

As written this issue could never be fixed. I've therefore rephrased the title to more accurately reflect the business concerns discussed above.

There are currently 12 D8 issues, 5 D7 issues and 16 D6 issues tagged PHP 5.4 across core and contrib.
https://www.drupal.org/project/issues/search?projects=&project_issue_fol...

Of the D7/D6 issues, two are marked critical
#2248783: WSOD in PHP 5.4: Call-time pass-by-reference has been removed in a module that has no supported release because it's dependencies are unmaintained. It does not look like it would cause any difficulties when using Migrate.
#1774796: Plan for Panels v6.x-3.11 release (PHP 5.4 fix) which was a one character fix committed 3 years ago, but has not been released because the module (Panels) is not being maintained on D6.

Unless there are other issues that I haven't found, I think we can consider this fixed.

This should be fixed, so we can test and fix failed tests https://www.drupal.org/node/1867192

That's already a Drupal 8 release candidate blocker, so I think we can go ahead and mark this fixed. If a new issue comes up, can always re-open.

(Just setting issue priority for historical purposes based on discussion with @Dries, @alexpott, @webchick, @catch, and @effulgentsia.)