WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#11956 closed defect (bug) (wontfix)

Implement backward compatible site options and transients

Reported by: Denis-de-Bernardy Owned by:
Milestone: Priority: normal
Severity: major Version: 3.0
Component: General Keywords: needs-patch
Focuses: Cc:

Description

I'm watching the number of site options and site transients grow with increasing worry, thinking these will break numbers of plugins that use them in a way or another.

Suggestion to improve backwards compatibility:

  1. We maintain an internal list of site option and site transient names.
  2. When get_option() and get_transient() is called, we check if it's a site option/transient
  3. If so, we return get_site_option() or get_site_transient() accordingly

In other words, if a plugin calls get_option(siteurl), WP translates this internally into get_site_option(siteurl), and applies the old-style filters in addition.

Thoughts?

Change History (10)

comment:1 @miqrogroove6 years ago

I recall from the dev chat that there is supposed to be full backward compatibility for plugins. I would make this a blocker.

comment:2 @nacin6 years ago

  • Keywords needs-patch added; 2nd-opinion removed

Is someone willing to compile a list of recent changes between options, site options, transients, and site transients?

comment:3 @nacin6 years ago

  • Type changed from enhancement to defect (bug)

This needs to be taken care of IMO.

comment:5 @Denis-de-Bernardy6 years ago

chances are a simple fix here is to simply apply *option_* filters to site options, and *transient_* filters to site transients.

comment:6 @Denis-de-Bernardy6 years ago

  • Milestone 3.0 deleted
  • Resolution set to worksforme
  • Status changed from new to closed

closing per discussion with andrew ("default filters, such as one on 'pre_transient_blah' that calls site_transient('blah'), would handle it.")

comment:7 @nacin6 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

I'm going to re-open, as I think this could be solved on the core side. Simple solution is adding these to default-filters.php:

add_filter( 'pre_transient_update_core',           create_function( '', 'return get_site_transient("update_core");'           ) );
add_filter( 'pre_transient_theme_roots',           create_function( '', 'return get_site_transient("theme_roots");'           ) );
add_filter( 'pre_transient_update_themes',         create_function( '', 'return get_site_transient("update_themes");'         ) );
add_filter( 'pre_transient_update_plugins',        create_function( '', 'return get_site_transient("update_plugins");'        ) );
add_filter( 'pre_transient_dismissed_update_core', create_function( '', 'return get_site_transient("dismissed_update_core");' ) );

That includes the 3.0 changes (and I think theme_roots was late 2.9). We could go back and also make the 2.8 changes (and the changes back) compatible as well if we wanted to.

I guess the one thing this doesn't do is run the original filters, but that'd be tough. This would at the very least allow get_transient('update_plugins') to return the right value. Maybe that isn't much of a priority and maybe the filters are more important.

comment:8 @Denis-de-Bernardy6 years ago

  • Milestone set to 3.0

Personally, the issue I ran into is the following:

  1. I hook into transient_update_plugins, in order to expand the results sent by the built-in update service
  2. In trunk, I need to a) hook into site_transient_update_plugins and b) use a site_transient myself.

The likelihood is I'll end up needing to add aliases for the newly introduces functions, so as to keep WP 2.9 compat.

comment:9 @ryan5 years ago

  • Milestone changed from 3.0 to 3.1

comment:10 @nacin5 years ago

  • Milestone Awaiting Triage deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

No traction, and it's been in the wild for a year. Closing.

Note: See TracTickets for help on using tickets.