DATE_RFC7231 already defined in PHP 7.0.19 and 7.1.5

In what way does this qualify as critical priority?

You wrote that it's a notice. I did not infer "site is unusable" from that.

This exact issue causes a fatal error, not a notice, in our project.

This seems like a straightforward enough quick fix, regardless of the priority level. Strictly speaking we could make it a const, instead of a define(), but the difference is marginal so... RTBC.

Strictly speaking we could make it a const, instead of a define()

@Crell
We cannot make it a const as that syntax (outside of class context) is only supported since PHP 5.3.0 (see http://php.net/manual/en/language.constants.syntax.php) and Drupal 7 officially still supports PHP 5.2.5+ (see https://www.drupal.org/docs/7/system-requirements/php#php_required).

Ah, you're right, I didn't notice the version was set to 7. Still RTBC.

For PHP 7.1, same issue doesn't happen on PHP 7.1.4 but does happen on PHP 7.1.5 (which was released on 5/11, the day before yesterday). The patch file included in #2 does fix the issue for PHP 7.1 as well.

path in #2 fixed it for me also (php 7.1.5)

#2 works for me on PHP 7.1.5 and mysql 5.7.18

Patch #2 fixed my site too (PHP 7.0.19). It was completely down, so it's critical fix for PHP7 users.

#2 works on 7.0.19

Fixed my D7 site too. +1 on RTBC.

Another +1.

@failcookie , what warning are you speaking of? Does this occur after having applied the patch from comment number 2?

The patch looks good, but let's add a code comment which explains why we need to do this. See attached for a possibility.

I am confused how this could cause a fatal error on anyone's site (since it's just a PHP notice).... It certainly didn't for me. However, it occurs early enough in the bootstrap that the notice won't get picked up by Drupal's error handler, which means it might be displayed on the screen to end users regardless of the site configuration, plus (for some reason I don't understand) a notice this early also interrupts the installer and prevents it from running... so critical priority seems correct.

This can go into the next regular bugfix release (rather than specifically waiting for Drupal 7.60).

I checked Drupal 8 and it uses Drupal\Component\Datetime\DateTimePlus::RFC7231 instead, so it shouldn't have a similar issue.

The added comments are helpful easy to understand.

Thanks :)

Patch #26 applies OK on Drupal 7.54 and fixes the issue.
Cheers!

Also checked and tested patch #26 - working like a charm! Should be ported - nice job!

This occured to me on Windows with apache 2.4 and PHP 7.1.5, although the notices were supposed to be hidden by my PHP settings. The patch #26 fixed it.

#26 worked for me - thanks!

I just triggered two retests for php 7 and php 7.1.

something changed with the testbot php 7 config since Feb 1 2017 when head passed?

Here is the Feb 1 2017 - head test for D7 with php 7

Perhaps the simpletest configuration had it's php 7 version(s) (7 and 7.1) changed?

haven't yet looked closely at the test results, just making an observation for now

Reproduced with PHP 7.1.5
Applying #26 fixed it.
Thanks

edit: this is a fairly simple fix (I can't think of any regression implied by it), therefore it would be (very) nice to have it in the next bugfix release, than waiting for 7.60

Drupal core should never have declared a constant without a Drupal namespace. Users are going to hit this bug whenever they update PHP to the latest stable version(s), and it will break their sites.

So, I agree, this really should be included in the next release of core, whatever that may be.

Drupal core should never have declared a constant without a Drupal namespace.

Ha, maybe not, but there are like 200+ examples of that in Drupal 7 core, and 100+ in Drupal 8 core already :)

I just triggered two retests for php 7 and php 7.1.

something changed with the testbot php 7 config since Feb 1 2017 when head passed?

Hm, I'll rerun the HEAD tests also to see if those fail on PHP 7 too. (The failures in the patch test are date-related, so it's at least possible it has something to do with this patch. On the other hand, the testbot seems to be running PHP 7.0.18 currently.)

It turns out the PHP 7 test failure is in HEAD too (https://www.drupal.org/pift-ci-job/676235) so I guess that's a separate regression due to some other post-release change in PHP 7 and probably needs a separate issue to look into.... Any of the people active in this issue would be welcome to help with that since you're already running PHP 7 :)

The patch here is therefore probably ready to commit.

Another +1 RTBC from me. New server is outputting the notice at the top of every rendered page; glad I caught this before upgrading my prod server!

I've just come across this issue on my new dev server running php 7.1.5 and the patch in #26 looks to solve the problem for me, thanks for the fix.

In my case as well as posting the warning when viewing general pages it also breaks things like module update admin interface.

It turns out the PHP 7 test failure is in HEAD too (https://www.drupal.org/pift-ci-job/676235) so I guess that's a separate regression due to some other post-release change in PHP 7 and probably needs a separate issue to look into

Turns out that was already fixed in Drupal 8 but never backported to Drupal 7. I made an issue and patch to backport it now: #2880700: [D7] UserTimeZoneFunctionalTest fails on recent versions of PHP 7 and 7.1

#26 works fine for me as well!

#26 is good please commit

#26 works for me on Drupal 7.54 and PHP 7.0.19.

Hi,

I don't think D7 is still being taken care of... sadly, so, better add this patch to your makefiles ;-)

@pol, better yet, lets fork D7 and let's take this off of drupal.org, make a new update module that pulls from Github instead.

I don't think this is a good idea... even if I would prefer to work on Github :-)

"Forking" Drupal 7 would makes things even more messier.

I just hope one day some people will just take care of D7 for the millions of sites yet running it.

The best frustrating example is: #1545964: Do not copy over the owner and engine of a theme if the child theme uses a different engine than the base theme

The patch here is therefore probably ready to commit.

Can anyone confirm whether there will be a release of Drupal 7 in the bugfix release window next week, and whether this patch will be part of that release? Since this blocks upgrades to php 7.0.19 and 7.1.5, it would be helpful if this could go out then.

Are there any other issues that might block a Drupal 7 release next week?

I also confirm #26 works.

Yes, this should go out in the next monthly release window (i.e. next week). I'm planning to do some commits tomorrow.

Great :)

#26 is OK for me too.

Also I can confirm that the patch in #26 is working fine!

++Dave_Rothstein Thanks so much.

Committed to 7.x - thanks! This will go out in the next monthly release window (scheduled for June 7).

I don't think D7 is still being taken care of.

@Pol/others: Most people listed in the Drupal 7 MAINTAINERS.txt file are no longer active. However there are 3 core committers who are active. I've been involved in this issue, and others have been involved in other issues (including the one you linked to, which I just reviewed now also and which is not ready to commit for a number of reasons, including the fact that it appears to still need fixing in Drupal 8 which was discussed a few times in that issue's history).

As far as I know, we're all essentially doing this in our free time, and I haven't heard of any organizations or website owners who are interested in sponsoring Drupal 7 maintenance work. So, thanks for your patience - and your contributions :)

#26 works for me. (Drupal 7.54, php 7.0)

#26 works for me. (Drupal 7.56, php 7.1.5)

#2 patch works for me in PHP 7.0.20. Thnx.

+1 for 7.54 with PHP 7.1.7
+1 for 7.56 with PHP 7.1.7

#26 worked for me
Drupal 7.54 PHP 7.1.11
thanks!

@David_Rothstein #26
Worked for me on PHP 7.1.11
Thanks

Un-hiding the patch

FYI: this was committed prior to the 7.55 release so the fix is already in 7.55 and 7.56.

Karoop, #2 is fix this error on php v7.0 also..
thanks

#2 Solved the issue for me.

I don't think D7 is still being taken care of... sadly, so, better add this patch to your makefiles ;-)

...

@pol, better yet, lets fork D7 and let's take this off of drupal.org, make a new update module that pulls from Github instead.

You guys do know that this has already happened, right?:

https://backdropcms.org

I don't think this is a good idea... even if I would prefer to work on Github :-)

...it is a great idea!: https://github.com/backdrop/backdrop ...hell yeah, GitHub makes things sooo much easier.

"Forking" Drupal 7 would makes things even more messier.

...nope, it makes things sooo much less messier ...the specific fork was made and is well-maintained by people that absolutely love Drupal 7.

I just hope one day some people will just take care of D7 for the millions of sites yet running it.

shameless plug: Yep, we've got things started some 4+ years ago. Come join us!! :)

backdrop cms, great project, unfortunately everything my clients need is in the stuff that was dropped. Like multilingual , entity_translation, i18n, entity_translation_unified_form , stuff that larger international organizations need.
so ya, Drupal still paying the bills. However yes I'll keep peeking at backdrop , quicksketch has done some excellent work there! Drupal 7 gets it done.

...well technically @joseph.olstad the multilingual/translation stuff was not "dropped"; they just have not been ported/implemented yet :) Backdrop is not D8 -things; it is D7 +someD7contrib +someD8 +magic +love :)

Updating Issue tags so this issue shows up with the rest of the PHP 7 issues.

#26 Work for me
I was getting same error issue add only

if (!defined('DATE_RFC7231')) {
define('DATE_RFC7231', 'D, d M Y H:i:s \G\M\T');
}

Instead of define('DATE_RFC7231', 'D, d M Y H:i:s \G\M\T'); @ line no 258 in bootstrap.inc
Thanks!!

This was released in 7.55

so 7.67 (current release) has this fix,

if you're still needing this patch it's because you're using php 7 with some version of core prior to 7.55?

Thanks. Patch in #26 worked for me.