'content_url' (and other *_url() functions) not filterable

[krudolph]

Hi,

A call to content_url invariably returns the whole path, including the "http[s]:" prefix and the server name. This may not be desired. In fact, I've written a filter function for option_siteurl and option_home to strip all local URIs off their server name, i.e. "​http://example.com/blog/x" becomes "/blog/x".

However, since content_url isn't pluggable, my filter function doesn't catch all URIs (especially not theme-related URIs such as the stylesheet link). Actually, content_url uses WP_CONTENT_URL, which, in turn, calls get_option('siteurl'), which, in turn, is pluggable. Unfortunately, this call is made before filter functions get registered because WP_CONTENT_URL is a global constant.

I propose two possible solutions:

• Make WP_CONTENT_URL a function. Since the constant is for internal use only, the scope of this change should be local. This solution would be preferred because it means that one hook would suffice to manipulate all local URIs created by WordPress.

• Make content_url pluggable.

[DD32]

how about defining the constants after plugins are loaded?, or filtering the output of content_dir() (and its friends)

[krudolph]

Replying to DD32:

how about defining the constants after plugins are loaded?

Well, since the constant is set in WP's core there's no chance of that. Reading the wp-config.php file is definitely required before plugins and themes can be loaded.

or filtering the output of content_dir() (and its friends)

I suppose you mean content_url (since there's no content_dir function anywhere in the code base)? As I wrote, its content cannot be filtered (that's what I meant by “not pluggable”).

[DD32]

Well, since the constant is set in WP's core there's no chance of that. Reading the wp-config.php file is definitely required before plugins and themes can be loaded

Sorry, It was late :/ I was thinking "URL's are in defines, Dir's are in functions"..

By moving them after the plugins are loaded, i was refering to the default values, with the thought "If a user defines it manually, thats what they want full stop" in the back of my mind.

I suppose you mean content_url (since there's no content_dir function anywhere in the code base)? As I wrote, its content cannot be filtered

Ah yeah.. I meant the content_url() and family, some plugins will use the constants, others will use the functions though, so be warned there..

that's what I meant by “not pluggable”).

Sorry, "pluggable" means Function-replace, While "filtered" means having a filter available to me, thats probably what got me a bit confused.

Adding a filter to the *_url() functions would be a good move IMO, but, as i said before, not all plugins use it, and a fair few are going to rely on the constants directly.

[coffee2code]

In link-template.php, site_url() is filterable, yet its associates are not:

• admin_url()
• includes_url()
• content_url()
• plugins_url()

The attached patch, bug7709.link-template.diff, simply makes the url that would be returned from each of those functions filterable.

[ryan]

(In [10983]) Add url filters. Props coffee2code. see #7709