Fixed a bug at multisite blogs

[herrvigg]

Issue by richterd
Friday Sep 04, 2015 at 08:05 GMT
Originally opened as qTranslate-Team/qtranslate-x#243

---

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

---

richterd included the following code: https://github.com/qTranslate-Team/qtranslate-x/pull/243/commits

[herrvigg]

Comment by johnclause
Friday Sep 04, 2015 at 15:40 GMT

---

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?

[herrvigg]

Comment by richterd
Friday Sep 04, 2015 at 16:34 GMT

---

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

[herrvigg]

Comment by johnclause
Friday Sep 04, 2015 at 17:27 GMT

---

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?

[herrvigg]

Comment by richterd
Friday Sep 04, 2015 at 17:47 GMT

---

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

[herrvigg]

Comment by johnclause
Friday Sep 04, 2015 at 18:08 GMT

---

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?

[herrvigg]

Comment by richterd
Monday Sep 07, 2015 at 08:40 GMT

---

What do you think of that solution?

[herrvigg]

Comment by johnclause
Wednesday Sep 16, 2015 at 17:06 GMT

---

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?

[herrvigg]

Comment by richterd
Thursday Sep 17, 2015 at 08:45 GMT

---

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.

[herrvigg]

Comment by johnclause
Thursday Sep 17, 2015 at 19:48 GMT

---

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?

[herrvigg]

Comment by johnclause
Wednesday Sep 30, 2015 at 05:34 GMT

---

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.

[herrvigg]

Comment by monkkeys
Sunday Oct 04, 2015 at 14:02 GMT

---

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!

[herrvigg]

Comment by johnclause
Sunday Oct 04, 2015 at 15:51 GMT

---

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