[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