[wp-trac] [WordPress Trac] #11385: a couple of uninstantiated options
WordPress Trac
wp-trac at lists.automattic.com
Fri Dec 11 09:07:38 UTC 2009
#11385: a couple of uninstantiated options
-------------------------------+--------------------------------------------
Reporter: Denis-de-Bernardy | Owner:
Type: defect (bug) | Status: reopened
Priority: normal | Milestone: 2.9
Component: Optimization | Version: 2.9
Severity: normal | Resolution:
Keywords: has-patch |
-------------------------------+--------------------------------------------
Changes (by Denis-de-Bernardy):
* status: closed => reopened
* resolution: worksforme =>
* milestone: => 2.9
Comment:
Replying to [comment:1 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.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/11385#comment:5>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list