Make WordPress Core

Opened 10 years ago

Closed 10 years ago

#27288 closed defect (bug) (invalid)

WP 3.9 Editor: 'mce_css' filter broken

Reported by: wpweaver's profile wpweaver Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.9
Component: Editor Keywords:
Focuses: Cc:

Description

Previously to 3.9, the 'mce_css' filter allowed using a .php file instead of a .css file to style the editor.

My theme, Weaver II, with tens of thousands of users, is broken in 3.9 because of this. I have been using a .php file to dynamically style the editor to match the theme options. This no longer works at all, while in the past substituting a .php file that dynamically generates the CSS in place of the editor-style.css file works perfectly.

I think this is a serious loss of function. Using a php file to dynamically generate CSS for the editor is an essential tool, and needs to be returned.

I will be happy to work with whoever is working on the Editor to demonstrate this problem. But to me and the tens of thousands of people using my theme, this is a huge deal-breaker.

Change History (14)

#1 @KirkM
10 years ago

This is a rather serious issue, especially for those who use Weaver II, Weaver II Pro and other premium themes that make use of the "mce_css" filter. Styling the editor is essential for proper post and page creation and editing especially for those who use Weaver II and other premium themes for business websites.

#2 @SergeyBiryukov
10 years ago

  • Milestone changed from Awaiting Review to 3.9

#3 follow-up: @SergeyBiryukov
10 years ago

Confirmed.

The filter itself still works as expected, editor-style.css from Weaver II gets added to the iframe. However, for some reason it's no longer applied to the editor content.

#4 in reply to: ↑ 3 ; follow-up: @wpweaver
10 years ago

Replying to SergeyBiryukov:

Confirmed.

The filter itself still works as expected, editor-style.css from Weaver II gets added to the iframe. However, for some reason it's no longer applied to the editor content.

That is not exactly what I reported...

The currently available Weaver II theme filter changes the editor-style.css to editor-style-css.php. It is the .php file that is not being processed. Just to be clear.

#5 in reply to: ↑ 4 @SergeyBiryukov
10 years ago

Replying to wpweaver:

The currently available Weaver II theme filter changes the editor-style.css to editor-style-css.php. It is the .php file that is not being processed. Just to be clear.

That's what I meant, just mentioned wrong file name, sorry.

I see editor-style-css.php in both the iframe <head> element and content_css item in tinyMCEPreInit:

http://trunk.wordpress/wp-content/themes/weaver-ii/editor-style-css.php?mce=1&fontsize=12
Last edited 10 years ago by SergeyBiryukov (previous) (diff)

#6 follow-up: @wpweaver
10 years ago

Problem solved - but sill a change in behavior.

The .php file MUST send

`header( 'Content-type: text/css' );'

first. Previously, that didn't matter.

Sorry for missing this on my own.

Version 0, edited 10 years ago by wpweaver (next)

#7 in reply to: ↑ 6 @nacin
10 years ago

Replying to wpweaver:

Problem solved - but sill a change in behavior.

The .php file MUST send

header( 'Content-type: text/css' );

first. Previously, that didn't matter.

Would be good to know whether that's caused by TinyMCE 4.0, or perhaps a Chrome update or something.

#8 @KirkM
10 years ago

Andrew & Sergey - Is there an earlier build of 3.9 that still incorporated TinyMCE 3.8.* available? If not much of the pre-3.9 core had changed between that and a build with TinyMCE 4.0 they could be perhaps used for comparison? Or am I way-off base here?

Last edited 10 years ago by KirkM (previous) (diff)

#9 follow-up: @jeremyfelt
10 years ago

@KirkM - [26876] is when TinyMCE 4.0.12 was first introduced to trunk. See #24067 for the incremental changes.

#10 @SergeyBiryukov
10 years ago

Confirmed that [26876] introduced the issue here.

Last edited 10 years ago by SergeyBiryukov (previous) (diff)

#11 in reply to: ↑ 9 @KirkM
10 years ago

Replying to jeremyfelt:

@KirkM - [26876] is when TinyMCE 4.0.12 was first introduced to trunk. See #24067 for the incremental changes.

I'm terribly rusty these days but the section between lines 787 and 812 of #24067 may have something to do with this. Of course, I could be completely wrong as well. The changes made to TinyMCE 4.0 are rather involved.

#12 @azaozz
10 years ago

Confirmed, caused by using a standards doctype. Example:

<!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="style.php" type="text/css" />
...

This stylesheet is not parsed in FF, WebKit and IE > 8 when it doesn't have the proper text/css content type header. Not just in TinyMCE but on any page (including in the admin). If the doctype is missing or is non-standard, the stylesheet is parsed.

TinyMCE 3.5.x used only <!DOCTYPE> but 4.0 uses the proper <!DOCTYPE html>. This can be changed but not sure what other things may break if we set the iframe document to quirks mode.

Considering that proper content type header is needed in nearly all cases when php file is loaded as stylesheet, thinking the current behavior in the editor is right.

#13 @nacin
10 years ago

Yeah, I can easily confirm that load-styles.php won't serve CSS to the admin without a text/css Content-Type header.

I can do a post on make/core explaining the change, but this otherwise seems like a wontfix. I imagine the proper doctype has other benefits.

#14 @nacin
10 years ago

  • Milestone 3.9 deleted
  • Resolution set to invalid
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.