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

WordPress Trac noreply at wordpress.org
Thu Oct 24 20:43:37 UTC 2013


#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 bpetty):

 Replying to [comment:8 nacin]:
 > It should be noted that the vast majority of those constants are
 internal use only.

 I agree with @toscho's use case, and you're right that it's mostly
 irrelevant to internal constants, however, I'd like to ensure that
 whatever is decided here is compatible with a second goal: to stop abusing
 constants to store application states that have been tormenting us with
 unit testing problems. Very few core contributors understand the
 implications of our hack surrounding `@runTestsInSeparateProcesses` used
 without disabling `@preserveGlobalState`, but with our default
 `prepareTemplate()` override that prevents preserving global constants.
 Ideally we shouldn't even be using `@runTestsInSeparateProcesses`. It's
 inefficient, difficult to debug, and we're only doing it because we can't
 reset these constants for the next test (confirming that they aren't
 actually constant, and never should have been defined as such).

 That specifically applies to internal request state constants, not just
 ones likely to be used with plugins and themes. Even if it didn't though,
 telling plugin developers that request states are handled like this, and
 then using a different approach internally is inconsistent and confusing.
 On the other hand, so is offering a filterable `wp_is_ajax()` that could
 result in a different state than the (still supported) `DOING_AJAX`
 constant since it can't be changed, but that's just an argument for
 deprecating the constant and actually removing it at some point.

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

 What is the idea proposed here? Have a link to the discussion?

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


More information about the wp-trac mailing list