[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 nacin):

 It should be noted that the vast majority of those constants are internal
 use only.
 * IS_PROFILE_PAGE - used on user-edit.php to tell if you are editing the
 current user (the profile), and really not needed.
  * WP_ADMIN - is_admin()
  * WP_BLOG_ADMIN - is_blog_admin()
  * WP_INSTALLING_NETWORK - used to load translations on wp-
 admin/network.php
  * WP_NETWORK_ADMIN - is_network_admin()
  * WP_REPAIRING - used as a config-level flag to access the maintenance
 script
  * WP_SETUP_CONFIG - internal use only
  * WP_USER_ADMIN - is_user_admin()
  * WP_USE_THEMES - should never be referenced outside of core, only maybe
 defined (but including wp-load.php is better)

 The seven remaining ones are a mixture of constants plugins can use and
 constants only core should use, but would be helpful to modify for testing
 purposes.
  * DOING_AJAX
  * DOING_AUTOSAVE
  * IFRAME_REQUEST
  * WP_IMPORTING
  * WP_INSTALLING
  * XMLRPC_REQUEST
  * DOING_CRON

 Side note, we've discussed using $_ENV as a way to test functions that
 rely on certain constants (like ABSPATH).

 When ryan and I designed WP_Screen, it was indeed meant as a more general
 bucket than just the administration interface. It just hadn't gotten to
 that point yet.

 is_wp_ajax_request() makes sense. We use wp_is_* sometimes, bpetty is
 right that we generally omit 'wp_', but we do use wp_is_* sometimes. So
 why is_wp_ here? Because it's not about prefixing, it's about the
 specificity of the kind of ajax request. is_ajax_request() would make me
 think it is checking a `X-Requested-With: XMLHttpRequest` header, versus
 specifically being an admin-ajax.php request.

 It might also be good to step back for a moment and think about the
 ''problem'', rather than the solution. ''Why'' do people need to check
 DOING_AJAX? Why does core need to check DOING_AJAX? Why do we need to
 allow it to be filterable? What are our end goals?

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