If you create a second text format that uses the TinyMCE editor, switching back and forth between those formats on the node edit page causes the textarea to disappear. Switching to a text format that does not use TinyMCE, or reloading the edit page, causes the textarea to reappear.
To reproduce:
- Start with a fresh install of Panopoly 7.x-1.0-rc3
- Create a basic page - make sure to save it in the WYSIWYG format
- Add a text format at admin/config/content/formats/add
- Assign the TinyMCE editor to it at admin/config/content/wysiwyg
- Edit the page you created earlier
- Switch the text format from WYSIWYG to the format you created
- Note the body field textarea disappears
- Switch the text format to one that does not use TinyMCE - for example HTML
- Note the textarea reappears
| Comment | File | Size | Author |
|---|---|---|---|
| wysiwyg-textarea.png | 85.81 KB | cboyden | |
| wysiwyg-textarea-1.png | 221.39 KB | cboyden |
Comments
Comment #1
populist commentedIf I had to guess, I think that having TWO formats that both have TinyMCE might be causing trouble. Why would you want to have two WYSIWYG filters? Do you see the same problem if you have two different WYSIWYG editors?
Comment #2
Lowkey commentedTo help solve this problem, perhaps you could open your javascript console (found in the developer tools in most browsers) and copy/paste the error message?
I had the problem on a former version of Panopoly, where the editor was not uninstantiated when the modal window was closed, creating an error when opened a new one, without refreshing the page.
Comment #3
populist commentedI am going to close this since having two TinyMCE versions might be a problem and not sure what Panopoly would be doing to cause trouble here.
Comment #4
defconjuan commentedPanopoly uses a wysiwyg settings hook (panopoly_wysiwyg_wysiwyg_editor_settings_alter inside panopoly_wysiwyg.module) to configure the editor and without these (specifically the PDW plugin settings) the wysiwyg initialization errors out.
The hook only applies these settings to text formats prefixed with 'panopoly_', so if you create a new format without that prefix, the wysiwyg editor will not load properly.
You'll notice that creating a new text format prefixed with 'panopoly_' works just fine. So updating the hook to be prefix agnostic (or just documenting that you have to prefix your text formats) would "resolve" this issue.
Comment #5
dsnopek@vtldevops: Thanks for tracking this down! It sounds this is a bug in panopoly_wysiwyg - that hook should be prefix agnostic or at least not break text formats that aren't prefixed with 'panopoly_'.
Comment #6
defconjuan commentedHappy to. Thanks to @cboyden for originally reporting this so I had somewhere to start.
Comment #8
dsnopekI've implemented a fix to this, which does the following:
panopoly_wysiwyg_alter_wysiwyg_editor_settings()which other distributions can use to apply the same customizations that Panopoly does to their text formats. For any "panopoly_*" text formats, we call this function so it works like before.hook_wysiwyg_editor_settings_alter()that will setup the PDW settings if they aren't already setup, for any text format (not just "panopoly_*" ones). This will prevent user created text formats from breaking!Thanks @cboyden and @vtldevops for your help!
Comment #9
defconjuan commentedHey, nice, thanks for the commit @dsnopek!