Maybe I'm just tired ... maybe this video is just tediously long. But maybe this editor is worth some attention, so I'm dumping this here link rather than just ^W and away I go.
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* if we're clever enough to Save or Publish while looking at our code in Source pushes most of what we actually keyboarded.
So 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. Meanwhile the WYSIWYG would remain, as an option, in the background where it so rightly belongs.
trac custom query (Only admins can save queries?! C'mon ... really ...)
20DEC07
Today (17JAN08) a plugin that seems to hit the nail on the head No such luck; see below. (thanks to Stephen Cronin for the heads up on this): "Raw HTML Plugin for WordPress" - "To prevent some part of your post or page from being processed and “texturized” by WordPress, wrap it in <!–start_raw–> ... <!–end_raw–>" by Janis Elsts at W-Shadow.com
"The plugin doesn't "tame" the editor in any way (that's why I say that using the visual editor is "not recommended" in my post).
So the visual editor is still at large ;)"
Actually, it only runs when a post is displayed. The plugin intercepts the content surrounded by the special tags and saves it in internal variables before WordPress can "prettify". Then, after WP is done messing with the rest of the post, it adds back the "raw" content in the right places.
MozDev? heh ... MozILE rocks totally! Gotta luv it. (Midas, the spec)
"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!"
"Taming The Advanced Editor" by Stephen Cronin (emph. added - bdt)
"Now it would be much nicer if the “code” window actually allowed you to edit the raw html source, but this workaround doesn’t quite do that."
"Customizing the TinyMCE buttons" at TimRohrer.com. (emph. added - bdt)
Leo Jackson’s "TrustWorthy XHTML" TinyMCE plugin may just do the job:
"I switch from Visual to Code view for a moment to fix something, and when I look back a few seconds later - it’s gone! All my <div>’s are gone, my <a> anchors are all askew, and when I finally publish my article, it’s changed again!
I finally had enough of it. It was time for change.
With Trustworthy XHTML, you are in control of auto-formatting - finally! [...]
Using a combination of internal options within TinyMCE and a modified version of wpautop(), I have created 5 options within Trustworthy XHTML"
(thanks to Stephen Cronin at "More Than Scratch the Surface" for pointing me to this)
No joy. See my sandbox test post. Meh.
I'd like to say at least "Close, but no cigar" ... alas, for my purposes there's no substantial change. Other writers with different kwetches might find some improvment; dunno.
see WYSIWYG HTML Editors at OneNaught.com, a good overview with a nice set of reference links e.g. "WYSIWYG Editor Checklist".
--
Do these have plugins?
--
File under WTF?!: "A wysiwyg HTML editor for use with IE 6 and above". And it's OpenSource and everything!
Ayn is similarly brain-dead, but it will work with IE5.5. And it's GNU, to boot! *snort*
NB: this is copied directly from How WordPress Process ...