WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#11615 closed enhancement (fixed)

Avoiding the options table when retrieving a user option

Reported by: nacin Owned by:
Milestone: 3.0 Priority: normal
Severity: normal Version: 2.9.1
Component: Optimization Keywords: has-patch
Focuses: Cc:

Description

Follow up to #11385.

We're querying the options table unnecessarily and unexpectedly on some calls to get_user_option(). This function first checks if the user option (say, 'rich_editing') exists at the per-blog per-user level, then the per-user level, then the per-blog level. The per-blog level can be turned off via one of the arguments but it is on by default.

There are currently seven different user options we check the options table for. Four (use_ssl, admin_color, comment_shortcuts, rich_editing) are set in wp_insert_user(), so unless a plugin deliberately removes the user meta there and wants the options table to be queried, we'll never generate needless queries on that.

On the other hand, screen_layout_$screen, plugins_last_view, and autosave_draft_ids are generating unnecessary queries on the options table when they have yet to be initialized. Patch here changes those.

Bigger picture here: We should come up with a new get_user_option() that doesn't check the options table by default. Since there is no use of get_user_option() in core that should fall back by default, I'm thinking that the options table check could perhaps be better served by a filter.

Attachments (2)

11615.diff (1.5 KB) - added by nacin 8 years ago.
11615.2.diff (8.2 KB) - added by nacin 8 years ago.
Die, die, die…

Download all attachments as: .zip

Change History (10)

@nacin
8 years ago

#1 @dd32
8 years ago

Since there is no use of get_user_option() in core that should fall back by default, I'm thinking that the options table check could perhaps be better served by a filter.

My suggestion would be to add a filter to it, and remove the per-blog functionality of it.. As you've said.. its not actually used as such.

#2 follow-up: @hakre
8 years ago

Didn't ryan said that the blogid will be removed from the database table anyway?

#3 @hakre
8 years ago

  • Version set to 2.9.1

#4 in reply to: ↑ 2 @nacin
8 years ago

Replying to hakre:

Didn't ryan said that the blogid will be removed from the database table anyway?

I imagine it'll be removed, but that's unrelated here. The per-blog setting is stored by taking the user meta key and prepending the wpdb prefix. So, it first checks for wp_use_ssl in wp_usermeta, then use_ssl in wp_usermeta, then use_ssl in wp_options.

The suggestion here is to get rid of the wp_options check when we don't need it. The bigger idea, as ryan had suggested, is to switch over to a function that doesn't check wp_options at all (at least by default) and only checks usermeta for blog-level and user-level values.

#5 @ryan
8 years ago

$check_blog_options should die. No one wants it to be true or even exist. Deprecate it and clean up all calls to get_user_option().

#6 @nacin
8 years ago

  • Keywords dev-feedback removed

New patch per IRC discussion.

@nacin
8 years ago

Die, die, die...

#7 @ryan
8 years ago

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

(In [12616]) Deprecate argument. Never fallback to options table for user option requests. Props nacin. fixes #11615

#8 @dd32
7 years ago

(In [13220]) Update get_user_option()'s PHPDoc Comment to remove mentions of blog options. See #11615

Note: See TracTickets for help on using tickets.