Fixed a bug at multisite blogs

[richterd]

plugin_dir_url() and content_url() are returning different domain names and then substr() cuts the string at the wrong place

[johnclause]

Hi Daniel, Could you give example of what plugin_dir_url() and content_url() are returning on your server? Do they have "http://domain ..." part?

[richterd]

Hi,
one further information: we are using the WordPress MU Domain Mapping plugin.

In our case:
plugin_dir_url() is returning the correct domain of the current site (http://www.example.net/wp-content/plugins/)

content_url() is returning the root domain on which the wordpress multisite network was installed. (http://www.root-domain-of-network-installation.net/wp-content/)

I assume that the domain mapper is overwriting / changing the content_url() return value.
Another situation in which the bug might appear: If you are using a CDN you can change the content_url to point to the CDN, while plugin_dir_url() will still return the blog domain.

As both functions have different code (e.g. WP_CONTENT_URL in case of content_url()) and different filters, one should not rely on getting the same domain returned from both.

Best regards,
Daniel Richter

[johnclause]

Some people customize "wp-content" string. How do we go about that? Maybe we should use a different approach all together? What that would be?

[richterd]

That's true. Can you give me a precise definition of what the function has to return? Or in other words: Why is the "plugin dirname from wp_content" not hard coded, e.g return '/qtranslate-x/...' ?

I will have a look at that on Monday, and hopefully come up with a implementation free of constants.

Greetings

[johnclause]

File paths in options are counted from WP_CONTENT_DIR folder. We need to find out a relative path to a file within qtranslate-x subfolder from WP_CONTENT_DIR folder. String "/qtranslate-x/" can also vary when people install development version, it is something like "/qtranslate-x-3.4.4/". Also plugin can be installed under standard "plugins", or it can be under "mu-plugins", not to mention that it is possible to customize that too. There is also business with folder links resolved vs unresolved. Some people link folders to some place else to share plugins set between a few sites.

The return string should be such that WP_CONTENT_DIR.'/'."returned_string" is a full path to the plugin folder without trailing slash. Similarly, WP_CONTENT_URL.'/'."returned_string" should be a URL to the plugin folder.

Normally this function return "plugins/qtranslate-x", but it can be "mu-plugins/qtranslate-x", or "plugins/qtranslate-x-xxx", etc.

I wish WP would have a way to extract such relative path. Maybe I did not look closely enough and they have it somewhere?

[richterd]

What do you think of that solution?

[johnclause]

Yes, it will work most of the time, but not 100% either. In multisite case, is url http://www.root-domain-of-network-installation.net/wp-content/plugins still work? I mean content_url()/.'plugins'? Or plugins are physically in different places for different sites? Why did WP separate it in such a way? Is there a function on multisite setup which returns 'plugins' common for all sites like they did with content?

[richterd]

Sorry, I don't get your questions. As plugin_dir_url() is returning the correct url in a multisite installation, it does work for multisites, yes. Typically you have the two folders plugins and mu-plugins in a multisite installation which are on the same place for all sites.

[johnclause]

You mention before that

content_url()/.'plugins'

and

plugin_dir_url()

are different URL, in your example:

http://www.root-domain-of-network-installation.net/wp-content/plugins/
http://www.example.net/wp-content/plugins/

If they point to a different physical location, then we have a bigger trouble, the plugin will not work at all, since it counts paths in options relative to 'content_url()'. If they are supposed to go to the same physical location on the server, then I do not understand why WP made those pats to be different.

What is their theory behind?

[johnclause]

Hi Daniel, could you test the latest version from the GitHub? I did not test it on multisite, but in my theory it should work.

If you have time, please test it with having plugin in both places for plugins, network path and specific domain path. As far as I understood plugins can reside in 4 places under multisite: common for all domains place, specific for each domain place, and those two for must-use plugins. QTX is not designed to work as must-use, because activation hooks will not work, but other two places should both work. Please, confirm.

[monkkeys]

I have confirmed that this fixed the issue. I was having issues with the Language Switching Buttons and flags not showing up after I mapped a domain to my multisite using WordPress MU Domain Mapping. I just downloaded the version 3.4.5.4 from GitHub and applied it, and everything is just as it was before the mapping, but on the mapped domain. Excellent work team!

[johnclause]

Thank you! I am closing this issue then, we can still write into a closed issue, or we can re-open it, if needed.