[wp-trac] [WordPress Trac] #32068: Excessive overhead in widgets.php on large site

WordPress Trac noreply at wordpress.org
Thu Apr 23 03:37:35 UTC 2015


#32068: Excessive overhead in widgets.php on large site
----------------------------+------------------------------
 Reporter:  ronnieg         |       Owner:
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  4.1
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+------------------------------

Comment (by ronnieg):

 In the case of the widgets.php page, if the Pages widget is not in an
 active widget area, which it is not on my site, nor on any of the many
 other sites I have built or support, then it shouldn't be necessary to
 build the drop-down list for it.

 If it is dragged into an active widget area, then and only then should it
 be necessary to build a drop-down list. (Hmmm? A drop-down list of 6000+
 pages? How would that ever be displayed and /or scrolled through?) And
 even then, it seems to me that specifying a starting page for that widget
 should be like the current custom menu build process. Let the user/admin
 open the widget in its assigned active widget area, then search for a
 starting page by page name, and only then would it need to build any
 trees.

 And IMO, given the simplicity of custom menu building with the current WP
 version, and the plethora of available plugins that allow an admin to add
 a custom menu anywhere they want, in a widget area or on a page/post, and
 given the heavy resources utilization, I believe that the Pages widget
 should actually be a top candidate for permanent removal from WP. Comments
 on that idea?

 Similar suggestion for the Options / Reading page. Give it the ability
 search for pages / posts when selecting one, instead of automatically
 creating a massive drop-down list, one that couldn't ever be displayed in
 any case. The required code is already there in the custom menu building
 process. These things may have made sense when WP sites were a couple
 dozen pages at most, but no longer, when larger and more complex sites are
 now more the norm.

 In the meantime, I will try to figure out how to permanently disable the
 Pages widget, remove it from the Available Widgets list, and suppress its
 useless (IMO) overhead.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32068#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list