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.
To turn off the advanced editor, login to the Admin area and click the My Profile link in the top right hand corner. The first parameter on the resulting page should be Use the visual editor when writing. If this is checked, uncheck it and click Update Profile.
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.
Note: if you do this, the Advanced Editor will not do any cleanup. If you make errors in your HTML that break the theme, you’re on your own! If this happens you may not be able to edit the post anymore – the only solution may be to close the browser, go to the manage posts page again and delete the offending post.
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.
Note: you need to delete your browser cache before this takes effect. For Internet Explorer, click Tools on the menu, then Internet Options, then Delete Files. For Firefox, simply press Ctrl+F5. For other browsers, sorry you’re on your own, but it should be straightforward to do.
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.
Hi
Looks good! Very useful, good stuff. Good resources here. Thanks much!
Bye
Stephen, I can’t thank you enough because I am usually adding HTML to my articles and the way that I found to get through this was this:
I pasted the HTML in the after selecting the Code Editor Tab, and without clicking anywhere else I saved the drat, else if I clicked the Text editor tab before saving it, it would automatically try to master the code!
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!
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*)
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
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
Very useful information. A had a lot of troubles with html in my blog. Problem is solved with your hack. Thank you for that. WP rules! 🙂
I use WordPress 2.5.1. I opened tiny_mce.js but there was no such code
this._def("cleanup", false);
. By the way I see only single line of JavaScript code. I made search for term “clean” and find at 86077 position this “cleanup:1”. Maybe should I change 1 to 0?I’ll take a look at this and see if I can fix the behavior in WP 2.5.1 unless you have posted an updated article for WP 2.5.1 yet? Maybe I should make a plugin for this as well. I’m also working on a plugin that gets rid of the UTF-8 and MS Word characters that sometimes appear in posts when copying/pasting from word processing programs and WordPress’s own sanitizing filter adds it back in, so I had to remove it twice. This would be a great addon for the existing plugin so I’ll try to get that out soon.
I gave up trying to disable the editor and learned to live with it. I wish I had found this post sooner. Thanks.
This is great. I usually write my posts in notepad and then paste them into WordPress so I add the HTML takes and such by hand so the Visual Editor is just a pain. Thanks.
Thanks guys, this is a really useful discussion. So many options to investigate! I’ve heard good reviews of Live-writer (MS may have actually produced something useful!)
I tend to write longer posts in Word, then paste them in, using the Paste as Plain Text option (in the hidden, advanced options of the wysiwyg editor)
Cheers, Jon
I was having a big problem with formatting, especially WP removing blank lines. I didn’t realize it was because of the things you mentioned here. To work around this problem I use the Text Control Plugin and set my formatting to nl2br. I don’t really understand what I have done or why it works (it may make more sense to you), but it did solve my problem.
I know I am not discussing something relevant to the above post, but I would want to know which plugin should I use to get the digg.com sign on the left side before the start of the title of each post of my blog. I have seen it on many blogs but do not know how to get that. Can anybody help.
Thanks for this post. It saved me some time getting it disabled. It is so much easier to use an external editor.
Like so many of the previous commentators have said; I wish I’d found this post sooner!
Regarding Eva White’s Qs about the digg.com – The one I’m thinking of is a ‘Digg this’ button which you can get from the digg site: go to the bottom of the digg website and click on ‘Intergate Digg Buttons’.
I am actually finding the advanced editor very helpful for styling my articles. I don’t know HTML well yet so I guess I rely on it for now. I will bookmark this for later. Thanks.
Thank you for very usefull advices. I permanently have troubles when I copy some html code into blog post and forget to close some tag. Also it is annoyed when in HTML view I create line breaks my pressing Enter and when I go into WYSIWYG mode all my linebreaks are lost. Now I hope I will save more time.
Hey there Stephen – Long time no see! And best of the season to you.
Was on TalkShoe yesterday for Jeffro’s WordPressWeekly with Ma.tt and huh huh when things got slow asked about MCE being “almost usable yet”. Turned out a lotta the guys on the channel in fact had it set to HTML! Which kinda proves the point but heh apparently it’s a whole lot better with 2.7 so *shrug* that’s how it goes.
cheers
–bentrem
Hey Ben,
How’s it going. I’ve just downloaded the podcast (I listen to it on the train), so I’m really interested in it now. Yeah, I gotta admit it’s been a long time since I tried it. Might have to give it a go (not holding my breath though)..
Nice tip about using external text editor. Some people would be better off doing it this way then turning advanced editor off. I just turned mine off after the first few problems.
this is useful information about the behavior of tinymce and its code cleaning actions. i’ve just integrated the editor into an application of mine and noticed that the way it changes things can be kind of irritating. so this post definitely offered me some clues about things i might be able to do to work around these issues.
I can’t tell you how much heart ache and pain this little trick would have saved me if I had only known about it 2 months ago. TY, TY, TY!!!
i got as far as this part
Note: if you do this, the Advanced Editor will not do any cleanup. If you make errors in your HTML that break the theme, you’re on your own! If this happens you may not be able to edit the post anymore – the only solution may be to close the browser, go to the manage posts page again and delete the offending post.
and then got scared and thought, i’ll manage. better slightly mangled than completely broken!
Interesting – I noticed the advanced editor was doing something with the code I posted in but this post explains a lot.
I think I will leave it as it is for now though because I’m not confident enough with HTML to be sure I won’t break my theme. It’s good to understand what’s going on though.
Great
thanks for all the tips, good useful information
Yes advance editor in wordpress has some problems but I do not think it can not resolved..ur tips are resolving some problems….And WordPress is better than other providers but it has some of weak points also (Every thing has..)
I font changes when i copy from my word document and pest their directly…but it was resolved….now I am facing no problem at all….
I can’t express thanks you enough because I am frequently adding HTML to my articles and the way that I found to get through this was this:
I pasted the HTML in the after selecting the Code Editor Tab, and without clicking somewhere else I saved the drat, else if I clicked the Text editor tab before saving it, it would robotically try to master the code!
Thank you so much for this post!
I have spent years trying to fix the stuff that WordPress had automatically ‘cleaned up’ for me.
It ranged from email sign-up boxes disappearing, to course registration forms going AWOL, to PayPal buttons vanishing – all of which has caused havoc and cost me credibility and customers.
Like previous commenters, I WISH WordPress would allow us the ‘lazy’ option of the visual editor, but with a check box in our settings telling WP not to bother messing with our html, when we use it 😉
Thank you for such a simple suggestion to help me keep my pages looking the way I want them to in future.
Namaste,
Clare
P.S. If ever you feel the need to de-stress / learn to meditate / dump baggage in your life, please let me know. I’d happily give you a free place on one of my courses to say thank you for taking the time to help total strangers!