wysiwyg_get_css does not retrieve Drupal theme (default or admin) [#2842179]

Since upgrading from WYSIWYG 7.x-2.2 to 7.x-2.3, the Drupal theme (default or system) is not applied to content in the editor iFrame (I am using CKEditor, but the cause does not appear to be editor-specific).

While tracing through a request to a Drupal theme, e.g., Bartik at https://localhost/wysiwyg_theme/bartik , I only see the 200 (OK) response and no CSS file(s). The expression on line 759 evaluates to FALSE, as no CSS data was attached to the response.

(lines 755 - 762)

if ($update_cache) {
    $url = url('wysiwyg_theme/' . $theme, array('absolute' => TRUE, 'max_redirects' => 0));
    $response = drupal_http_request($url);;
    $cached = cache_get('wysiwyg_css');
    if ($cached && !empty($cached->data[$theme])) {
      $css = $cached->data[$theme]['files'];
    }
  }

I observe the same behaviour while using the default site theme (not Bartik).

If I revert to the previous version of wysiwyg_get_css while retaining all other modifications in the 7.x-2.3 release, the theme files are loaded.

Please advise on what needs to be done to get the latest version of wysiwyg_get_css in a working state on my site.

Comments

Comment #1

9 January 2017 at 18:02

mmikitka created an issue. See original summary.

Comment #2

TwoD

Swedish

Sweden

CreditAttribution: TwoD as a volunteer commented 9 January 2017 at 20:33

Category:

Bug report

» Support request

That page is not meant to return the list of files in the response, just a status telling Wysiwyg if the current user has access to the requested theme.

Which settings are you using on the CSS tab for 'Editor CSS' and 'Theme' on the editor profile?
Have you inspected the editor's iframe to see what's in that document's head? You may not see a specific request for the theme's individual stylesheets anymore as the new method allows for loading aggregated files, so the browser may save a request and re-use the same same aggregated file loaded for the main document inside the iframe.

The process works by Wysiwyg first checking if the list of stylesheets was cached, and if so just returns the list.
If no files were cached, it makes an internal HTTP request to that page callback, which forces a certain theme to be active if the current user is allowed to use it, else it defaults to activating the default frontend theme. The requested page is never meant to be accessed directly. All it really does is to let the active theme build up a list of stylesheets to load while rendering an otherwise empty page. Wysiwyg uses a pre-render callback on the "styles" element to grab the complete list of stylesheets just before they would normally be output to the document header. Wysiwyg then invokes a hook which lets you filter that list.
If a Aggregation is enabled, the remaining entries in the list are (possibly) aggregated using the same rules core normally applies.
The final list is then stored in the cache, keyed by the active theme name. Once the internal HTTP request is done Wysiwyg checks the Status code and whether there's anything cached by the requested theme's name and returns that (or the default list of stylesheets).

If you're getting a 200 OK there should either be a list of stylesheets in the cache or the theme didn't actually load any. It's possible something interrupted the process and you ended up with an empty cache entry for that theme. If so, simply clearing the cache should fix it.

Comment #3

dandaman CreditAttribution: dandaman commented 26 January 2017 at 22:55

On one of our servers, this request to http://www.domain.com/wysiwyg_theme/theme_name is timing out. This means that it takes over 60 seconds for this check of some sort to run. Which is making every page with a WYSIWYG on it load extra slowly. I think it's a networking issue that I'll get the server admins to fix because the server can't seem to find out where www.domain.com is or something.

Comment #4

TwoD

Swedish

Sweden

CreditAttribution: TwoD as a volunteer commented 27 January 2017 at 07:45

As I described above, that URL renders an empty page, well, it doesn't even actually render any markup, so I'm not sure how it could time out on its own. But yes, if the machine can't reach itself that could certainly be an issue.

Would be very interesting to see what you can find out about that. Maybe DNS? Containers?

One way to work around this would be to place the styles you need from your theme in a separate file and reference it from the editor profile instead. Then you could also make compensations for wrapper markup differences inside the editor vs where most of your content is normally rendered. It's an extra subset of the theme to maintain though.

Comment #5

dandaman CreditAttribution: dandaman commented 27 January 2017 at 16:02

Yeah, it seems the way the hosting company was routing things, the server did a DNS lookup but when it tried to send a request to that IP, it somehow timed out due to some sort of firewall or routing issue. I updated the server's host files to include their internal network's IP for requests to the site's domain and then it no longer took 60 seconds to do this and got the expected result. Also, when it was having this issue, the issue was noted in Drupal core's "Status Report" page that HTTP requests may not be working right, and updating the hosts file fixed that as well. (I guess Drupal core does a request to itself to check routing issues such as this, but the message was more like, "We're not sure if your server can route to the Internet" and it could check for Drupal updates, so I thought it was some sort of false positive, but now it's clear it was requesting to itself that was not working.)

Comment #6

mmikitka CreditAttribution: mmikitka commented 3 May 2017 at 15:32

I identified the cause: I have two Drupal instances running the same site behind a reverse proxy with only the HTTP endpoint enabled on the web servers (there is a direct connection from the F5 LB to the web servers; HTTPS requests are sent from the F5 LB to the web servers via HTTP). Since all content editing must go through HTTPS and I don't have an outbound route to the HTTPS endpoint from the web servers, the background request to /wysiwyg/THEME fails, and the 'wysiwyg_css' cache variable is empty.

For the time being, I will use hook_wysiwyg_editor_settings_alter to auto-inject the CSS style(s) into $settings['contentsCss'] (I'm using CKeditor).

@TwoD, thanks for your help