#27208 closed enhancement (wontfix)
Make add_filter and add_action available in wp-config.php
Reported by: | Denis-de-Bernardy | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.8.1 |
Component: | Bootstrap/Load | Keywords: | |
Focuses: | Cc: |
Description (last modified by )
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)
Change History (16)
#1
@
11 years ago
functions.php
should likely get included too, so as to make __return_true
and __return_false
available.
#2
follow-up:
↓ 3
@
11 years ago
- Component changed from General to Bootstrap/Load
- Description modified (diff)
#3
in reply to:
↑ 2
@
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:
↓ 5
@
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
@
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.
#6
@
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:
↓ 8
@
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.
#8
in reply to:
↑ 7
;
follow-up:
↓ 9
@
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 arequire
statement into arequire_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
@
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 arequire
statement into arequire_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. :-|
require works too