Fix for #264, repeatable groups with a WYSIWYG editor, take 2#693
Fix for #264, repeatable groups with a WYSIWYG editor, take 2#693johnsonpaul1014 wants to merge 1 commit intoCMB2:trunkfrom
Conversation
|
👍 getting this in would be awesome |
|
Not ignoring, just busy. We'll be reviewing soon. |
|
Hmm, you don't actually ever enqueue the wysiwyg.js. Is there a reason for that? |
|
I see, you've concatenated it, but their is no solution if |
|
That's a good point. It probably makes more sense to enqueue it with the main script having a dependency on it, so a local wysiwyg variable could be used instead of window.wysiwyg. I was just trying to eliminate the extra server request. |
|
@johnsonpaul1014 Thanks a ton for getting the ball rolling. I've merged your branch in and used it as a (great) starting point. I had to re-think things to make it a bit more performant (there was no reason to destroy/reinit all instances when shifting rows), and fix a few bugs (removing a group high up in the stack resulted in a bad initiation when new rows were added). I also updated the script-loader to properly enqueue the file separately if |
|
This is now in trunk and will be in the next release. |
3 participants
This is a second attempt at a pull request to fix the repeatable WYSIWYG editor fields. It adds in a fix to make sure that editors aren't attempted to be destroyed before they actually exist. I have been using this in production for a bit now with no more issues. There may be a better way to integrate this with existing CMB code, but I was able to pull this out of some other logic I had to make WYSIWYG editors.