[wp-trac] [WordPress Trac] #12400: Add a wp_loaded hook, an ob_start hook, and an front end ajax hook

[WordPress Trac]

#12400: Add a wp_loaded hook, an ob_start hook, and an front end ajax hook
-------------------------------+--------------------------------------------
 Reporter:  Denis-de-Bernardy  |       Owner:     
     Type:  feature request    |      Status:  new
 Priority:  normal             |   Milestone:  3.0
Component:  General            |     Version:  3.0
 Severity:  normal             |    Keywords:     
-------------------------------+--------------------------------------------
Description changed by Denis-de-Bernardy:

Old description:

> Requests for some kind of wp_loaded hook have crept up here and there in
> trac over the years.
>
> Typically, the requester is looking into doing front-end ajax requests
> and the like. There are other use cases, such as wanting to catch
> specific URIs -- e.g. a trailing /print/ to the url, which the permalink
> API is incapable of catching.
>
> They all got rejected on grounds that there is the init hook that can be
> used just as well for ajax. Or the template_redirect hook in place of an
> ob_start hook. The list goes on.
>
> When you want WP and plugins to be loaded '''and''' fully initialized,
> instantiated and ready to go, setting a priority to obscene levels on the
> init hook works (I typically use 1000000)... but it always feels like
> you're working around a crippled API.
>
> Starting output buffers on template_redirect with a priority -1000000
> feels equally clunky.
>
> Then, there is the front-end ajax. Yes, admin-ajax.php can be used
> unauthenticated... But the fact of the matter is, you can end up with SSL
> turned on when it's not useful, and the lack of an wp-ajax.php file makes
> many a plugin dev wonder where in the bloody hell he place hooks to catch
> his requests.
>
> It would be sweet if this all got fixed in WP 3.0.
>
> The argument that goes "a hook already exists" seems extremely invalid to
> me. There are many places in WP where two hooks (and oftentimes many
> more) can be used to achieve the same result. Think wp_headers and
> send_headers, for instance. What they have in common is some kind of
> before/after flow, which init and template_redirect are currently
> lacking.
>
> One could argue that parse_request is nearby init, and that wp is nearby
> template_redirect, so they'd be good enough. But the first of these
> parses expensive regular expressions before firing, and both are only
> known to WP junkies.
>
> Suggested hooks for WP 3.0:
>
>  - a wp-ajax.php file built similarly to admin-ajax.php.
>  - an wp_loaded hook at the very end of wp-settings.php, with a
> commentary that tells plugin authors that init should be used to
> instantiate, wp_loaded should be used to act once everything is
> instantiated, and that wp-ajax.php has hooks that are specific to ajax
> requests.
>  - an ob_start (or pre_load_template, or whatever...) hook at the very
> beginning of template-loader.php, with a commentary that tells plugin
> authors that the new hook should be used to instantiate such as output
> buffering once WP is fully loaded, while the second is traditionally used
> to pick an arbitrary template.

New description:

 Requests for some kind of wp_loaded hook have crept up here and there in
 trac over the years.

 Typically, the requester is looking into doing front-end ajax requests and
 the like. There are other use cases, such as wanting to catch specific
 URIs -- e.g. a trailing /print/ to the url, which the permalink API is
 incapable of catching.

 They all got rejected on grounds that there is the init hook that can be
 used just as well for ajax. Or the template_redirect hook in place of an
 ob_start hook. The list goes on.

 When you want WP and plugins to be loaded '''and''' fully initialized,
 instantiated and ready to go, setting a priority to obscene levels on the
 init hook works (I typically use 1000000)... but it always feels like
 you're working around a crippled API.

 Starting output buffers on template_redirect with a priority -1000000
 feels equally clunky.

 Then, there is the front-end ajax. Yes, admin-ajax.php can be used
 unauthenticated... But the fact of the matter is, you can end up with SSL
 turned on when it's not useful, and the lack of an wp-ajax.php file makes
 many a plugin dev wonder where in the bloody hell he should catch his own
 requests.

 It would be sweet if this all got fixed in WP 3.0.

 The argument that goes "a hook already exists" seems extremely invalid to
 me. There are many places in WP where two hooks (and oftentimes many more)
 can be used to achieve the same result. Think wp_headers and send_headers,
 for instance. What they have in common is some kind of before/after flow,
 which init and template_redirect are currently lacking.

 One could argue that parse_request is nearby init, and that wp is nearby
 template_redirect, so they'd be good enough. But the first of these parses
 expensive regular expressions before firing, and both are only known to WP
 junkies.

 Suggested hooks for WP 3.0:

  - a wp-ajax.php file built similarly to admin-ajax.php.
  - an wp_loaded hook at the very end of wp-settings.php, with a commentary
 that tells plugin authors that init should be used to instantiate,
 wp_loaded should be used to act once everything is instantiated, and that
 wp-ajax.php has hooks that are specific to ajax requests.
  - an ob_start (or pre_load_template, or whatever...) hook at the very
 beginning of template-loader.php, with a commentary that tells plugin
 authors that the new hook should be used to instantiate such as output
 buffering once WP is fully loaded, while the second is traditionally used
 to pick an arbitrary template.

--

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