![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 15 years ago
Closed 14 years ago
#19437 closed enhancement (fixed)
Pass post type as a class to TinyMCE init
| Reported by: | markjaquith | Owned by: | azaozz |
|---|---|---|---|
| Priority: | normal | Milestone: | 3.4 |
| Component: | TinyMCE | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: |
Description
If we pass the post type as a class to TinyMCE, editor-styles.css can target rules to specific post types which may be displayed differently.
<?php wp_editor($post->post_content, 'content', array('dfw' => true, 'tabindex' => 1, 'tinymce' => array( 'body_class' => 'post-type-' . $post_type ) ) ); ?>
Attachments (1)
Change History (18)
#2
@
15 years ago
- Component General → Editor
- Milestone Awaiting Review → Future Release
- Type defect (bug) → enhancement
Been looking into something similar recently too. However to set anything into TinyMCE's iframe it has to go through JS (as it's 100% JS generated). So we need a JS "helper" function to modify classes (and IDs?) in the iframe document.
Seems the best way to do this would be to handle it from one of our custom TinyMCE plugins: we can pass extra classes as MCE init setting and then apply them from the plugin.
Also it seems we need to make editor-style.css more structured/predictable. There are styles/selectors that shouldn't go in there and all selectors should be exactly the same as in the theme's style.css.
#3
@
14 years ago
Just dropping a note while it's on my mind, this will become increasingly more important as plugins (like bbPress/BuddyPress) start including wp_editor() in places outside of the traditional post editor; within the theme, for example.
#4
@
14 years ago
It would also be useful to have a class added with the wp_editor() $editor_id to allow for unique styling of TinyMCE editors.
#6
@
14 years ago
- Component Editor → TinyMCE
- Keywords needs-patch removed
- Milestone Future Release → 3.4
3.4 as part of the editor enhancements.
#8
follow-up:
↓ 11
@
14 years ago
For security, do we need to esc_attr() the $body_class variable?
That's what we do at the end of the get_body_class() function (http://core.trac.wordpress.org/browser/trunk/wp-includes/post-template.php#L545).
#11
in reply to: ↑ 8
@
14 years ago
Replying to jamescollins:
For security, do we need to esc_attr() the $body_class variable?
Don't see a point in escaping the editor ID or the post_type strings.
That's what we do at the end of the get_body_class() function (http://core.trac.wordpress.org/browser/trunk/wp-includes/post-template.php#L545).
Right, seems that's not needed there either, the HTML class attribute allows all UTF-8 chars with very few exceptions.
#14
follow-up:
↓ 15
@
14 years ago
[20059] brings back #18457. 19437.child-editor-style.patch is an attempt to fix that.
#15
in reply to: ↑ 14
@
14 years ago
Replying to SergeyBiryukov:
Wouldn't that add the child theme's stylesheet before the parent theme's? At first look in the patch the parent theme loop is after the child theme loop:
Edit: nevermind, that's otherwise round.
+100. Ran into this earlier today.