Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#27208 closed enhancement (wontfix)

Make add_filter and add_action available in wp-config.php

Reported by: denis-de-bernardy's profile Denis-de-Bernardy Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.8.1
Component: Bootstrap/Load Keywords:
Focuses: Cc:

Description (last modified by SergeyBiryukov)

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.

Attachments (4)

27208.diff (1.4 KB) - added by Denis-de-Bernardy 11 years ago.
27208.2.diff (1.4 KB) - added by Denis-de-Bernardy 11 years ago.
require works too
27208.3.diff (1.6 KB) - added by Denis-de-Bernardy 11 years ago.
27208.4.diff (543 bytes) - added by Denis-de-Bernardy 11 years ago.
Allow wp-config.php to include the file with add_filter() without crashing WP

Download all attachments as: .zip

Change History (16)

@Denis-de-Bernardy
11 years ago

require works too

#1 @Denis-de-Bernardy
11 years ago

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

#2 follow-up: @SergeyBiryukov
11 years ago

  • Component changed from General to Bootstrap/Load
  • Description modified (diff)

#3 in reply to: ↑ 2 @Denis-de-Bernardy
11 years ago

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.

#4 follow-up: @nacin
11 years ago

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.

#5 in reply to: ↑ 4 @Denis-de-Bernardy
11 years ago

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
11 years ago

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

#6 @Denis-de-Bernardy
11 years ago

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.

#7 follow-up: @Denis-de-Bernardy
11 years ago

@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.

Last edited 11 years ago by Denis-de-Bernardy (previous) (diff)

#8 in reply to: ↑ 7 ; follow-up: @SergeyBiryukov
11 years ago

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

#9 in reply to: ↑ 8 @Denis-de-Bernardy
11 years ago

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. :-|

This ticket was mentioned in IRC in #wordpress-dev by ddebernardy. View the logs.


11 years ago

#11 @Denis-de-Bernardy
11 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

Closing per IRC discussion.

#12 @helen
11 years ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.