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

[Ken Brucker]

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