1

We are having an issue where WYGWAM fields are disappearing on initialization of the js in the Edit Entry screen in the control panel. This is only for IE8 and IE9; other browsers work fine. This behavior is consistent whether we let the fields initialize on load or if we initialize on focus (in which case, the field's content loads and is visible, but disappears on click).

The channel contains a series of Matrix fields, including WYGWAM, Assets, and Playa fields. We are running an install of EE2.5.5, Matrix 2.5.3, Playa 4.3.3, and Assets 2.0.5.

In the browser console, we are seeing the following two errors:

  • Not enough storage to complete this operation. ckeditor.js, Line 13
  • Object doesn't support this property or method. compressed.js; Code: 0; Line 39.

Note, turning off nsm_morphine_theme where the compressed.js code resides eliminates the second js error, but does not resolve the issue above.

Here is a screen shot per Lisa Wess' request below. It is the Text field which has the Wygwam field type; the other empty fields simply do not have data entered in them.

Missing Wygwam

------------------------------- UPDATE -------------------------------

There are two issues, both of which appear to be related to upgrading to Assets 2.

First, on upgrading we have the same issue as this: Clicking on folders in the Assets 2 file manager does not work on IE8.

Applying the hack Kevin Lees suggests takes care of the issue where the Assets 2 dialog box will not allow the user to select items from the popup.

The second, original issue -- that the Wygwam fields are not instantiating -- appears to be related to the control panel page making over 31 CSS calls; IE8/9 have a hard limit of 31 CSS calls, ignoring any calls above that number.

I believe this behavior is related to a change in Assets 2, which introduced a number of small, separate style calls in the head. No bid deal, except IE8/9 is counting each against the total. Therefore a page with multiple matrix and assets fields pushes past the 31-call limit.

Short of downgrading to Assets 1, the only fix we've found is to force the user to use Compatibility mode, which doesn't impose the 31-call limit.

I would be curious to hear if anyone else is having this problem or has found a better, long-term solution.

Improve this question
12
  • Shanan, have you tried with compatibility mode on? Also, any chance you could post a screenshot of the publish page in IE?
    – Lisa
    Mar 27, 2013 at 0:01
  • Yes, the field is visible with compatibility mode on.
    – Shanan Galligan
    Mar 27, 2013 at 12:05
  • Update, we have a reported case now where compatibility mode does not resolve the issue in IE9 (running on Windows 8). The plot thickens.
    – Shanan Galligan
    Mar 27, 2013 at 16:27
  • Shanan - so compatability mode fixes it in IE 8 on Windows 7? But not in IE 9 on Windows 8? I have Windows 7 here so I can do some testing on that, but I do not yet have Windows 8. Are there any other third-party add-ons on that publish page? YOu showed a very limited selection. What about if you have a channel with a field with just wygwam in the publish field - does that reduced case error?
    – Lisa
    Mar 27, 2013 at 16:56
  • Updates! Ignore the IE9/Windows 8 report -- we had a miscommunication on our side. This behavior is only confirmed to occur in IE8 and IE9 with compatibility mode OFF (turning compatibility mode on makes everything hunky dory). I am now creating channels with reduced fields.
    – Shanan Galligan
    Mar 27, 2013 at 20:36

2 Answers 2

Reset to default
1

P&T has some related fixes coming in future updates which may well solve these issues. Our final fix was to simply replace the Assets field type with the native file manager and Wygwam with EE's Rich Text field type. Bare bones, but now functioning correctly in IE8/9.

Improve this answer
3
  • 1
    Just to add to this, a large part of the problem is that IE has a 31 CSS call limit. The combination of add-ons on Shanan's install exceeded that. Removing some items from that publish page to bring the number of calls down was important to get this working.
    – Lisa
    Apr 3, 2013 at 20:04
  • Agreed -- I earlier updated the original question above to try to stress that the 31-call limit was at the center of the problem. I could edit it again to make it more clear? That said, it's also worth noting that the channel had worked with earlier versions of the same P&T plugins, but pushed over our hard limit when we updated to the current versions. It's something we'll need to keep in mind for clients relegated to legacy browsers.
    – Shanan Galligan
    Apr 4, 2013 at 10:33
  • Nah, it was pretty clear, but in case people skipped down to the answer, I wanted to make sure it was clear here as well. :) Thank you Shanan!
    – Lisa
    Apr 4, 2013 at 16:35
0

Sounds like our client is having a similar issue with IE9 and Windows 7. The WYGWAM field disappears when initialising.

I used browserstack to try it and it does disappear. I tried compatibly mode too but it didn't fix it. If you delay initialisation you can see the content but as soon as you click in the WYGWAM filed it goes.

Are there any other work arounds?

Improve this answer
1
  • What other -- and how many -- field types are you using in the channel? Also, is this a new install or did the behavior start after updating modules (this was our case -- we updated our plugins, and the new plugins pushed us over the 31 CSS call limit).
    – Shanan Galligan
    Apr 4, 2013 at 10:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.