Amazing hack for fixing the code changing habits of the WordPress editor
Update March 23, 2008: The code that I originally wrote below based on Roland O’Connor’s post didn’t work. I subsequently found this WordPress Forum topic, which had the correct code to replace, and I’ve corrected the post below.
Also, I wrote a follow-up post to this one with more tips on using plugins and hacks for fixing this editor problem. So read this post, and then check out Plugins and hacks for improving the WordPress TinyMCE editor
Have you ever embedded code in your WordPress editor, only to find that saving the post causes the code to change and your whole blog’s layout to break?
Have you ever tried to use divs in your WordPress editor, only to find that all your div tags have been replaced with p tags?
Well, despair no further! Roland O’Connor has written about an easy solution that fixes this problem.
Here’s what you do:
- Find the file wp-includes/js/tinymce/tiny_mce_config.php.
- Find the line
$valid_elements='p/-div[*],-strong/-b[*],-em/-i[*],-font[*],-ul[*],-ol[*],
-li[*],*[*]'; - Change it to
$valid_elements ='-strong/-b[*],-em/-i[*],-font[*],-ul[*],-ol[*],-li[*],*[*]';
$valid_elements = '#p[*],-div[*],-strong/-b[*],-em/-i[*],-font[*],-ul[*],-ol[*],
-li[*],*[*]';
Make sure all the code is on one line. That’s it!
The only problem with this hack is that you have to remember to redo it every time you upgrade your WordPress blog. Unless of course someone feels like making this into a plugin…hint hint, wink wink, nudge nudge.
Category: Tips
Great Hint. This is one of the most frustrating things I’ve found in WordPress. Good to know there is an easy fix out there.
Here’s everything you would need for a plugin. Just add a header and you’re good to go:
function fix_tinymce_divs($allowed = '') {return '-strong/-b[*],-em/-i[*],-font[*],-ul[*],-ol[*],-li[*],*[*]';}add_filter('mce_valid_elements', 'fix_tinymce_divs');It breaks the TinyMCE…check Rowland’s comments
I tried to change too. But not luck for <object> <embed> tags
that’s TinyMCE, used in WordPress, is really suck for XHMTL validation.
Somebody from WordPress development should take responsible for that.
@filosofo – that is really nice of you to provide the code needed for a plugin. Would you mind if I put one together based on that?
@mudbrrk and Myo Kyaw Htun – you were right about the code not working. It turns out that the guy who posted about this didn’t quite get it right, but I found different code and tested it out, and it worked on my blog! So come back and check out this post to see the correct code.
Here’s an interesting forum topic related to this issue: http://wordpress.org/support/topic/101906?replies=32
It seems very odd that this fundamental feature is missing from the core of WordPress.
I prefer the bbCode method used by most forum software to this weird WordPress markdown mumbo jumbo, at least I know how my code will display after I hit post then rather than it being a gamble as it is now.
And the ability to add pure HTML would be handy too. Although that would have to be limited to admins to prevent hacking attacks.
An interesting aside … I gave some members of my forum access to an [html] bbCode tag recently. This allowed them to use any HTML code they wanted. I knew this could lead to the site design being destroyed if they felt like it, simply by messing with the CSS (body {display:none) would have some interesting effects!), but I didn’t expect there to be any major security issues with this.
However, one of those who I gave access to this tag, told me he could hack in and start using the admin panel if he wanted to. I thought he was talking a load of baloney so dared him to try, withing 90 mins he hacked through and started posting messages under my username! He also reckoned he could make his way right through to my raw database files if he wanted – I didn’t dare him to try that.
Anyhows, my point here is that although it seems odd that WordPress doesn’t allow pure HTML, there is a very good reason for it. Apparently a little Javascript in a forum post/blog post can cause some serious security issues.
[...] at WordPress Garage explains how to make the WordPress editor stop changing your code. It has never really bothered me, but I see a lot of people complaining about the code formatting [...]
[...] viu que ele substituiu todos por &lt;p&gt; ?Não se desespere. De acordo com o blog wpgarage, a solução para esse problema é simples, desde que você tenha uma noção de ftp e edição de [...]
guys, thanks for the hack..
but i find them not working in wp 2.5+.
just check it out, there’s no such thing as “
$valid_elements"..This is what it says in the config file:
// Setting “valid_elements”, “invalid_elements” and “extended_valid_elements” can be done through “tiny_mce_before_init”.
// Best is to use the default cleanup by not specifying valid_elements, as TinyMCE contains full set of XHTML 1.0.
Hi,
Thanks for such a great tip, this is exactly what I searching for to fix wordpress editor problem.
Thanks again.
[...] few days ago I wrote about a way to make the WordPress TinyMCE text editor stop stripping div tags. The original code that I wrote didn’t work, but I subsequently found a solution that I [...]
This hack no longer works in wordpress 2.7.1.
Does anyone have a work around for that version?
@alan – AFAIK this hack no longer works because it is no longer needed. I don’t think DIV tags are converted to P tags in WordPress anymore.
No, we still need a solution. WP 2.7.1 is STILL chewing up even basic HTML code and throwing it away. I will insert some IMG and <a> tags and it will come back 3 saves later and throw them all away. Any solutions anyone?
Yup – things like iframes and a <div style=”clear:both;”></div> that let’s me reatart text properly under pictures are
still being stripped out – absolutely maddening – there MUST be a solution out there somewhere!
I have a solution to this problem. It took me all day to figure it out, and it is very hacky. I’m so pissed at WP for not having features to turn OFF their ‘autop’ function and allow html editing to be true html editing. Even if just for admin-status users, it would have saved ALL of us a bunch of time.
My solution is to use shortcodes. They are not stripped out, and they can be used to insert div tags after the stripping has taken place. Here is my code…
// The [clear_both] shortcode
function shortcode_clear_both() {
return ‘<div style=”clear:both”></div>’;
}
add_shortcode( ‘clear_both’, ‘shortcode_clear_both’ );
// The [div] shortcode
function shortcode_div( $atts, $content=null ) {
extract(shortcode_atts(array(
‘class’ => ”,
‘style’ => ”,
‘id’ => ”,
), $atts));
$ret = ‘<div’;
if (!empty($style)) $ret .= ‘ style=”‘.$style . ‘” ‘;
if (!empty($class)) $ret .= ‘ class=”‘.$class . ‘” ‘;
if (!empty($id)) $ret .= ‘ id=”‘.$id . ‘” ‘;
$ret .= ‘>’;
$ret .= $content . ‘</div>’;
return $ret;
}
add_shortcode( ‘div’, ‘shortcode_div’ );
Hope this helps someone out there.
I forget to mention that to use the shortcodes, they must be on a line by themselves. For example…
….. your markup and text here….
[clear_both]
…. More text here.
The thing to notice is the blank lines around the short code. This must also be done with the [div] shortcode. Without these blank links, you will get spurious <br /> tags. Its weird. I guess the multiple blank lines create multiple sequential <br /> tags, which then get stripped out all at once. I tell you if I wasn’t so vested in WP I’d find something else. Their overprotective practices are just screwy.
[...] Rinaldi hat nun vor ein paar Tagen bei WPGarage in einem Kommentar eine Lösung präsentiert, die ich genial finde – einfach weil sie für meine Zwecke ohne [...]
Thanks Ron!
The clear_both shortcode worked. I simply added a height to the style, so all I use is the [clear_both] with no DIVs. I also had to edit your apostrophes otherwise my site went blank.