There's a new release of the WYSIWYG module as of the end of 2016. Several of the issues that panopoly_wysiwyg has patches for have been marked fixed. Other patches used in panopoly_wysiwyg might need to be re-rolled. There are a lot of changes, so this would require some intensive testing.
| Comment | File | Size | Author |
|---|---|---|---|
| #25 | panopoly_wysiwyg-wysiwyg-v24-2865140-v25.patch | 6.82 KB | dsnopek |
| #14 | panopoly_test-wysiwyg-v24-2865140-14.patch | 4.84 KB | cboyden |
| #12 | panopoly_magic-wysiwyg-v24-2865140-12.patch | 2.86 KB | dsnopek |
Comments
Comment #2
dsnopekHere's a patch for testing!
EDIT: And here's a Travis build: https://travis-ci.org/panopoly/panopoly/builds/232592113
Comment #3
dsnopekNeed to update the Feature exports! Here's a new patch
EDIT: Here's a new Travis build: https://travis-ci.org/panopoly/panopoly/builds/232890694
Comment #4
dsnopekHere's a new Travis build after some attempts to fix the tests:
https://travis-ci.org/panopoly/panopoly/builds/235004108
Comment #5
dsnopekAh, this fails tests because it breaks live preview when editing the WYSIWYG (#2880513: Live preview not updating when typing in WYSIWYG was from left over copy of the newer WYSIWYG in my dev environment).
Comment #6
dsnopekHere's the start of a patch for panopoly_magic -- it works for MarkItUp, but not TinyMCE, so it still needs work.
Comment #7
dsnopekHere's a new patch that completely changes the way we are injecting the additional configuration for tinymce and markitup, which is working for me for both!
EDIT: Here's a Travis build for these patches: https://travis-ci.org/panopoly/panopoly/builds/235488740
Comment #8
cboyden commentedThe live preview test is failing because there's something going wrong when switching to the HTML editor. The toolbar isn't loading and typing in the field isn't working. I'm getting the following error in my console locally:
ReferenceError: config is not definedThis is triggered on line 101 of panopoly_magic.js, in this code block:
This might just be a typo, shouldn't it be
context[funcName]? Updated patch and interdiff attached. This is working locally, but there may be some timing issues with the live preview.Comment #9
dsnopekAh, actually, it should be 'settings'. I didn't update this in the last refactor. Strangely, it seems like this might not even be necessary? I'll do some more testing later.
Comment #10
dsnopekComment #11
dsnopekI did some more testing. It looks like our markitup integration code is just not working. Like, it registers an
onEnterhandler to catch the ENTER key, and the event does get called, but it doesn't actually trigger the preview. That said, it doesn't seem like the markitup integration is totally necessary -- it mostly just works with the plain textarea support!Maybe we should just remove that code? Here's a patch with it commented out, that I'm going to run through the tests.
EDIT: Here's a Travis build: https://travis-ci.org/panopoly/panopoly/builds/236160892
Comment #12
dsnopekAh, I named the last patch like it was for panopoly_wysiwyg rather than panopoly_magic so the tests failed. :-( Here's the same patch renamed.
EDIT: Here's the Travis build: https://travis-ci.org/panopoly/panopoly/builds/236389169
Comment #13
dsnopekTest are failing that they can't click the "Add media" button. :-/ Might need to update the way we click buttons in the tests?
Comment #14
cboyden commentedThe failures are due to two problems:
I don't know how to fix the first problem, but I've attached a patch for panopoly_test for the 2nd problem.
Comment #15
dsnopekIt looks like some of the plugins' names have changed, specifically:
I think this is about special naming for plugins that used the Drupal-generic way of implementing a WYSIWYG plugin, and it appears to be due to supporting TinyMCE 3 and TinyMCE 4 with the same configuration per #1968318: Support for TinyMCE 4.x
In any case, the attached patch appears to fix it! I'll try the tests again in a moment
EDIT: Here's a Travis build: https://travis-ci.org/panopoly/panopoly/builds/237586805
Comment #16
cboyden commentedLocal testing looks good so far, tests are passing and functionality works as expected. We'll be doing more testing later on.
Comment #17
cboyden commentedLinking some related issues that we discovered in testing:
Comment #18
dsnopekAdded latest patch from #2884691: "Use theme CSS" gives incorrect CSS when '#groups' array doesn't line up with child elements and #2884761: Stylesheet links with query parameters break when added to WYSIWYG frame. I suspect this won't be the last patches added!
EDIT: Here's a new build on Travis: https://travis-ci.org/panopoly/panopoly/builds/241219937
Comment #19
cboyden commented@dsnopek does there need to be an update hook to handle the changed setting names? block_formats has become theme_advanced_blockformats, among other things.
Comment #20
cboyden commentedAlso, there are a lot of settings in the feature that no longer seem to apply to the HTML editor. When I look at admin/config/content/wysiwyg/profile/panopoly_html_text on an updated site, there are no sections for CSS or Cleanup and Output. Of course, these sections make less sense for the HTML editor. CSS only matters if you are using a WYSIWYG, and the HTML editor displays code. There are some options in the Cleanup section that make sense for a code editor, and some that don't.
Comment #21
cboyden commentedI tried deleting the WYSIWYG profile for markitup and recreating it from scratch to match the previous one, using only the settings that are available in the new UI. I've attached an updated patch and interdiff with the results.
Comment #22
dsnopekThanks! Here's a test build on Travis:
https://travis-ci.org/panopoly/panopoly/builds/242459393
Comment #23
cboyden commentedAfter upgrading from latest dev to dev + this patch, panopoly_wysiwyg is overridden:
Comment #24
dsnopekComment #25
dsnopekI tried the upgrade process and it turns out that the clean-up to the HTML profile in #21 is the cause! We need to pair those changes to the Features export with the same changes in a
hook_update_N(). Here's a patch that does that!And it also removes the 'css_theme' change which appears to not be needed either? It feels weird to hardcode the Panopoly default theme, anyway. But if I was wrong about that one, we could always have the
hook_update_N()set it?EDIT: Here's a Travis build with this new patch: https://travis-ci.org/panopoly/panopoly/builds/242556500
Comment #26
cboyden commentedThis combination of patches is working as expected.
Comment #28
dsnopekThanks! Committed :-)