[wp-hackers] TinyMCE plugin issues in domain mapped multisite config related to WP_PLUGIN_URL usage

[Jess Planck]

Most folks with mention that it has been suggested to use plugins_url() and the other helper functions. BUT I'm sure TinyMCE is partly to blame, BUT so are the strict rules to reduce XSS.

It appears that TinyMCE uses a helper function to remotely load languages using javascript. In my case this worked fine since I had a WordPress multisite in sub-directory or sub-domain mode. UNTIL I enforced SSL. Then all the TinyMCE language includes failed miserably for any external TinyMCE plugin. The only way to work around the was to include the language packs in the source code for the edit post page rather than remotely loading them via JS. It sucks, but makes perfect sense for the paranoid. I'm guessing the SSL rules for most browsers are just a tad more paranoid.

Jess

On Sep 2, 2011, at 12:28 PM, Ken Brucker wrote:

> I ended up copying Andrew Ozz's method too (Thank you Andrew for paving the way!)
> 
> I do think there's a bug in here, just not sure if it's the definition of WP_PLUGIN_URL or in the assumptions wp_tiny_mce() makes for locating the plugin language files.  My gut instinct is that WP_PLUGIN_URL should use the mapped domain name and not the network multi-site name.  But I'm not sure what could break if such a change is made.  
> 
> I do see that both WP_CONTENT_URL and WP_PLUGIN_URL use the network name, even when the mapped name is requested for the Admin pages.  I don't have a development MU site setup or I'd play more with this right now.
> 
> -- Ken
> 
> On Sep 2, 2011, at 10:03 AM, Jess Planck wrote:
> 
>> Had the same issue with other multisite installs and ended up using Andrew Ozz's method of pulling in language strings in the TinyMCE Advanced plugin. 
>> 
>> I'm sure there has to be a better way to handle external TinyMCE plugins, but at least this kinda works. 
>> 
>> Jess
>> 
>> On Sep 2, 2011, at 9:49 AM, Ken Brucker <ken.brucker at action-a-day.com> wrote:
>> 
>>> I'm working on a plugin that has a TinyMCE plugin with popup and am running into issues trying to use it in a multi-site configuration with domain mapping enabled.
>>> 
>>> What I've found is that WP_PLUGIN_URL is set to the network URL while plugins_url() returns the mapped URL.  When the admin screens use the mapped name, this is creating several issues because some elements of the screen are referenced via the network URL and some via the mapped URL.
>>> 
>>> I've got two scenarios, neither of which work:
>>> 
>>> 1) Plugin uses WP_PLUGIN_URL to register the TinyMCE plugin via mce_external_plugins filter
>>> 
>>> Result is XSS scripting violation because the tinymce popup iframe is using the network name while the admin page uses the mapped name.
>>> 
>>> 2) Plugin uses plugins_url() to register the plugin
>>> 
>>> The scripts run, but the tinymce/langs files are not retrieved because the logic in wp-admin/includes/post.php:wp_tiny_mce() around line 1498 mangles the translation.  The code tries to filter using WP_PLUGIN_URL (network name) which won't match the incoming URL that uses the mapped name.  The resulting file system path has the mapped URL path embedded so the subsequent searches for the language files fail.
>>> 
>>> What's not clear to me if the issue is the WP_PLUGIN_URL value or the code in wp_tiny_mce().  In a multi-site domain mapped environment what should WP_PLUGIN_URL be?  If the admin screen is also supposed to use the mapped URL should WP_PLUGIN_URL be the mapped domain so all is 100% consistent?
>>> 
>>> After examining some other plugins it appears the workaround is to setup a tinymce/lang    s/langs.php to do the right thing to find the .js language files.  This extra code in each plugin to do this correctly wouldn't be required if wp_tiny_mce() was able to handle multi-site domain mapped configs.  If wp_tiny_mce() did the right thing it would also lower the bar for plugins to support multi-site configs.
>>> 
>>> This has been a bugger to sort out why popups in a multi-site were failing.
>>> 
>>> -- Ken
>>> 
>>> 
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> 
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers