Fully support PHP 7.2 in Drupal 7

In lieu of interdiff file, the changes are:

_drupal_shutdown_function()
- reference on $callback was not present before so omit from patch

_form_validate
- $elements['#value'] instanceof Countable is not necessary
- form API does not use Countable object

module_enable and module_disable
- comments are more concise

book_prev and book_next
- changes are more concise

theme_table
- remove change; add to drupal_common_theme

drupal_common_theme
- correct prototype values on 3 theme items

same patch with header removed

testUploadModule

fail: [Other] Line 738 of modules/update/update.test:
Existing module was extracted and not reinstalled.

Same error I got over here when I tried to suppress the error to get an idea on where we stood.
#2925449-51: [PHP 7] Function each() is deprecated since PHP 7.2 [D7]
https://www.drupal.org/pift-ci-job/924112

I'm gonna guess you'll have to get php 7.2 running locally and manually debug this :/

PHP 5.3 failed with this

fail: [Completion check] Line 24 of modules/rdf/rdf.test:
The test did not complete due to a fatal error.

Guessing that was just a random failure

Manually tested uploading of modules in PHP 7.2. Uploading a tar file will result in a fatal error due to Archive_Tar incompatibility with PHP 7.2 #2946045: Unable to update modules due to Archive_Tar incompatibility with PHP 7.2

Updated status to Needs work

#21 applied cleanly and worked for me. Thanks!

Upgraded today to 7.2 and was getting "The each() function is deprecated" error. Patch #21 no errors.

What about #2938567: PHP 7.2: Warning: count(): Parameter must be an array or an object that implements Countable a theme_table()?

What about #2938567: PHP 7.2: Warning: count(): Parameter must be an array or an object that implements Countable a theme_table()?

The patch in #2885610: [PHP 7.2] Avoid count() calls on uncountable variables , which is also included in the combined patch in this issue fixes that. I marked that issue a duplicate of 2885610.

Are $colgroups and other similar variables arrays always?

This is the plan issue, but happy for it to be critical.

The patch in #20 worked for me also. Hopefully this will be officially added to core soon.

Found a case locally where @maximpodorov was right... $colgroups was coming in as a bare null to theme_table().

Looks like the other variables are controlled locally here.

(first time patch, apologies for errors)

Uploading exactly the same patch as #31 just to see if we can get a totally green board from the tests; to me at least, the mess left over from a few testbot errors makes it very unclear whether all tests are actually passing or whether there are legit failures.

If all tests pass, will put this back to RTBC.

So we still saw 3 test failures for PHP7.2 however I'm not entirely convinced they were legitimate.

Queued for a retest; if the same 3 failures come back we'll have to dig into them.

Unless I'm missing something, that looks like a pass for PHP7.2 on the re-test; I think the first time around was a testbot snafu.

Good news then! Back to RTBC.

Thank you very much for re-testing. That was a very good idea.

Is #2885129: [PHP 7.2] create_function() is deprecated part of this? (old update, but still)

What is the current disposition of patch 31 ? Has it been tested, committed, pushed to release or update ?

I'd like to get rid of warning: "The each() function is deprecated. This message will be suppressed on further calls in menu_set_active_trail() (line 2405 of /var/www/html/xxxx/includes/menu.inc)."

I was hoping to see the message suppressed, but that doesn't seem to be working.. I'm stuck because others are pushing WP.

@gary_mazz: Turn off error messaging if you won't see such warnings. As joseph.olstad stated: on the way in.

@joseph.olsta - any idea when the patches will be committed?
Or in the meanwhile, could someone help us to point which one to patch while we are waiting for a new release? :)

You can track individual progress in the linked issues. Some are merged to the 7.x branch, but not released in a proper release. I wouldn't be surprised if a release takes time because 8.x gets more attention nowadays.

I use the patch at #31 for Drupal 7 sites.

Patch #31 works for me.
php version: 7.2
Drupal core 7.59

Fixed via the sub-issues

Hooray. It's fixed. Thanks to everyone involved. Sorry for the dumb question, but: Do I understand correctly that the next release 7.60 will then be fully PHP 7.2 compatible?

Unless a security release races first, 7.60 will contain all these fixes. I wouldn't call it "Fully 7.2 compatible" because there could be bugs unreported here.

When is it expected to release Drupal 7.60? somebody remember release dates?

#31 works for me.
Had to also modify:

@ "includes/theme.inc" file.
- $links = $variables['links'];
+ $links = (array) $variables['links'];

#31 Works for me.

Thanks

I was able to apply this patch successfully and everything appears to be working as intended in my sandbox php 7.2 environment.

Thank you!

> When is it expected to release Drupal 7.60? somebody remember release dates?
Afaik it has always been the plan(/target) that releases every 6 months would contain new features.
But 7.50 was over 2 years ago, so I guess that idea didn't last very long.

@MustangGB and @oriol_e9g

The following are prior release dates. Any day now, it would seem. (Thank you everyone who contributed to this.)

7.59 - 25 April 2018
7.58 - 28 March 2018
7.57 - 21 February 2018
7.56 - 21 June 2017
7.55 - 7 June 2017
7.54 - 1 February 2017
7.53 - 7 December 2016
7.52 - 16 November 2016
7.51 - 5 October 2016
7.50 - 7 July 2016
7.44 - 15 June 2016
7.43 - 24 February 2016
7.42 - 3 February 2016
7.41 - 21 October 2015
7.40 - 14 October 2015
7.39 - 19 August 2015
7.38 - 17 June 2015
7.37 - 7 May 2015
7.36 - 2 April 2015
7.35 - 18 March 2015

Hello,
I applied patch given... but still not working for php 7.2
still getting.
Fatal error: Uncaught Error: Call to undefined function cache_get() in public_html/includes/module.inc:762 Stack trace: #0 public_html/includes/module.inc(962): module_implements('system_theme_in...') #1 public_html/modules/system/system.module(2511): module_invoke_all('system_theme_in...') #2 /public_html/includes/theme.inc(798): _system_rebuild_theme_data() #3 /public_html/includes/theme.maintenance.inc(57): list_themes() #4/public_html/includes/bootstrap.inc(2881): _drupal_maintenance_theme() #5 /public_html/includes/errors.inc(179): drupal_maintenance_theme() #6 /public_html/includes/bootstrap.inc(2609): _drupal_log_error(Array, true) #7 [internal function]: _drupal_exception_handler(Object(Error)) #8 {main} thrown in/public_html/includes/module.inc on line 762
Help me ....

@pramodini123 - I can't reproduce your issue, do you mind to tell us the step by step how you faced the error? Maybe a screenshot can also help us.

Hello,
Server admin has removed.. php7 so automatically 7.2 is now there.... So I applied the patch given... but still these errors are...
Thank you,

Hello,
I used drupal 7.x dev .. .then also getting same error... I tried also by removing one by one modules but no other errors...

Hello,
Thanks joseph.olstad I updated drupal dev version ... with your reply... bu was not working .same error . but..
I just updated fresh settings.php and updated there details with database and other details there... and its working...
Thanks a lot for your help joseph.olstad
Thank you

I completely agree :-)

I think the comment by pipicom #60 was missed. I ran into his same issue with theme.inc

As this is a plan, I feel good to re-open this until #2996519: PHP 7.2 compatibility - make sure some variables are arrays in theme_links(). is fixed.

Thanks!

Full support of PHP 7.2 is fixed again as of our current knowledge:

#2996519: PHP 7.2 compatibility - make sure some variables are arrays in theme_links().

So marking this plan as fixed again.

I don't understand what just happened, is Fabianx trying to give himself three times the amount of work?

This is long overdue to be released.. any schedule?

We are having to upgrade our web servers to support PHP 7. It would be great to go direclty to 7.2, instead of having to go to 7.1 until Drupal 7.60 is released to support PHP 7.2.

Is there a planned date for the release of Drupal 7.6?

Thanks,
Pablo

I do use Drupal 7 with PHP 7.2 on dev boxes and various VMs, and I experienced no problems, problem will rise with modules, mostly, core is not really problematic.

Hm. There was more than half a year between 7.56 and 7.57 according to #64. I hope this isnt any indication. Does anyone know whether the release process has any transparency? When I search for issues tagged "Drupal 7.60" target I find LOTS of issues. Many "reviewed and tested by the community", many also in "Needs review", "Needs work" state. Many abandoned for many months or even years. I wonder: Is there are some kind of credible list of what needs to be solved until 7.60 is released? Right now, everyone on this issue is anxiously waiting I guess. We have mixed D7/D8 servers with lots of websites on them and we cannot upgrade to 7.2 and profit from the performance benefits etc only due to this issue. And it's not really a solution to use any dev branch etc if you have many, many production websites to take care of.

Security releases do not contain bug fixes, so none of these PHP 7.2 fixes were included in the 7.60 release. Hopefully maintainers will finally merge and release a 7.61 with these changes.

yup... So many people are waiting for the php 7.2 fixes.

Last functional release: Drupal 7.55, 2017-06-07

For those of us with Drupal 7 sites on shared hosting PHP 7.2 compatibility is increasingly important. Many major players like Midphase have already upgraded their servers and do not provide the option of sticking with an earlier PHP version.

++1 for the swiftest possible release of 7.61.

I run a few small ok-if-it-breaks-ware sites on PHP 7.3-rc3 with 7.x-dev, and it surprisingly runs well.

There aren't much deprecations in PHP 7.3 (shameless self plug: https://ayesh.me/Upgrade-PHP-7.3) that raises any big problems.

However, 7.3 is just around the corner, and it would be nice if we could have a 7 61 feature release just so we can say Drupal 7 is compatible with latest photo version.

+1 from me - please prioritize PHP 7.2 in 7.61

Yes, for the love of jeebus, let's get PHP 7.2 in 7.61!

The next stable release of Drupal 7 will include the fixes, the question is whether there'll be another security release before that.

The next stable release of Drupal 7 will include the fixes, the question is whether there'll be another security release before that.

Perhaps we shouldn't delay a 7.61 release for so long that someone finds a vulnerability in 7.60? To be honest it is getting ridiculous how long these PHP 7.2 fixes let alone improvements are dragging. On a serious note, I am available to help out maintainers if they are time-constraint.

HostEurope disabled PHP 5.6 yesterday for shared hosting and 7.2 is now their default.

Thanks a lot, Joseph. Good to know. What I find most disconcerting is not that the release takes a bit longer but the huge intransparency of the release process in general that Drupal and associated modules is often enshrouded in. This bug is in status "Closed (fixed)". And then it stays just like that for an indefinite amount of time. And now, if you search for "Drupal 7.61 target" you see lots of different issues. Are they going to be fixed before 7.61 is released? Or some of them? Or what does it all mean?

I guess the Drupal core developers probably have a list of issues they want to have fixed until Drupal 7.61 is released. And, I guess again, it's not too far-fetched to imagine this list is not on paper but exists in electronic form. Then, I wonder: Why aren't they simply making this information available to the public? Imagine you're waiting at the doctor's office and they say you need to wait for 3 hours. It's bad, but after all you can accept it, read a magazine and wait. Now, imagine you're waiting for 3 hours and you simply don't know if you need to wait another 3 hours, 6 hours or 4 weeks sitting in that office. No one talking to you. The simple information on what to expect makes a huge difference here.

I'm well aware the Drupal folks are a bunch of pretty clever guys and many things might have their reasons but sometimes it would really help *a lot* for those of us who have to get the job done everyday to know a bit more about what's actually going on.

The "open" part of the term "Open Source" IMHO shouldnt only mean you can have the source code, but also that the development process in general is more open. Since LibreOffice split off from OpenOffice and, well, liberated the development process it seems the software is progressing at almost 10x the original speed.

I'm still having a huge list of Drupal patches I keep porting from version to version to make the many Drupal websites we take care of work. Which is OK. It's free after all. But some of those patches also sit there for years. It's admittedly not core though. I honestly sometimes wonder: Is the original maintainer still alive? If you ask me, the information process could really be improved upon. It can and should IMHO be way more clear for happens next with issues that have patches available or are even marked as "fixed".

Ok, just my thoughts on this. Hope this didnt come across as too much of a rant. I like Drupal after all :-)

Closing this discussion as it has gone way off topic.

@joseph.oldstad's comment #98 stands as the final word on the subject.