WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 9 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 10 years ago.
11615.2.diff (8.2 KB) - added by nacin 10 years ago.
Die, die, die…

Download all attachments as: .zip

Change History (10)

@nacin
10 years ago

#1 @dd32
10 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
10 years ago

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

#3 @hakre
10 years ago

  • Version set to 2.9.1

#4 in reply to: ↑ 2 @nacin
10 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
10 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
10 years ago

  • Keywords dev-feedback removed

New patch per IRC discussion.

@nacin
10 years ago

Die, die, die...

#7 @ryan
10 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
9 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.