[wp-trac] [WordPress Trac] #21871: Reduce reliance on global variables in list tables

WordPress Trac wp-trac at lists.automattic.com
Sat Sep 22 19:52:38 UTC 2012


#21871: Reduce reliance on global variables in list tables
----------------------------+-----------------------
 Reporter:  ryan            |       Owner:  ryan
     Type:  enhancement     |      Status:  reopened
 Priority:  normal          |   Milestone:  3.5
Component:  Administration  |     Version:  3.4
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |
----------------------------+-----------------------

Comment (by ryan):

 The screen basically needs four things: the admin context ( user | network
 | site | front ), the particular admin page, post_type, and taxonomy.
 Currently, get() attempts to get these in several ways.

  * The global hook_suffix along with post_type and taxonomy from the
 request and the *_ADMIN constants
  * A hook name that is pretty much hook_suffix with the .php being
 optional plus post_type and taxonomy from request and the *_ADMIN
 constants
  * An "ID" that is a little more removed from the hook suffix that encodes
 the admin context and the post_type and taxonomy. It currently does not
 provide both the post_type and the taxonomy to edit-tags.php. Only
 taxonomy is provided.
  * The guid patches introduce a new id that provides everything needed in
 one string.

 There are several methods used for passing screen info along to ajax
 handlers.

  * Inline JS in admin-header.php also attempts to provide some screen
 related information via pagenow and typenow variables.

  * WP_List_Table::_js_vars() passes along the screen id and base.

  * edit-tags.php passes the screen ID in a hidden input.

 get() is already pretty much a query processor so passing query strings to
 it won't require much work. Once we parse that info we still need to
 create an ID of some sort to use for option names, filters, and so on and
 also to provide some insulation from file naming changes. The existing id
 property in the screen object seems sufficient for these purposes. I doubt
 anyone will want to target to guid specificity.

 So, I guess we need to answer the question of how we want to pass screen
 info to ajax handlers and JS. We're currently all over the place. A guid
 is one simple string, but passing some sort of struct or query string is
 pretty simple too.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/21871#comment:20>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list