[Plugin: WP Super Edit] Advanced Link dialog white screen

I just pushed an update for wp-super-edit/trunk that uses plugin_url() instead of WP_PLUGIN_URL, so if the domain mapping plugin is using the plugin_url filter then this might work. I’ll put this through a couple of tests on a subdomain multisite that admin, but I don’t have a domain-mapped site to test on.

The iframes would definitely fail if WP_PLUGIN_URL isn’t getting set with a proper URI or might fail if it’s returning a cross-site URI. It looks like plugin_url() should have some multi-site checks. You might have to check the wp_super_edit_plugins table because it does have a url field that would allow you to do custom URL(s) for TinyMCE plugin development support, but I haven’t developed it further. It really doesn’t have any multisite support.

If that doesn’t work, then we need to check to see if the domain mapping plugin developers are using the plugin_url filter or can do another method to make sure plugin_url() returns https://mymappedsite.com/wp-content/plugins.

I’ll probably commit a point update later today or tomorrow.

I’ll test it as soon as it comes out and let you know the results.

I’m awed by your willingness to quickly address an issue that I have seen raised by no one else.

My sincere thanks.

I just installed the update and it is functioning on a child site without it being activated on the parent site. So for me — yipppee!

The one thing that is not perfect is the dialog display which shows

{#advlink_dlg.general_props}
{#advlink_dlg.url}

and so on rather than buttons or words, which will be a problem for a user who does not know what the tags mean. I do know what they mean and am happy as pie.

When the plugin is activated on the parent site, all the dialogs appear properly for posting on that parent site. The dialogs of children sites still show the code rather than the buttons.

Let me know if there are any tests I can do or anything else to help.

Thank you so much for tending to this.

I need to note that in the upcoming WordPress 3.1 release, the link dialog will be dramatically changed, so this may change the dynamics of this particular problem.

I did find a method to check the URL for the language files. Using the Firebug extension for the Firefox web browser you can examine the DOM for the post or page editing in WordPress.

Once you visit the Post or Page edit, look in Firebug under the DOM tab. You should see an object named tinymce in all lowercase (not the tinyMCE object). Expand the “tinymce” object and look for “ScriptLoader” and expand that. You should see URL(s) looking in a /advlink/ directory. See what those URL(s) look like. You might have en.js and en_dlg.js files, but I don’t think that will matter.

If the URL(s) look correct, then see where they go and look for weird 404 errors. Also check the source code for the edit screen to see if there are URL(s) point to weird places. If any URL is off, then the browsers may see the remote file as a XSS threat.

I’ll be working on WP 3.1 compatibility soon, so we may have to revisit this issue after the release. Feel free to send me any more information that you find either here or via e-mail especially since I don’t have a domain mapping site to test with.

All of the paths work except one. Going thru the steps you outlined, I did find it trying to call

\wp-super-edit\tinymce_plugins\advlink\en.js

and that file does not exist.

I downloaded a fresh zip of Super Edit to see if I had somehow lost the file, but it isn’t in the download package.

The same file is called for in

/wp-includes/js/tinymce/langs/en.js

and that doesn’t exist either.

But, I don’t see how this could be the problem since if the en.js file is essential then it shouldn’t display properly on the parent page and it does.

I also tried hard-coding the path references in link.htm both URI and URL paths but it seemed to have no effect.

But I may be on to something. In exploring I found the file tiny_mce_popup.js which contains the instruction

// Uncomment and change this document.domain value if you are loading the script cross subdomains
// document.domain = 'moxiecode.com';

I uncommented and inserted my domain. Ended up with the pure white screen iframe. I tried several different domains (of the same parent) and they all resulted in white screens. Commenting the line out returned me to the functional but incorrectly rendered iframe.

I actually have no idea how to be helpful here. Since 3.1 is coming soon, perhaps best to leave off this problem until then?

Just finished testing under 3.1

It works perfectly!

Mark this issue as completely resolved.

No it is not working !!! I have installed it and nothing is working under 3.1 cant see what the plugin is suggesting …

I was finally able to reproduce an issue causing the editor to malfunction on older websites using WP Super Edit.

I couple versions ago I moved the “Custom CSS Classes” and “Super Emoticons” from being just “TinyMCE” plugins to being separate “WordPress Plugins”. This was done because those two (and other personal ones) have functionality that requires more access to the WordPress internals, so they have to be activated as separate WordPress plugins.

This fixed an issue dealing with callback functions that I shouldn’t have been doing in the first place. Unfortunately it looks like it broke some sites that may have had these active for a long time.

The easiest solution is to reload WP Super Edit.

1. Make a note of the Editor Plugins activated and the position of the buttons for your editor.
2. Go to the WP Super Edit Options tab and press the Uninstall WP Super Edit Database Tables button. This will remove the tables for WP Super Edit from your database.
3. Go to the WordPress plugins area and make sure that WP Super Edit is the only active plugin. If the Theme Classes or Emoticon plugins are active, deactivate them.
4. Go back to the Settings > WP Super Edit area and press the Install WP Super Edit button.
5. If you want to use the WP Super Edit Theme Classes or Emoticon plugins, go back to the WordPress plugin area and activate those plugins.

Unfortunately this will clear out all settings for the buttons and plugins that you may have had previously. You have my sincerest apologies.

If you are brave, before you do any of this do a backup of the wp_super_edit_users table in your database. That table stores the actual button configurations, so you may be able to replace that table AFTER the reinstall and get some of your user’s configurations working as before. I haven’t tested this, but it should work.