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.

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.

failcookie’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?

failcookie’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