plugin.php functions (filters) should be available to all pluggable components (wpdb, object cache)

[andy]

Problem: DB plugins (e.g. HyperDB) can't use add_filter or apply_filters in their configurations because these functions are unavailable at include time.

Discussion: The filter and action functions in plugin.php should be available to all pluggable components. This includes WPDB and WP_Object_Cache which should rely on these core programming patterns rather than reimplementing them. As these functions deal only with global variables, it is safe to include them earlier. Functions related to plugin_basename are not useful to WPDB or WP_Object_Cache but there is no danger in moving them as well.

Solution: Require plugin.php before require_wp_db().

[jacobsantos]

Question: How would one actually hook into these functions? No plugins would be loaded, because the DB will not have access to load those plugins yet. Is the assumption that a future feature will be added that autoloads for these requirements?

Question: How do the mentioned classes reimplement the plugin API?

Further Technical Details needed: Basically, the reasoning behind this is internal and contained component usage of the plugin API.

Counter-argument: You are using an pattern that is not appropriate for an Object-Oriented paradigm for simplicity and convenience sake only. Appropriate patterns already exist for what I assume you wish to use the Plugin API for in these classes.

Dissent: You are basically making a decision that will have lasting design decisions on the forward progress of the object-oriented paradigm within WordPress, without public debate and without initial discussion on the reasoning and purpose.

Reasoning: WordPress stands above other web applications for its great use of procedural code. Others may learn from its implementation. The same is not true for the objects within WordPress and it is getting worse.

There are no design decisions and most happen on a whim from independent minds based on individual skill, expertise and OO dogma. Given the elitist stances most OO programmers have, I suppose the "grounded" nature focusing on simplicity and ease of development is emphasized over more practical designs which limit rewrites and obsoleting classes; which since this never happens simply means more manure has to be shoveled on top of what is currently existing.

[filosofo]

Jacob, it looks like you wrote your comment in the style of Aquinas. I could live with that as a requirement for all Trac tickets.

[andy]

Replying to jacobsantos:

Question: How would one actually hook into these functions? No plugins would be loaded, because the DB will not have access to load those plugins yet. Is the assumption that a future feature will be added that autoloads for these requirements?

I want to use the 'query' filter and I want to be sure that every query is passed through my filter. However, the 'query' filter is only applied conditionally because apply_filters is not necessarily available when the first query is run.

There are typically several queries executed before plugins are loaded. Thus, if I want all queries to pass through my filter I must add my filter prior to the first query. Thus I must add my filter during the database configuration phase. This is impossible because the entire database inclusion phase is completed prior to the inclusion of plugin.php.

Strictly speaking, I can hack globals to add a filter any time I want. I don't like doing this, but I've done it. However, if I need to execute a query during the database configuration phase, my filters will not be applied because the 'query' filter is conditional upon the existence of a function in plugin.php.

While these are certainly edge and corner cases, they are not unrealistic. I created this ticket because HyperDB needs a query filter that never lets a query escape the filter. A new system is not needed; what is needed is add_filter and apply_filters. True story.

[ryan]

(In [15811]) Require plugin.php earlier so all pluggables can get at it. Props skeltoac. fixes #15042

[Denis-de-Bernardy]

Shouldn't the default filters be moved as well? After all, if we allow to plug things in, in wpdb for instance, we should also be able to plug things out without needing to hook into init.