a couple of uninstantiated options

[Denis-de-Bernardy]

A couple of options, which are used by get_user_option(), do not seem to be instantiated anywhere.

In particular:

			case 'edit_per_page':
			case 'edit_pages_per_page':
			case 'edit_comments_per_page':
			case 'upload_per_page':
			case 'categories_per_page':
			case 'edit_tags_per_page':
			case 'plugins_per_page':

[nacin]

I can't find any option called by get_user_option() that is instantiated on the blog level. Some appear to be instantiated per-user in wp_insert_user() (admin_color, use_ssl, comment_shortcuts, rich_editing).

Granted, I see that it might be good for some of these to be instantiated somewhere, but the code already provides for that; example below. Many other options contain variable names, which is also appropriately handled.

$plugins_per_page = get_user_option('plugins_per_page');
if ( empty($plugins_per_page) )
	$plugins_per_page = 999;
$plugins_per_page = apply_filters('plugins_per_page', $plugins_per_page);

Perhaps I'm missing something?

[nacin]

I also found #2033 -- rich_editing was specifically removed as a blog-level option after it was converted to a user option, even though get_user_option at the time fell back to blog-level options (which it still does, at least by default) after checking for the option at the user-per-blog and user scopes.

[Denis-de-Bernardy]

Replying to nacin:

I can't find any option called by get_user_option() that is instantiated on the blog level. Some appear to be instantiated per-user in wp_insert_user() (admin_color, use_ssl, comment_shortcuts, rich_editing).

and others are not.

Granted, I see that it might be good for some of these to be instantiated somewhere, but the code already provides for that; example below. Many other options contain variable names, which is also appropriately handled.

$plugins_per_page = get_user_option('plugins_per_page');
if ( empty($plugins_per_page) )
	$plugins_per_page = 999;
$plugins_per_page = apply_filters('plugins_per_page', $plugins_per_page);

Perhaps I'm missing something?

Yes: these cause a useless query on every admin page load when they're not instantiated, since WP ends up thinking they're not autoloaded.

[dd32]

Ticket seems to be correct, Whilst i've not tested it, seems right and it'll only occur for users which have not saved the screen options for the current page.

[nacin]

Replying to Denis-de-Bernardy:

Yes: these cause a useless query on every admin page load when they're not instantiated, since WP ends up thinking they're not autoloaded.

Replying to dd32:

Ticket seems to be correct, Whilst i've not tested it, seems right and it'll only occur for users which have not saved the screen options for the current page.

Fair enough, that's convinced me to about-face on this. In that case, are there any others that should be set at the blog level?

[nacin]

Or, instead of instantiating them in wpdb->options, what if we used the parameter for get_user_option that prevents a blog-level check?

That would prevent needing to fetch the blog-level option, prevent the need to add six new options (which are autoloaded, as well), would prevent the unnecessary query generated by get_option, etc. Just in general, it prevents duplication in logic that would need to remain hardcoded and could very well be hard-coded, considering there is a filter both on get_user_option and on each of these values.

[nacin]

Patch that standardizes filters, standardizes checks to prevent $per_page being < 1, and prevents get_user_option from checking for a blog option.

Also removes an orphaned $posts_per_page = get_option('posts_per_page') in the admin.php bootstrap. The variable is never used, though it is overwritten in post.php, and appears to be an artifact that is left over from before the time of screen options.

Probably good for 3.0. To fix in 2.9, I'd suggest the simple get_user_option change of setting the third variable to false, turning off blog option checking.

[ryan]

nacin's patch looks good except for the removal of the $posts_per_page global. That option is defined in the schema. Perhaps it doesn't need to be made a global, but that can be argued in a different ticket.

[ryan]

In a future release, we should replace get_user_option() with something that doesn't unexpectedly dip into the options table by default. This isn't the first time we've made unnecessary option table queries because of it.

[nacin]

Replying to ryan:

nacin's patch looks good except for the removal of the $posts_per_page global. That option is defined in the schema. Perhaps it doesn't need to be made a global, but that can be argued in a different ticket.

Correct me if I'm wrong, but that's the reading option for the number of posts to display per page in a theme. The global $posts_per_page variable itself is unused in admin, but in the off-chance a plugin used it, it is overridden to hold the screen options per_page value in post.php.

I suppose this would make sense if it is being maintained for back compat, assuming that the admin used to rely on the same setting?

[nacin]

Patch without global $posts_per_page, just in case and to move this along.

[ryan]

It's probably old cruft that needs to be removed, but I'd rather play it safe for 2.9 in case someone happens to be using it.

[ryan]

(In [12375]) Don't fallback to the options database when retrieving *_per_page user options. Props nacin. fixes #11385