WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#39132 closed defect (bug) (fixed)

WP 4.7, object-cache.php breaks the site if APC is not enabled in php

Reported by: innocuo Owned by: dd32
Milestone: 4.7.1 Priority: normal
Severity: normal Version: 4.7
Component: Bootstrap/Load Keywords: has-patch fixed-major
Focuses: Cc:
PR Number:

Description

This happens if PHP doesn't have APC enabled.

In wp-includes/object-cache.php: the code checks if APC is enabled, by checking the existence of the function 'apc_fetch'. If it isn't, then it sets $GLOBALS['_wp_using_ext_object_cache'] to false, and manually adds a filter to $wp_filter['all'] , like this:

$GLOBALS['wp_filter']['all'][-100]['apc_not_actually_running'] = array( 'function' => 'apc_not_actually_running', 'accepted_args' => 0 );

Then, when _wp_call_all_hook() is called (this is in wp-includes/plugin.php), the code breaks.

This happens because it does this:

$wp_filter['all']->do_all_hook( $args );

meaning, it expects $wp_filter['all'] to be a WP_Hook object, but it is an array due to the override that happened in object-cache.php (mentioned above).

An "solution" for users would be to install and enable APC on php,
or comment the line that adds the filter as an array in object-cache.php (line 667 in the latest version). The real solution would be to add this filter using/via WP_Hook?

Attachments (1)

39132.diff (502 bytes) - added by jorbin 3 years ago.

Download all attachments as: .zip

Change History (23)

#1 @innocuo
3 years ago

  • Summary changed from WP 4.7 breaks if APC is not enabled in php to WP 4.7, object-cache.php breaks the site if APC is not enabled in php

#2 @dd32
3 years ago

  • Milestone changed from Awaiting Review to 4.7.1

FWIW, you're running a custom wp-content/object-cache.php file here, which is not the same as wp-includes/object-cache.php. You're also running one which is incompatible with your server setup (as you don't have APC enabled).

The APC version from @markjaquith here seems to be what's referenced: https://plugins.svn.wordpress.org/apc/tags/2.0.6/object-cache.php

In WordPress 3.0 and earlier plugin.php was loaded after the object cache, in 3.1 and later it's loaded before.

I guess we have to do something similar to [39370] for object-cache.php.

#3 @innocuo
3 years ago

You are absolutely right, object-cache.php is in wp-content, not wp-includes; and can also confirm I was referencing the "APC Object Cache" plugin version 2.0.6
my brain went dyslexic when spending too much time hunting my issue, even after reviewing this file several times.

Sorry about this, but it's my first time reporting an issue. I'm assuming the policy is for me to "leave as new" and you'll close/resolve it?

@jorbin
3 years ago

#4 @jorbin
3 years ago

  • Keywords has-patch added

I've uploaded a patch that I belive will fix this issue. @innocuo can you please test it.

This ticket was mentioned in Slack in #core by jorbin. View the logs.


3 years ago

#6 @jorbin
3 years ago

#39146 was marked as a duplicate.

#7 @dd32
3 years ago

@jorbin You'll need to explicitly global $wp_filter;, other than that, 39132.diff looks like it's in the correct nested branch to me.

I'll note though, that wp_start_object_cache() has a branch which claims that object-cache.php might have been included from advanced-cache.php - it might've also been included by whatever loaded WordPress, but in either of those cases, the conversion would've happened on WP_Hook or advanced-cache.php inclusion.

#8 @innocuo
3 years ago

I was just replying, too :)

@jorbin, as @dd32 mentioned, global $wp_filter; needs to be added within wp_start_object_cache()

After doing that, your patch works OK.I tested the following cases:

  • if object-cache.php v2.0.6 exists
  • if object-cache.php doesn't exist
  • if object-cache.php exists and is an empty file

in all cases, I don't have APC enabled. It looks like it should work if APC is enabled as then object-cache.php doesn't add anything to $wp_filter.

#9 @swissspidy
3 years ago

#39169 was marked as a duplicate.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


3 years ago

#11 in reply to: ↑ 10 ; follow-up: @bdanielson2016
3 years ago

I deleted the object-cache.php in wp-content/object-cache.php and now I get an Fatal error: Uncaught Error: Class 'WP_Taxonomy' not found

#12 in reply to: ↑ 11 @innocuo
3 years ago

@bdanielson2016, looks to me like the issue you mention is unrelated. What must be happening is that you have 2 errors, php stops at error 1 caused by object-cache.php. By deleting it you actually fix error 1, but now php stops at error 2.

I can only reproduce the error reported by @bdanielson2016 if I remove wp-includes/class-wp-taxonomy.php.
And the error is only displayed when:

  • object-cache.php is not present
  • or if object-cache.php is present and wp-includes/load.php is patched.

This just means one error is hiding the presence of the other.

There's a similar report in the support forums with someone suggesting it's due to a failed incomplete update.

Last edited 3 years ago by innocuo (previous) (diff)

This ticket was mentioned in Slack in #forums by ipstenu. View the logs.


3 years ago

#14 @dd32
3 years ago

#39217 was marked as a duplicate.

#15 @rymr31
3 years ago

Good stuff here, so, is there an optimal way on how to update to 4.7 and fix this bug? Or should those of us having this problem wait for the next Wordpress update if it is going to be fixed then?

#16 @dd32
3 years ago

Good stuff here, so, is there an optimal way on how to update to 4.7 and fix this bug?

Realistically; if you run into this, you're running a wp-content/object-cache.php file which is probably actually working as intended and should be removed - it's literally doing nothing.

This situation will be fixed in 4.7.1 though.

#17 @dd32
3 years ago

  • Owner set to dd32
  • Resolution set to fixed
  • Status changed from new to closed

In 39565:

Bootstrap: Re-initialize any hooks added manually by object-cache.php.
Prior to 3.1 if a object cache dropin wanted to add actions, they needed to use $wp_filter directly.

Props jorbin.
Fixes #39132.

#18 @dd32
3 years ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

re-opening for backport.

#19 @dd32
3 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 39605:

Bootstrap: Re-initialize any hooks added manually by object-cache.php.
Prior to 3.1 if a object cache dropin wanted to add actions, they needed to use $wp_filter directly.

Props jorbin.
Merges [39565] to the 4.7 branch.
Fixes #39132.

#20 @dd32
3 years ago

#39391 was marked as a duplicate.

#21 @dd32
3 years ago

#39401 was marked as a duplicate.

This ticket was mentioned in Slack in #forums by ipstenu. View the logs.


3 years ago

Note: See TracTickets for help on using tickets.