Make add_filter and add_action available in wp-config.php

[Denis-de-Bernardy]

Per this comment here:

https://core.trac.wordpress.org/ticket/21663#comment:199

If it's a problem to introduce defines due to unit testing, we could simply make add_filter() available in wp-config.php to work around the problem.

Patch against 3.8.1 attached.

[Denis-de-Bernardy]

require works too

[Denis-de-Bernardy]

functions.php should likely get included too, so as to make __return_true and __return_false available.

[Denis-de-Bernardy]

Replying to SergeyBiryukov:

It would be *really* neat if this made it in WP 2.9, btw. I was scratching my head the other day on how to register an action from wp-config.php so as to boot a Symfony Kernel on the init hook without resorting to manipulating $wp_filter directly, and it then dawned on me that wp-settings.php uses require instead of require_once to include plugin.php.

[nacin]

The test framework actually has the ability to pre-add filters in config context. There are better ways to test things; we don't need this for unit tests.

While I can see the benefits, there is also a huge can of worms here. I don't have much of a desire for this to be a thing.

Side note, functions.php isn't needed. A callback doesn't need to exist until the hook is run, not when it is added.

[Denis-de-Bernardy]

Replying to nacin:

While I can see the benefits, there is also a huge can of worms here. I don't have much of a desire for this to be a thing.

Can you elaborate on that a bit? I honestly fail to see what could go wrong. I can only see benefits — especially in the context I just mentioned, i.e. integration between WP and third-party apps. Merely changing that require into require_once would be good enough for my sake. Can you please do at least that, so I don't need to worry about future compatibility of my $wp_filter hack?

Side note, functions.php isn't needed. A callback doesn't need to exist until the hook is run, not when it is added.

In that case the second patch is the one to use.

[Denis-de-Bernardy]

Allow wp-config.php to include the file with add_filter() without crashing WP

[Denis-de-Bernardy]

I've attached the most minimalistic possible patch to make integration between WP and third party apps more possible:

By using require_once instead of require, WP would no longer crash when its plugin API is included before loading WP itself.

[Denis-de-Bernardy]

@nacin or sergey: any odds you could get 27208.4.diff into 2.9? The only thing it does is change a require statement into a require_once statement, so as to allow developers to add WP filters prior to loading WP if needed.

In case it matters, my use-case is the following:

# www/index.php
$kernel = require __DIR__.'/../app/bootstrap.php';
$request = Request::createFromGlobals();
$response = $kernel->handle($request);

if ($response instanceof WPResponse) {
    # Load WordPress in the global scope and
    # re-inject the response back into Symfony using an output buffer
    $response->bootstrap($kernel, $request);
    require __DIR__.'/wp/index.php';
}
else {
    # Let Symfony send the response and terminate normally
    $response->send();
    $kernel->terminate($request, $response);
}

That method being:

# WordPressBundle\Component\Response class:
    /**
     * Sets up filters and post-processing needed to catch the WordPress output
     *
     * @param HttpKernelInterface $kernel
     * @param Request $request
     * @return Response $this
     */
    public function bootstrap(HttpKernelInterface $kernel, Request $request)
    {
        # Catch WP status header
        $GLOBALS['wp_filter']['status_header'][PHP_INT_MAX][__CLASS__.'::catchStatusCode'] = array(
            'function' => array($this, 'catchStatusCode'),
            'accepted_args' => 4,
        );

        ...
    }

As you can see in the above, things would be more sensible with an add_filter() call. I could admittedly require PHP 5.4 instead of PHP 5.3, since the latter allows to catch the status code using a built-in function. But I can readily picture other scenarios where adding a filter here and there without needing to load WP in full might be useful.

Moreover, I can foresee how fragile the above implementation is in the event the plugin API's internals change at some point or another.

[SergeyBiryukov]

Replying to Denis-de-Bernardy:

@nacin or sergey: any odds you could get 27208.4.diff into 2.9? The only thing it does is change a require statement into a require_once statement, so as to allow developers to add WP filters prior to loading WP if needed.

I don't have any objections to 27208.4.diff​, but we've stopped moving enhancements to 3.9 two days ago:
​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2014-03-03&sort=asc#m802537

[Denis-de-Bernardy]

Replying to SergeyBiryukov:

Replying to Denis-de-Bernardy:

@nacin or sergey: any odds you could get 27208.4.diff into 2.9? The only thing it does is change a require statement into a require_once statement, so as to allow developers to add WP filters prior to loading WP if needed.

I don't have any objections to 27208.4.diff​, but we've stopped moving enhancements to 3.9 two days ago:
​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2014-03-03&sort=asc#m802537

It would be really sweet if the patch could get checked in regardless. With a little luck I'll be done with my WordPress bundle at around the same time WP 3.9 gets released. :-|

[Denis-de-Bernardy]

Closing per IRC discussion.