WordPress - Taming The Advanced Editor
June 21st, 2007 by Stephen Cronin (5,492 views)Adding simple HTML code to a post should be easy, but it can lead to major frustrations. Why? Because the Advanced Editor cleans your code for you. Unfortunately, it often changes your code so that it no longer works!
While I understand arguments for cleaning the code (errors in your HTML could break the Theme), I believe that if you want to add code, then you should be allowed to do so without it being changed.
I use HTML to create rounded text boxes within my posts. Unfortunately, my code fell foul of the Advanced Editor’s cleaning process. Below I summarise some of the solutions I discovered to this problem:
Turning Off The Advanced Editor
There is a simple solution: turn off the Advanced Editor. This should solve all the problems. I know that quite a few users have done this and it may be worth considering if you often add HTML. However, for many users this is not an ideal solution as they want to use the Advanced Editor.
Using An External Text Editor
If you only add HTML occasionally, leave the Advanced Editor on and use it for posts without HTML. Write posts with HTML using an external text editor, then copy the content into WordPress.
WordPress ‘cleans’ your code when the Advanced Editor opens your post. Errors don’t occur the first time HTML is entered and saved, they occur on subsequent saves (the Advanced Editor re-opens the post after the save).
This means you should not have any problem if you:
- create the post content in an external text editor
- create a new post in WordPress (or edit an existing one)
- go to the Code Tab page
- paste the post contents from the external file
- save or publish the post
The code will break the next time you edit the post (immediately if you Save and continue), but there will be no problem unless you save again. If you need to edit the post, do so in the text file, then repeat the above.
Turning the Advance Editor Cleanup Off
If you often enter your own HTML, but still want to use the Advanced Editor, then you might want to consider turning it’s cleanup option off. I stumbled upon how to do this on Thu Tu’s Smacking Wordpress Editor.
To summarize how to turn off the advance editor cleanup:
Download the wp-includes/js/tinymce/tiny_mce.js file using an FTP program and use a text editor to change the following (near line 167) from:
this._def("cleanup", true);
to
this._def("cleanup", false);
Save the file, then ftp it back up to the server, overwriting the original.
Stopping New Lines Before <div>
For me, turning the advance editor cleanup off solved most of my problems. Only one problem remained: WordPress automatically puts a new line before a <div>. In the case of my rounded text boxes, this means that there is a blank line before the first line of text.
Of course this only happens on subsequent saves, not the first one and can be easily solved by manually deleting the new line. However it is annoying to have to do this everytime you edit the post.
I found the following ways to stop this happening, but none of them are really a viable solution for me, because of other problems they introduce:
It is possible turn off the automatic <br />, by Disabling WordPress’ slap-happy approach to <br /> tags. However, this also turns off the automatic <br /> in places where I actually want them.
Urban Giraffe has a plugin by John Godley to disable the WordPress wpautop function, which formats your posts. However, I found that it stripped the blank lines between paragraphs, even if I manually added <p> or <br /> tags. John’s post mentions this problem and gives a link to a WordPress Support page, but the suggestions there didn’t work for me. I only tried this quickly and didn’t persist, so it may be worth you trying.
In both cases, the solutions cause more work than just deleting the new line that WordPress adds before <div>, so I’ve settled for that.
Alternative To Turning The Cleanup Off
Turning off the Advance Editor cleanup, turns off all the cleanup. If all you need is the ability to use <div> without it being turned into <p>, there is a gentler option, outlined in a comment on this WordPress Support page.
To summarise, you need to:
- remove
p/-div[*]from line66 of\wp-includes\formatting.php - remove line 25 from
\wp-includes\js\tinymce\tiny_mce_config.php
See the support page for more details on these changes.
This works well, but I’d rather have the cleanup totally off.
Conclusion
So, which of the above methods do I use? Well truthfully, I’m not sure yet. Maybe all of them!
I started by writing my posts in an text editor and I like this for another reason as well: I can create my posts offline. I do have an offline copy of WordPress running on my USB drive, but it’s easier to just open a text editor. Yes, I’m lazy! But I often write for a few minutes in between other things and a text editor is quicker.
I am very tempted to turn the Advanced Editor off, because I add my own HTML to most posts. I don’t really use the Advanced Editor features and I’m comfortable with HTML. However I am persisting with it for the moment - but I have turned off the Advanced Editor Cleanup to make life easier.
So what do you do? I’m interested in hearing of any other methods you know of.
Tags: advanced editor, wordpress
Loading ...
Hi
Looks good! Very useful, good stuff. Good resources here. Thanks much!
Bye
[…] of web development PHP, MySQL, CSS, Javascript, Ajax, and WordPress. Stephen’s post Taming The Advanced Editor has already been helpful and I’m actively using this valuable […]
[…] articles which will definitely have an audience. I did read a couple of articles, and in particular WordPress - Taming The Advanced Editor. Most of the content is readable and if you like WordPress and customizing WordPress, you will […]
I wish I’d found this post yesterday! I had a very frustrating time last night trying to put some code in a post. I figured out eventually what the problem was and used a text editor but this could have saved me a lot of swearing and frustration. I’m going to post a link to this article on my site in the hope that others will be spared some of that frustration!
[…] More Than Scratch The Surface » Blog Archive » WordPress - Taming The Advanced Editor You might also be interested in: How To:Find Creative Commons ImagesSabayon Linux x86/x86-64 3.4: Stable ReleaseMy Top 10 WordPress PluginsHow to: Protect CSS Mods for ANY WordPress Theme Printer Friendly Page var addthis_pub = ‘OOB4LCS8QWG12ZRW’; Leave a Comment […]
I have always turned off the advanced editor, it surprising how much html you can pick up when you have to use it to make posts, good article!
Janet, once again thanks for your comment and your write up. I like your site and will check it out further! As for adding HTML to posts, I like WordPress a lot, but this was a major frustration for me. It’s a pity you didn’t see this first!
Andy, actually I have now turned of the advanced editor too. I’m comfortable with HTML, so I like it a lot. I don’t miss the advanced editor stuff. I’ve edited my quicktags.js to add other things I use a lot (like H2, H3) so I can quickly add the HTML tags, which makes it easier.
I can’t understand why the developers don’t simply put an option in the admin panel to turn off html cleanup. Having to monkey around with code to do something so simple is a real pain, and is much more likely to cause stuff to break than invalid HTML.
Malik, I agree. The decision should be in the hands of the users, not enforced on them.
Hi Stephen … thanks for this.
I got so POd with TinyMCE that I’ve decided to wrestle this down to the mat.
see my scratch list of editor-related material at codex wiki
cheers
–bentrem
Hi Ben,
Thanks for adding this post to the list! I’m going to have to check out some of the other links. Anyone reading this would do well to check out your list (link in Ben’s comment).
It’s worth noting that these days, I’ve got the Advanced Editor turned off. This still causes me problems occasionally with <p> tags being added in places where it breaks XHTML Transitional validation.
Hey Stephen - Your “<p>added in places that break validation” is the wicked under-belly of this whole thing. What’s awefully apparent is how lotsa folk are getting into wrestling matches with something that should be, well, like falling off a log. (I added a couple of heh pithy quotes to my codex wiki page, one of them being from your blog.)
Do you happen to know Flux CMS? Those folk take XHTML validation seriously; I’m sure their editor produces valid code. But at the moment I think it’s too primitive for deployment with WP.
Anyhow, there’s a bit of a groundswell about this. Whatever comes from it is bound to be A Good Thing for a lotta people.
Hi Ben, sorry you got caught in the spam queue (too many links).
I’m a bit behind posts at the moment, but sometime when I catch up, I’m going to revisit this issue and link to your wiki page. This issus is a serious pain and it’d be good to build on the groundswell.
I’ve haven’t seen Flux CMS yet and don’t quite have time to check at the moment, but I’ll put it on the list of things to do, because it sounds good. Thanks for the tip!
Edit: By the last statement I don’t mean that I’d consider moving from WordPress, because it has too much else going for it at the moment (despite the XHTML headaches), but I will check out the Flux editor.
*NB: secondary blog used in link*
“sorry you got caught in the spam queue” … dewd, what can I say but “Good eye!” Comment management … yet another problematic.
I don’t want to p*ss anybody off, but I did blog one loud blurt concerning the editor … it’s wrong in sooooooo many ways.
I invite you and any others to watch/contribute to my page on codex.worpress:
http://codex.wordpress.org/User:Bentrem/EditorScratch
Clambering out of the swamp for a moment: I don’t see WPMU really thriving until/unless issues like WYSIWYG are nailed … I mean aced. I pointed to Flux cuz I think the crew there is righteous, and because their editor might set the standard.
Nothing would please me more than finding a blog post that says, “WP as CMS? Absolutely … WPMU is a gem”.
^5
ben
Ben,
It was just the Comment Moderation queue (because of having more than two links), so I actually got an email to approve / spam it. It wasn’t that hard to spot!
Having said that, I get next to no Spam in the Askimet queue, thanks to the Math Comment Spam Protection and Simple Trackback Validation plugins.
That’s why I won’t be giving up WordPress - because of the number of great plugins which make life easier. Yes, some plugins are buggy and you could argue that WordPress should have these features built in, etc, but at the end of the day the functionality exists.
It’s sort of like Firefox (which can be a memory hog) and the huge number of great extensions to it. No way I’m swapping Firefox in the near future either! I couldn’t live without the extra functionality…
But the Editor is a part of WordPress that needs to be improved and I’m totally behind you on that!
@Stephen … sure wish you were on Twitter. (R U? –bentrem)
“It wasn’t that hard to spot!” is the hear/essence of SW; w/o cognitive foundations we’re just noise. Dunno that you studied it but know/feel you’re philo enought to grok: we’re the A1 finest filters in the galaxy. ‘cept for clouds … clouds are right clever. And then there’s goldfish … amazing how agile/adaptive they are. And gophers … rite clehvur. And my champion English Springer Spaniel OMG Ai?! And my Cat *blink* Oh-woops … where was I?
*grin*
Dewd, there are those of us who know there’s a piece of work to be done. Period. Full stop. The rest is sophomoric posturing. (Wanna posture up? UFC.)
“the Editor is a part of WordPress that needs to be improved” … dare me to be honest? Dare me?
That so many people have suffered so much so often shows how WordPerfect i.e. Automattic is only one of many entities who are more than willing to harvest the good will form WWW and Web2.0 while serving /tainted meat/. A certain group of well known people are too damned busy building their CV to do the heavy lifting. And I mean 80% of the buzz for 20% of the work.
I can’t seem a friend of WP … #wp-bugs shows that … like Moz 0.98a … I can do FMECA, I can change manage 175 MIL-SPEC docs … but I don’t rate responses on IRC.
Occam’s razor, bro’ … never are the eternal verites more true than when we deny them. Tech_doc types scare yuppies’ kidz … kidz have never heard *KWATZ!!*
Want revolution?
Easy: Bhutan … we set up an institute of IT/discourse. (see Jurgan Haberman’s “Discourse Ethics”. Also Heidegger’s “Essays on Technology”. While you’re at it, John Willinsky on OpenAccess.
k … that.
^5
ben
p.s. Woo! my last batch of beer turned out well carbinated at 7%!! *grin*
typo *D’uh!* 01:41 after beer *girlish giggle*
s/ “hear/essence” / “heart/essence”
K
‘nite
Ben, maybe I better get some of that beer - seem fun! When you sober up
have a look at the Trustworthy XHTML plugin. I just found it, haven’t tried it yet, but it sounds promising and I don’t think it’s on your list.
*I changed my blog link … for your entertainment.*
You might have noticed that I tried to be pretty exhaustive on my codex page … http://snipurl.com/1vkfp … my most likely course of action was to find out why FCK wasn’t the editor included; BitFlux is on the shelf, I saw it had not VewSource (but I’m inquiring into that).
But Jackson’ TrustWorthy … “Using a combination of internal options within TinyMCE and a modified version of wpautop()” … that seems very sensible. Thanks for that … spot on.
I have an up to date sandbox install, so lets see!
p.s. yesterday during WP “Bug Day” I worked through a bunch of “editor” tickets; on the one that seemed to be tracking the problems I suggested a quick fix, i.e since the problem happens when toggling between CodeView *cough* and “WYSIWYG” *nervous giggle* I suggested we supply a config option to switch the default … so CodeView would be front … which would mean that hitting Save/Publish directly from there would obviate most of those glitches.
I don’t expect that to move forward but heh it’s chumming the water; might find others in the dev community inclined to lean into this sorta thing.
cheers
Wanna create an editor plugin? *grin*
No joy. I’d like to say even “Close, but no cigar” … alas, for my purposes there’s no substantial change. Other writers with different kwetches might find some improvment; dunno.
see my ‘’sandbox” blog post
p.s. was gonna create an account for you but found email naught … no damage / no blame.
*Hands Stephen a cigar; puts another aside for Leo Jackson.*
Good news: I was wrong.
Turns out that the plugin’s XHTML config default to “Disabled”. I toggled that (XHTML transitional) and whoopeee! Toggling back and forth did notRPTnot blow my markup away.
Soo … though there’s still some wierdness (like heh not seeing all markup in “CodeView”) but it fixes some wretched behaviour.
–
Update: you can keep your cigar, but dunno that I’ll give Leo his … just yet. Did what I could to freak the editor out w/o using invalid code and ayup, at some point a few of the linebreaks disappeared.
I really think we mustRPTmust be able to see <br> and <p>. So, there we are.
^5
Hi Ben,
Hey your idea of an option to switch the default view (so CodeView could be the main view) is great! It should help solve the problem and there would be some people out there (like us) who’d prefer to start with the Code View anyway. Hope someone picks up on it.
So the Trustworthy XHTML plugin makes it better, but it’s not perfect… Hmm.. Small steps…
I agree that we should be able to see the <br> and <p> in the editor - one solution is just to type them all. When I was trying to get one page to validate, I simply typed the <p> tags where I wanted them and that stopped WordPress putting them in the wrong place - although it doesn’t always work and that the whole problem with this!
Well, thanks for the nice puff of rainbow-colored air! I’ve never released a plug-in (Remnds himself that the really hasn’t read through even “The Loop“.) so this might be my opportunity to really hoe in.
I think the real design flaw is that it’s overly aggressive in “correcting” markup. I say this because LJ’s editor doesn’t show <P> or <br>, but neither does it mess with them. I’ve always found that environment very condusive to quicki writing. (I only recently joined ning; that editor too is less dictatorial.) Point being: if editor doesn’t mess with markup then fine that it doesn’t show, but if it’s going to change things then it really should present that.
I guess “Show All” should be another option. Well, looks like I’ve got a project! *grin*
BTW: look forward to seeing you active in codex. *noodge!*
have a really happy Christmas, Stephen
cheers
Hi Ben, it’s Christmas day and I’m at work! (no holiday here in China).
Go ahead, write a plugin - it’s not that hard once you get into it. Yes I guess you’re right - we don’t really need to see all the XHTML as long as it doesn’t mess with it. If you know what it’s going to do and it sticks to it, then no problem. Having said, I think it would be good to have a button to show it if we want to see it - I’m just a little paranoid!
Anyway, I hope you are having a great Christmas!
*URL to my “Buffer Dump” blog at wp.com*
G’day Stephen; Christmas here and I’m doing what I do … nothing but “unity of the three times” for this vajrayana tantrika. *grin*
Yes indeed … “Plugin sighted off the starboard bow!” … I’m using this as test-case / pretext for learning “the loop” (see my new page on Code).
What I can’t figure: if a person wants to see CodeView, why would they not want to see all code?. To my way of thinking “all or none” would be most typical.
So, just that for now.
One Q: if a body was going to optimize an editor, would you personally recommend TinyMCE over FCK?
best to you and yours in that ancient place
–
Ben, Hope you enjoyed it! I’ve been taking it easy for the last few days (apart from work)
I checked out your Loop page - I’ve never seen most of those articles. Good collection!
Personally, I’m happy to see all the markup. If I were arguing why it shouldn’t show all of it: I guess a case could be made that it makes the content harder to read. Not a problem for those switching between views, but maybe a case for those with the Advanced Viewer turned off. A bit of a shaky argument though.
As for the choice between TinyMCE and FCK, I’m a little embarrassed to admit that I’ve never tried FCK - so I’m not much help on this one.
“I’m happy to see all the markup. If … I guess a case could be made that it makes the content harder to read.”
I think you’ve got the nut of it there Stephen; scenario / use-case being that a person goes into CodeView because / only because they want to stick something in that the WYSIWYG buttons don’t provide … as a work-around … so they wouldn’t care to see markup for the rest.
Fair enough. WYSIWY who wants CodeView as fall-back, and coders who want just the reverse. Ergo sensible to have configuration option setting which is default.
I’m trying to find out a) why TinyMCE became the install editor, and b) if there’s a snag with bundling FCK … licence or something. I’m trying to get my changes into the WP build, rather than just optimize my own site: so it would show up (eventually) on blogs at WordPress.com
cheers
(A sad day in Pakistan. *sigh*)
[…] solução prática veio do site More than Scratch the Surface, no artigo WordPress - Taming The Advanced Editor. O autor Stephen Cronin traz a solução simples e razoavelmente prática: “desligar o editor […]
Hi Ben, you shouldn’t have mentioned Pakistan. After I read your comment I went off to find out what had happened and forgot to come back to your comment! A sad day indeed…
I agree with everything you say above and it would be great to get these changes into the build…
And now for something different: I’m trying out Windows Live Writer for writing posts, then copying and pasting the XHTML across to WordPress before publishing. Microsoft have a lot to answer for with IE (and other things), but WLW seems to be a good product so far.
The XHTML seems to be valid (and includes all the markup, eg <p> tags, etc). I haven’t really pushed it though. We’ll see how it goes… It’s not really the answer though: on one occasion, WordPress still managed to break the XHTML by adding stuff to what I’d copied from WLW.
Hey Stephen … I got distracted by all sorts of fun stuff, not least of which is http://slowflying.groundplane.org
Now that I’ve returned to regularly scheduled programming … I wonder if most “serious” WP bloggers have found similar work-arounds? Likely the hand-coders have done that … and the media types use the WYSIWYG as is, or with a plugin. And naive users just do what they can. That doesn’t leave much of a community to demand change!
But I’m going to persist with the “CodeView as Default” check-box, if only as a way of getting to know “The Loop”.
So the bigger changes aren’t front.of.mind but my codex pages will provide continuity.
BTW: are you tooled up to do check-ins? It’s been years since I’ve done that.
Hi Ben, Sorry, been offline again for a week..
You could be right about everyone having there own solution, etc, but I think if you can get a solution happening, people will use it. I’m not tooled up - most of my coding is very small and simple stuff…
HiYa -
“I think if you can get a solution happening, people will use it. ” Agreed. And still, I’d like to see something that’s so basic that it gets rolled into the build.
As for “tooled up”: what I’m looking at is really pretty minor … changing/hacking the TinyMCE code or even the WP Admin panel isn’t like creating something from scratch (Thank God!).
cya
Stephen - I’m confused about your “not tooled up”. I have your “IFrame Plugin” JS and PHP open in TextPad just now … makes it seem like you’re pretty well tooled and up to speed!
*blink*
cheers
Ben,
I was assuming you were talking about CVS or SVN or something like that. I don’t use any sort of versioning system, but maybe I should…
As for up to speed, I’m really just a hacker (but one that’s been hacking for quite a while now). I can make it work, but my code isn’t always nice and clean like it should be.
Also, I better point out that the widgets part of IFrameWidgets is built on another plugin (GAdsense by Otto).
You may want to check out a new plugin I just heard about: Raw HTML Plugin for WordPress. I haven’t tried it yet, but it sounds good.
He shoots … he scooooooores!!!!
Wunnerful … good eye Stephen … that certainly seems to be the fix.
What comes to mind for me is that this magic could be selectable i.e. rather than introducing markup for one slab of source have it as a check-box either on a page in Admin config or on the WYSIWYG module.
And again: extending a choice of default mode I think dignifies the user, e.g. “Sure go ahead show me the WYSIWYG by default (or not) but don’t texturize.”
cheers
[…] way of context: I’ve been having an on-going exchange with Stephen Cronin in his blog about WYSIWYG being over-bearing and also I’ve put together what I hope is a pretty comprehensive […]
I’m quite new with Wordpress.
I never experience things like this when paste a html code to the WP editor.
Perhaps latest WP version has fixed this bug.
debt,
They’ve made a few changes, but there are still problems with it.
Think Style Sheets!
After plowing thru a ton of wp code and deconstructing all of the various suggestions for fixes to the line break/paragraph spacing issue, I’ve pretty much decided that the best/quickest/easiest way to deal with the issue is the theme’s style sheet. You will either need to add an entry or make a mod to an entry that corresponds to the class of the div in which your posts appear. WP will add a automagically between paragraphs (cr/lf in text) so the style sheet entry is something like (for mu wp):
.entry p {
margin: 6px 0 6px 0;
}
which would give you a 6 pixel margin at the top and bottom of each paragraph in div class entry. It is prolly different for single user wp, but you get the idea.
This way when wp upgrades roll, you will not have to deal with regression and integration. Most display issues can be handled in the css.
@Christofle Thanks for the effort … I’m sure most folk just throw their hands in the air and give up … surely out efforts will have to pay off some way some day!
So, if I read you write, you’re suggesting something like the way we have style sheet separate from the HTML in a web page … to control the behaviour of a WYSIWIG editor. I can’t help finding this a little bit funny, but you may have the right idea!
Maybe, if this works well, it’s a way of coping until the editor is really and truly fixed.
@Stephen What do you think?
–bentrem
[…] off the visual editor in Wordpress: (via Weblog Tools Collection and More than scratch the surface) In Wordpress’s admin interface, switch to the users tab and edit your current user. […]
[…] Stephen at Scratch99 has a great article about how to address this problem, and I suspect that Ryan will take the simple method of editing the TinyMCE javascript file and just turn off the “clean code” feature. […]