404 (Not Found) system.menus.css within CK Editor iframe

Same for me. Your advice works OK - thank you!

For clearance: line
stylesheets[all][] = system.menus.css
has to be romved from zen.info
and

stylesheets[all][] = system.menus.css
stylesheets[all][] = system.messages.css
stylesheets[all][] = system.theme.css

from subtheme info file.
Code for template.php

function subtheme_css_alter(&$css) {
  // Zen includes it' own versions
  if (isset($css['modules/system/system.menus.css'])) {
    unset($css['modules/system/system.menus.css']);
  }
  if (isset($css['modules/system/system.messages.css'])) {
    unset($css['modules/system/system.messages.css']);
  }
  if (isset($css['modules/system/system.theme.css'])) {
    unset($css['modules/system/system.theme.css']);
  }
} 

Here is small patch that fixes issue by removing link to non-existent css in zen.info

But you should have system.menus.css in you subtheme folder (at least empty file), otherwise default system.menus.css will be loaded and could break zen menu styling

Here is another patch, alternate to #3. It just adds missing empty system.menus.css file to zen theme.

From the description in the info files, this is simply just wrong. Defining new styles here does not remove the system css files.

i.e. Using hook_css_alter() is the way that this should be done.

/**
 * Implements hook_css_alter().
 *
 * Removes the system styles that Zen handles.
 */
function zen_css_alter(&$css) {
  // Zen incorrectly tries to remove these via the .info file.
  $excluded_css = array(
    'modules/system/system.menus.css',
    'modules/system/system.messages.css',
    'modules/system/system.theme.css',
  );
  foreach ($excluded_css as $css_file) {
    if (isset($css[$css_file])) {
      unset($css[$css_file]);
    }
  }
}

Then removing the 4 info lines too.

Just encountered this issue with wysiwyg module using ckeditor 4.4.6 standard library configured to use theme.css which is a zen subtheme.

When creating or editing content watchdog entries appear page not found for
system.menus.css
system.messages.css
system.theme.css

Since this only happens when ckeditor is loaded what is the best solution?

Can the solution in #6 be added to the template.php file?

Adding the solution in #6 to the subtheme template.php file and removing/commenting out the four lines, one in zen.info and three in subtheme.info file has resolved the page not found errors in watchdog.

This may need further review and possibly a patch.

Thank you, all.

From https://www.drupal.org/node/263967 :

stylesheets[all][] = system-menus.css

Adding the override for a style sheet that does not exist inside the theme will omit the core or module style sheet. This is by design [...]

Which means the bug is in those modules for assuming that the file has to exist in the theme. The documented, standard way to remove a module's stylesheet in a theme is by doing what Zen is doing now. I'm not going to switch to a non-standard way.

Please reference this issue in a new bug report for those modules. Thanks!

Cool trick, but it is not compatible with CK Editor which is what this issue is about.

Trivial to replicate, edit some content with WYSIWYG + Zen starter theme + CK Editor.

How about dropping this left field random Drupal wtf, and using hook_css_alter?

https://api.drupal.org/api/drupal/modules%21system%21system.api.php/func...

Code above and removing these lines from the starter kit.

; First we remove the system's menu and message styling since Zen has its own.
stylesheets[all][] = system.menus.css
stylesheets[all][] = system.messages.css
stylesheets[all][] = system.theme.css

And this from Zen itself

stylesheets[all][] = system.menus.css

Done.

[edit]
Drupal 7.43
WYSIWYG 7.x-2.2+54-dev
Zen 7.x-5.5

If I understand this is coming from the ckeditor js not from the wysiwyg module making it difficult to file the issue to a different module.

Also, I find the solution in this thread appealing as it simplifies zen sub-themes and it appears to be based on proper use of the api. It does not seem to cause any other problems, at least so far in testing.

It does raise a big backward compatibility issue :-(

Can we just hack Zen or implement the workaround? I will not reopen again if you choose not to do anything.

There is nothing wrong with Zen or WYSIWYG, but some deep wacky issue with core that will almost certainly never be fixed....

[edit]
I assumed you could use your own alters, but no such luck. Hacking appears to be the only solution.
[/edit]

This is the bug in WYSIWYG module. It doesn't check file existing before adding it to the list of files to load.

>.<

No fault in either module: Drupal screws this up, and it is likely that it would take many hours of mucking around in the quagmire to find the cause, only to see it needed to be forward ported to Drupal 8.x or maybe Drupal 9.x if it requires an API change, and hopefully, just maybe, see it get fixed in Drupal 7 while Drupal 7 is still supported. Or just a simple fix here...

$settings['contentsCss'] = wysiwyg_get_css();
...
  foreach (drupal_add_css() as $filepath => $info) {
    if ($info['group'] >= CSS_THEME && $info['type'] != 'inline' && $info['media'] != 'print') {
      $files[] = file_create_url($filepath);
    }
  }

System calls are darn expensive c/f code. I'm glad the WYSIWYG module doesn't check and assumes that other things will be right.

Cool trick, but it is not compatible with CK Editor…

Not a trick. It is the documented way for any theme to remove a stylesheet coming from a module. Just about every major contributed theme on drupal.org uses this method. https://www.drupal.org/node/263967

Drupal screws this up,

No it doesn't. Its just that Drupal 7's APIs aren't very clear in this area.

…forward ported to Drupal 8.x or maybe Drupal 9.x if it requires an API change

You're in luck. Drupal 8 fixes the API already. You can use stylesheet-remove in theme info.yml files.

This is the bug in WYSIWYG module. It doesn't check file existing before adding it to the list of files to load.

Agreed.

Thank you everyone for exploring and concluding this issue.
As John said awhile ago, it's the contrib module not the theme :-)
Now we have the fix :-):-):-)

It was a wysiwyg module issue.
I don't see the issue when using the ckeditor module.

K, the solution works, so this is a purely informational comment.

I was wrong above, the root cause is actually Zen not core, as per the API for drupal_get_css() states replace not remove. Zen does the latter, so the results from drupal_get_css() can no longer be assumed safe.

Themes may replace module-defined CSS files by adding a stylesheet with the same filename. For example, themes/bartik/system-menus.css would replace modules/system/system-menus.css. This allows themes to override complete CSS files, rather than specific selectors, when necessary.

Even the documentation reference above states to use hook_css_alter(). Hooks are slow, but system calls are much slower.