Make WordPress Core

Opened 7 years ago

Closed 7 years ago

#17787 closed enhancement (wontfix)

A bunch of filters and minor fixes

Reported by: 5ubliminal Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.2
Component: Plugins Keywords:
Focuses: Cc:


First of all I removed the

unset($wp_filter); // in wp-settings.php

and setup a static counter in add_filter(). On the first run, it will reset the $wp_filter to an empty array(). It will also make sure on each run the $wp_filter is an array().

This allows plugins to hook even inside the wp-config.php if it includes the wp-includes/plugin.php file.

I added 1-2 filters to all functions that list plugin files. This way plugins can alter these lists. Still got a lot to test but the filters in place do absolutely no damage, but provide me the testing ground for some deeper modifications.

I also added 2 tweaks I carry on from version to version. A filter like this:

apply_filters( "query_template", $templates, $type );

located in the get_query_template() function allowing unitary management of template file array regardless of future WordPress changes.

Also added an extra parameter to login_init action in wp-login.php. Special actions exist for each $action but needed the general one to tell me where it's calling from.

do_action( 'login_init', $action ); // This was missing

Changes are commented and my name attached to each change so you know who to blame or ask questions.


Attachments (3)

filters-and-minor-tweaks.patch (5.5 KB) - added by 5ubliminal 7 years ago.
Fixes for mentioned improvements.
plugins-filters.patch (2.6 KB) - added by 5ubliminal 7 years ago.
Only the Plugins filters.
plugins-filters.2.patch (3.4 KB) - added by 5ubliminal 7 years ago.
One more tweak.

Download all attachments as: .zip

Change History (15)

7 years ago

Fixes for mentioned improvements.

#1 @scribu
7 years ago

It's not a good idea to bundle unrelated changes into a single patch and ticket.

I like the filters for plugin lists. This should be the main focus of the ticket. Please upload a new patch with just those.

Please open a new ticket for unset($wp_filter), with a clear explanation of the benefit, as well as some solid benchmarks and tests. That function is critical.

As for the 'query_template' filter, see #14310

Last edited 7 years ago by scribu (previous) (diff)

#2 @scribu
7 years ago

Also, there should be a new ticket for the 'login_init' filter.

Finally, please don't put @author tags in the code. They discourage collaboration.

#3 @5ubliminal
7 years ago

I just wanted to make sure you know where the code is from. Assumed you clean things yourself... when you look into it. Not sure how SVN works... quite new to this. Miracle I got so far.

Will submit a new patch with filters for plugins functions and split the others up also.

Thanks for the prompt reply.

#4 @scribu
7 years ago

If you're using Linux or OSX, you can make partial patches like this:

svn diff file-a.php file-b.php file-c.php > the-patch.diff

If not, you can edit it directly in a text editor.

Last edited 7 years ago by scribu (previous) (diff)

7 years ago

Only the Plugins filters.

#5 @5ubliminal
7 years ago

The filter thing has no benefit due to how WP is designed... Never mind it.

#6 follow-up: @nacin
7 years ago

I see no reason for these filters.

In order to take advantage of these, you need to have full control over your environment. Which means if you need to tweak your mu-plugins, do so. There are plenty of filters available in the admin side for plugins and network plugins.

7 years ago

One more tweak.

#7 @5ubliminal
7 years ago

I added my final change. Right before mu-plugins are loaded WP looks for a wp-plugins.php file in ABSPATH or ABSPATH/../ (parent). Just like it does for wp-config.php.

In that file I am able to register filter to add custom (MU/regular) plugins to the loading blog. My main goal is to add custom folders for a multi wp-config.php installation that gives access to custom plugins path.


Blog x.com, y.com and z.com are installed in same installation. Wp-config.php detects name from domain and loads wp-x.com-config.php and so on. Then I have WP_PLUGINS_DIR and WPMU_PLUGINS_DIR with the global plugins. I want to add two more folders (still implementing but those filters are vital) with plugins designed for blogs. So a blog could have WPMU_LOCAL_PLUGINS_DIR added and listed along.

I have something like this but I would like it integrated in your plugin manager which is better and provides an unitary experience.

Nevertheless, those filters hurt nobody but allow those who really mold WordPress by their needs to take full control.

Thanks, hope it makes some sense.

PS: I mu-plugins, only base directory php files are loaded. I have a single base directory file that loads plugins located in level 1 folders. With these filters, not only do I load those plugins but I can actually make them visible in the MustUse list which I could not.

#8 @nacin
7 years ago

You can do this without filters.

Put global plugins in WPMU_PLUGINS_DIR. Conditionally define WP_PLUGINS_DIR wherever you think it should go for that site.

Or, conditionally load a folder on plugins_loaded.

These hooks don't make any difference in fulfilling the flexibility you want.

The Must Use list is a nice to have, but I'd rather it wasn't in core. There's no real need to have them visible especially in a peculiar setup such as yours.

#9 @5ubliminal
7 years ago

I aim for two WP_PLUGINS_DIR. One global, for all the blogs installed, and one per blog. I have over a hundred plugins in the global WP_PLUGINS_DIR. And another folder with Theme/Blog specific stuff...

It does not really matter actually. These filters hurt no one if they remain and I AM sure that some may make good use of it. The others will not even reach them...

I always thought WordPress was about versatility. Altering plugin lists is versatility's FATALITY (Mortal Kombat stuff).

PS: I also dream of plugin categorization, a new plugin data Category: header to group those who handle comments, UI, posts, etc...

#10 in reply to: ↑ 6 @scribu
7 years ago

Replying to nacin:

There are plenty of filters available in the admin side for plugins and network plugins.

I was going to disagree with you, but then I found the 'all_plugins' filter, which would make the proposed 'get_plugins' filter unnecessary.

Replying to 5ubliminal:

These filters hurt no one if they remain

The problem with adding filters is that we have to maintain backwards compatibility for them, so we have to do it right the first time.

#11 @5ubliminal
7 years ago

I give up. I'll just find my way in and hack things with a plugin, as I already do...

Thanks for putting up with my WordPress eccentricities :)

PS: Hope the general get_query_template() (11 months old ticket you sent me) will make it in the core while I'm still shading the earth.

 * Allow the use of one major filter named 'query_template'.
 * Only if the returned value is an array() will it be used to replace previous array().
 * This is to prevent accidental returns of NULLs or such.
if(is_array( $new_templates = apply_filters( "query_template", $templates, $type ) ) and !empty( $new_templates )){
	 $templates = $new_templates; // Assign new array as it passed type and content validation

It's up to you to have this implemented. My version has two parameters and while the old one has just 1.

#12 @SergeyBiryukov
7 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

As per the comments above, no additional filters are needed.

Note: See TracTickets for help on using tickets.