[wp-trac] [WordPress Trac] #25669: Introduce helper function for AJAX checks

[WordPress Trac]

#25669: Introduce helper function for AJAX checks
-------------------------+------------------------------
 Reporter:  toscho       |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+------------------------------

Comment (by TJNowell):

 Replying to [comment:5 bpetty]:
 > Agreed, and I've been trying to find some time to come up with a similar
 solution that works well for all of our request state constants. Here's
 some of our other constants with the exact same problem as `DOING_AJAX`:
 >
 > {{{
 > DOING_AUTOSAVE
 > DOING_CRON
 > IFRAME_REQUEST
 > IS_PROFILE_PAGE
 > WP_ADMIN
 > WP_BLOG_ADMIN
 > WP_IMPORTING
 > WP_INSTALLING
 > WP_INSTALLING_NETWORK
 > WP_NETWORK_ADMIN
 > WP_REPAIRING
 > WP_SETUP_CONFIG
 > WP_USER_ADMIN
 > WP_USE_THEMES
 > XMLRPC_REQUEST
 > }}}

 Agreed, I'd prefer we got the `is_ajax_request` request committed first so
 it doesn't succumb to scope creep.

 > Also note that WordPress does not use the `wp` prefix with `is_*`
 methods. If we're following convention here, it would just be `is_ajax()`,
 or `is_ajax_request()` if you want to be really clear.

 Agreed, I'm happy for the suggested rename to `is_ajax_request`

 > However, do we want to clutter the global namespace with more non-
 prefixed `is_*_request()` methods (for all of the constants listed above),
 or work through a single object like `WP_Screen`? The latter option might
 require promoting `WP_Screen` to `wp-includes` instead of just admin, or
 building a somewhat different `WP_Request` object instead using the same
 design model.
 >
 > The reason I mention `WP_Screen` is because some of these request states
 are already being managed there. Take a look at `is_admin()`, which is
 controlled through `WP_Screen`. We're already providing this convenient
 wrapper (like the AJAX one being proposed) for some of these other
 constants with `is_admin()`. We're still not deprecating the constants
 behind that, but that was technically the preferred replacement for the
 following constants (of the ones I mentioned above):
 >
 > {{{
 > WP_ADMIN
 > WP_BLOG_ADMIN
 > WP_NETWORK_ADMIN
 > WP_USER_ADMIN
 > }}}

 A good point but perhaps that belongs in a new ticket with the other
 constants? As mentioned before, scope creep

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