[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