The issue observed on Windows, IIS 10, and PHP 7.

The latest version of PHP, 7.0.19, fixes this bug in PHP and defines the constant DATE_RFC7231 in PHP itself.

As a result, Bootstrap now generates a notice:

Constant DATE_RFC7231 already defined in C:\vhosts\my-site\includes\bootstrap.inc on line 258

In my environment, a PHP notice at that stage of Bootstrap completely broke the site. I could revert the PHP version to the previous one, but there was no workaround in user interface.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

karoop created an issue. See original summary.

karoop’s picture

karoop’s picture

Status: Active » Needs review
cilefen’s picture

In what way does this qualify as critical priority?

karoop’s picture

It rendered my site completely unusable with no immediate workaround except for applying the patch. Feel free to change the priority if you find a workaround.

cilefen’s picture

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

karoop’s picture

Issue summary: View changes
travis uribe’s picture

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

cilefen’s picture

Issue tags: +php7
cilefen’s picture

Crell’s picture

Status: Needs review » Reviewed & tested by the community

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.

MegaChriz’s picture

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).

Crell’s picture

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

deminy’s picture

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.

robertgarrigos’s picture

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

nateB’s picture

#2 works for me on PHP 7.1.5 and mysql 5.7.18

egontinno’s picture

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

karoop’s picture

Issue summary: View changes
jief’s picture

#2 works on 7.0.19

heddn’s picture

Assigned: karoop » Unassigned

Fixed my D7 site too. +1 on RTBC.

greggles’s picture

Another +1.

Anonymous’s picture

Is there any short term fix I can do in the meantime to get rid of the warning for a D7 site?

joseph.olstad’s picture

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

Anonymous’s picture

Sorry! I totally missed that patch for some reason - Yes, the patch fixed the issue for me. Thank you for your help, @joseph.olstad.

joseph.olstad’s picture

Issue tags: +Drupal 7.60 target
David_Rothstein’s picture

Title: DATE_RFC7231 already defined in PHP 7.0.19 » DATE_RFC7231 already defined in PHP 7.0.19 and 7.1.5
Status: Reviewed & tested by the community » Needs review
Issue tags: -Drupal 7.60 target
FileSize
710 bytes
571 bytes

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.

joseph.olstad’s picture

Status: Needs review » Reviewed & tested by the community

The added comments are helpful easy to understand.

Thanks :)

pacproduct’s picture

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

pmchristensen’s picture

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

oxrc’s picture

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.

bmateus’s picture

#26 worked for me - thanks!

joseph.olstad’s picture

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

delta’s picture

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

pjcdawkins’s picture

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.

David_Rothstein’s picture

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.)

David_Rothstein’s picture

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.

geerlingguy’s picture

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!

Ollie222’s picture

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.

David_Rothstein’s picture

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

vegardjo’s picture

#26 works fine for me as well!

GiorgosK’s picture

#26 is good please commit

randell’s picture

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

Pol’s picture

Hi,

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

joseph.olstad’s picture

@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.

Pol’s picture

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

greg.1.anderson’s picture

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?

nickonom’s picture

I also confirm #26 works.

David_Rothstein’s picture

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

GuillaumeDuveau’s picture

Great :)

#26 is OK for me too.

legovaer’s picture

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

greg.1.anderson’s picture

++Dave_Rothstein Thanks so much.

  • David_Rothstein committed 8008df2 on 7.x
    Issue #2877243 by David_Rothstein, karoop, joseph.olstad, deminy:...
David_Rothstein’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: +7.55 release notes

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 :)

Status: Fixed » Closed (fixed)

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

waqarit’s picture

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

donapis’s picture

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

timhtheos’s picture

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

willhallonline’s picture

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

noi_ag’s picture

shilpadru8187’s picture

@David_Rothstein #26
Worked for me on PHP 7.1.11
Thanks

rooby’s picture

joseph.olstad’s picture

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

Justincletus’s picture

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

kennybell’s picture

#2 Solved the issue for me.

klonos’s picture

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!! :)

joseph.olstad’s picture

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.

klonos’s picture

...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 :)

oadaeh’s picture

Issue tags: -php7 +PHP 7.0 (duplicate)

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

sushilkr’s picture

#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!!

joseph.olstad’s picture

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?

AswathyAjish’s picture

Thanks. Patch in #26 worked for me.