Comments

cboyden created an issue. See original summary.

dsnopek’s picture

Title: Update WYSIWYG to 2.3 » Update WYSIWYG to 2.4
Status: Active » Needs review
StatusFileSize
new887 bytes

Here's a patch for testing!

EDIT: And here's a Travis build: https://travis-ci.org/panopoly/panopoly/builds/232592113

dsnopek’s picture

StatusFileSize
new3.41 KB

Need 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

dsnopek’s picture

Here's a new Travis build after some attempts to fix the tests:

https://travis-ci.org/panopoly/panopoly/builds/235004108

dsnopek’s picture

Status: Needs review » Needs work

Ah, 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).

dsnopek’s picture

StatusFileSize
new1.02 KB

Here's the start of a patch for panopoly_magic -- it works for MarkItUp, but not TinyMCE, so it still needs work.

dsnopek’s picture

Status: Needs work » Needs review
StatusFileSize
new2.86 KB

Here'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

cboyden’s picture

StatusFileSize
new2.86 KB
new453 bytes

The 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 defined

This is triggered on line 101 of panopoly_magic.js, in this code block:

  // A function to run before Drupal.wysiwyg.editor.attach.markitup() with the
  // same arguments.
  function wysiwygMarkitupBeforeAttach(context, params, settings) {
    var onWysiwygChange = onWysiwygChangeFactory(params.field);
    $.each(['afterInsert', 'onEnter'], function (index, funcName) {
      config[funcName] = onWysiwygChange;
    });
  }

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.

dsnopek’s picture

Ah, 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.

dsnopek’s picture

dsnopek’s picture

StatusFileSize
new2.86 KB
new1.1 KB

I did some more testing. It looks like our markitup integration code is just not working. Like, it registers an onEnter handler 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

dsnopek’s picture

StatusFileSize
new2.86 KB

Ah, 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

dsnopek’s picture

Status: Needs review » Needs work

Test are failing that they can't click the "Add media" button. :-/ Might need to update the way we click buttons in the tests?

cboyden’s picture

StatusFileSize
new4.84 KB

The failures are due to two problems:

  • The wysiwyg alter hooks in panopoly_wysiwyg.module are not being invoked. So the default button order is not set. The Media button is hidden in the third row of buttons and is not clickable during the test.
  • The alt text of the button has changed from "Add media" to "Media browser."

I don't know how to fix the first problem, but I've attached a patch for panopoly_test for the 2nd problem.

dsnopek’s picture

Status: Needs work » Needs review
StatusFileSize
new4.93 KB
new1.53 KB

It looks like some of the plugins' names have changed, specifically:

  • media -> drupal_media
  • break -> drupal_break

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

cboyden’s picture

Local testing looks good so far, tests are passing and functionality works as expected. We'll be doing more testing later on.

dsnopek’s picture

cboyden’s picture

@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.

cboyden’s picture

Status: Needs review » Needs work

Also, 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.

cboyden’s picture

Status: Needs work » Needs review
StatusFileSize
new5.74 KB
new1.44 KB

I 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.

dsnopek’s picture

Thanks! Here's a test build on Travis:

https://travis-ci.org/panopoly/panopoly/builds/242459393

cboyden’s picture

Status: Needs review » Needs work

After upgrading from latest dev to dev + this patch, panopoly_wysiwyg is overridden:

$ drush fd panopoly_wysiwyg
Legend:
< Code:       drush features-revert will remove the overrides.
> Overrides:  drush features-update will update the exported feature with the displayed overrides

Component type: wysiwyg
      ),
      'settings' => array(
>       'block_formats' => 'h1,h2,h3,h4,h5,h6',
        'buttons' => array(
          'default' => array(
          ),
        ),
>       'convert_fonts_to_spans' => 1,
        'css_setting' => 'theme',
<       'css_theme' => 'responsive_bartik',
        'language' => 'en',
>       'paste_auto_cleanup_on_paste' => 1,
>       'path_loc' => 'bottom',
>       'remove_linebreaks' => 1,
>       'resizing' => 1,
>       'theme' => 'advanced',
>       'toolbar_align' => 'left',
>       'toolbar_loc' => 'top',
>       'verify_html' => 1,
      ),
    ),
dsnopek’s picture

dsnopek’s picture

Status: Needs work » Needs review
StatusFileSize
new6.82 KB
new1.59 KB

I 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

cboyden’s picture

Status: Needs review » Reviewed & tested by the community

This combination of patches is working as expected.

  • dsnopek committed f1b7685 on 7.x-1.x
    Update Panopoly WYSIWYG, Magic and Test for Issue #2865140 by dsnopek,...
dsnopek’s picture

Status: Reviewed & tested by the community » Fixed

Thanks! Committed :-)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.