#11862 closed defect (bug) (duplicate)
the_editor js bug when switching between Visual / HTML with multiple on page
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 2.9.1 |
Component: | Editor | Keywords: | |
Focuses: | Cc: |
Description
First instance works flawlessly, however second and subsequent instances have issues with switching between Visual / HTML mode.
- Setup multiple instances of the_editor on page, with normal scripts (no JS errors on page when using them)
- Switch between Visual / HTML on second / subsequent editors on the page, you'll see an issue with the HTML view toolbar appearing / disappearing on the first instance.
- If first instance is in HTML view, the HTML toolbar will disappear as you select second / subsequent editors into HTML view. Upon switching first editor back to Visual (visual toolbar appears) then to HTML (the HTML toolbar appears).
OTHER NOTE: Tested in Google Chrome and Firefox
Attachments (2)
Change History (15)
#2
@
14 years ago
- Keywords needs-patch added
- Milestone changed from Unassigned to Future Release
Setting to Future Release until a patch is added.
#4
@
14 years ago
- Summary changed from the_editor error when switching between Visual / HTML with multiple editor boxes on page to the_editor js bug when switching between Visual / HTML with multiple on page
#5
@
14 years ago
I'm willing to pay for this bug fix, if someone wants to step up and take it on. I'm sure my sacrifice along with your sacrifice will help WP core code be used in more ways. I'm excited that the Pods plugin will be switching to TinyMCE core code for the TinyMCE, but this is the only thing holding us (and other plugins) back from using the default core code.
I assume the_editor was meant to be generalized so that it could be used in more than one place, since the actual functionality works (apart from this bug) when it's used multiple times on a page.
Please consider this ticket for the very next bug fix release (if at all possible).
#6
@
14 years ago
I've been working on a patch for this issue, and I'm at a point where I need to get a sanity check. While I am certain that the code can be updated to make the function work properly with multiple instances, I'm not so certain that such a patch would ever be accepted into core.
I've attached the working copy of my patch as it stands currently as well as a brief plugin that simply adds a second instance of the_editor to the posts and pages editors. Using these together will allow for testing of this idea.
The current patch solves the problem as Scott described it while also exposing the level of work required to get this solution properly coded. The patch allows for more than one instance of the editors to coexist with the HTML and Visual tabs working as expected.
The following are known issues with the current patch:
- The "Insert into Post" media upload feature always adds to the first editor.
- The HTML quick links always use the last editor.
There are some additional issues that are related to use. For example, the the_editor function does not handle generating the table that creates the bottom part of the editor which contains the resize handle. This means that there are additional coding needs beyond just using the_editor. This table is also styled in such a way that using matching IDs and classes for the table structure is all but necessary to get the same look, this causes issues with the word count JS code.
Due to these issues, I'm wondering if my efforts wouldn't be better spent on creating a patch that duplicates the functionality of the_editor but does so in a way that doesn't affect any of the code and styling that the_editor currently uses. After a time, the the_editor function could be deprecated and all the core code would use the new function.
I'd like to get some thoughts on what other developers would like to see as it relates to this issue and what type of solution would be desired.
#8
@
14 years ago
Given the past history of other types of tickets like this regarding multiple editors, I'm not sure how open the Core team is to something like this. It's obvious that it's necessary, but perhaps it's not a big priority for them. If the patch was created in a way that they could spend a minimal amount of time on it, I'd say maybe there's a chance. I don't see why they wouldn't want a built-in function that plugins could use / reuse.
Either way, if you get something working and they don't decide to run with it, I'd be interested in getting a version of your patch which could be independently used in plugins. Perhaps it would be good to set some sort of standard way for plugins to fulfill their needs that the_editor() doesn't currently fit.
#10
@
14 years ago
Generally TinyMCE can be added as many times as needed on the same page. For the edit page all it needs is another instance of it and another textarea since all the JS files are already loaded there. I believe there are quite a few plugins doing this.
However the HTML editor doesn't easily support multiple instances and the script that switches visual -> HTML mode doesn't support them at all. To fix this we will have to start with the HTML editor and make it true multi-instance capable (use JS objects, multiple settings/buttons, no global JS vars, etc.). Then we can fix the script that switches editors. Of course that will break all plugins that currently add buttons to the HTML editor.
#11
@
13 years ago
I've had some work done on this recently, I'm going to review and see if I can post a patch that could solve some of the issues I've had previously.
#12
@
12 years ago
- Keywords needs-patch removed
- Resolution set to duplicate
- Status changed from new to closed
Fixed in WP 3.3 with the brand spankin new WP Editor API (Ticket #17144) from @azaozz, glad to help him get it tested and moved along (we included a pre-release version of it this past summer in Pods)!
I should add: