wysiwyg editor reformatting my HTML
-
Why does the WYSIWYG editor in WordPress reformat and screw up my HTML in my posts?
After writing the post, I find a typo, I go to Manage>edit and it takes out all my <p> tags and runs all my sentences together.
I’ve been having to hack by using Dreamweaver as my editor and then having to cut and paste in code view. Its frustrating that I cannot trust my WordPress editor to edit it.
I’m using Firefox 2 on both PC and Mac and Safari on Mac.
What can I do?
-
I can’t understand why this problem. I’m with WordPress 2.5, where it says
…a WYSIWYG that doesn’t mess with your code…
but if I write in a post this:
<object width="425" height="350" data="https://en.sevenload.com/pl/MuSJRtd/425x350/swf" type="application/x-shockwave-flash"> <param name="FlashVars" value="apiHost=api.sevenload.com" /> <param name="AllowScriptAccess" value="always" /> <param name="movie" value="https://en.sevenload.com/pl/MuSJRtd/425x350/swf" /> <param name="allowfullscreen" value="true" /> </object>
(valid code from XHTML 1.1)
why if I go to edit it, them “someone” has chaged it for:
<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="425" height="350" codebase="https://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"> <param name="FlashVars" value="apiHost=api.sevenload.com" /> <param name="AllowScriptAccess" value="always" /> <param name="allowfullscreen" value="true" /> <param name="src" value="https://en.sevenload.com/pl/MuSJRtd/425x350/swf" /> <embed type="application/x-shockwave-flash" width="425" height="350" src="https://en.sevenload.com/pl/MuSJRtd/425x350/swf" allowfullscreen="true" allowscriptaccess="always" flashvars="apiHost=api.sevenload.com"> </embed> </object>
finally, with WordPress 2.5 also I have to disable visual editor for write and edit posts without strange changes ??
biker3,
How did you disable the visual editor? I’m still experiencing problems with 2.5 messing with my code and am a little pissed about it.
Rich
I just found out today. When I switch from visual to html to insert some code save and go back to visual it cuts up the inserted code. If you have inserted code you cannot go back and forth between visual and html. Serious pain! Does anyone know if anything is being done about this?
I have to second this option. I’ve searched for about a half hour here in the WP support forum but haven’t seen an answer to this yet. I’m running 2.5.1 and in my opinion, the HTML option should be just that — completely open to html editing. If I screw it up, its my fault. Maybe in the admin options, where you can uncheck the visual editor per user, why not have an uncheck html editor for those who don’t need to use it (most of my users NEED the visual editor).
Do not use the visual editor if you want to edit your own code. The visual editor is only for code-phobic newbies. Switching back and forth between code view and the visual editor will only cause you problems and mangle your custom code. The visual and code editors have different ways of doing things, and going back and forth between the two types of editors can cause code errors to accumulate.
I use only the code view and then repeatedly preview my saved (but unpublished) post to see exactly how my code looks visually.
Hey all,
I recently came across this thread in search of a solution for symptoms that most closely resemble planetim’s post.
iridiax – while I agree with and often practice what you preach, the content on our blog is occasionally authored by multiple people. So, not everyone in our group has the desire or experience to use straight HTML. In this scenario and under certain circumstances, straight HTML code added by one person may ‘vanish’ as a result of another author merely fixing a typo through the tinyMCE editor.
Up until now, this has not been a real problem with the one exception of iframes (a common solution for adding custom/ external content that I’m sure most folks here are familiar with).
Well, we recently stepped up to WordPress 2.5.1 and have been running smoothly until a need arose to post something with an iframe that would wrap some media content.
In short, what used to work in sub 2.5 WordPress would no longer be displayed correctly once an HTML post was revised with the tinyMCE editor .
Considering this a step back, I dug in and found a fairly forceful solution that meets our needs. Still, I felt it was relevant enough to share with the other folks out there who may have experienced the same frustrations I did.
Let me be clear – I am VERY aware that this is not the proper way to accomplish my goal. In fact, I encourage a more experienced user to enlighten us all with an approach that is easier to apply and has less potential for adverse effects.
And of course – as I just stated, the procedure below changes the intended function of the tinyMCE editor in WordPress and could cause irreversible damage to your blog. Therefore, consider the following for informational / discussion purposes only and proceed at your own risk:
- Locate the file ‘tiny_mce_config.php’ ( it should live in %your_blog_root%/wp-includes/js/tinymce/ )
- Assuming you want to avoid catastrophe if things go awry, back this file up!
- Open this file in any text editor and locate the following code ( Line 298 for me )
- Replace with this ( or a variation to suit your own needs )
- Save the file back to its original location
- Clear your browser cache ( for good measure )
- While technically unnecessary, you can also delete or rename the folder ‘js_cache’ ( it should live in %your_blog_root%/wp-content/uploads/ )
- Test your new settings with the desired code by toggling back and forth between the ‘Visual’ and ‘HTML’ tabs at least once. Return back to the HTML view to verify the code is still there and finally back to the ‘Visual’ tab to save/publish a test post.
// Add external plugins and init $content .= $ext_plugins . 'tinyMCE.init({' . $mce_options . '});';
// Add external plugins and init $content .= $ext_plugins . 'tinyMCE.init({extended_valid_elements : "iframe[id|class|title|style|align|frameborder|height|longdesc|marginheight|marginwidth|name|scrolling|src|width]",' . $mce_options . '});';
That worked in my situation, I hope it helps other folks here apply a good temporary fix to a problem that should be addressed in later versions.
Something, anything – even a simple tag like:
{ignore_this} bunch of stuff {/ignore_this}
might encapsulate code that should be ignored by all the various levels of HTML cleanup. And yes, I realize this creates potential problems that the good folks at WordPress were probably trying to avoid.
Anyone want to write a plugin?
Thanks,
Chris
Hy,
This fixed the problem for me with Advanced TinyMCE, but I still don’t see the second line of formatting tools. Does anybody has a fix for that?
Thank you
Vizthink: You are a Gentleman, a Scholar and a Star. (if, however, you happen to be female, please feel free to alter the first of those honorary titles)
You have just saved me the arduous task of having to backup my posts to Notepad for fear of losing my iframes code by opening in the visual editor – and from the frustration of constantly forgetting to do so!
I am using iframes to display google maps and will also be using them to display Lightroom image galleries. This Visual Editor bug was a real pain. Hopefully it will be fixed in the next update.
Thanks again for the tip.
Chris.
BeautyPhoto.comSoulplayer,
Sadly, I have no input on your issues with the Advanced TinyMCE buttons – although keep searching, I have seen some thingss floating in these forums that may pertain to your particular issue.
chrisbirchall,
Awesome! Glad its working and solved your problems (at least for the short term). Your initial guess was right, so you can continue to call me a Gentleman ??
Cheers!
I had the same issue, banged my head against computer then found the wp-unformatted plugin, installed and it works perfectly, and is 2.5 compatible.
Hmmm. Just did the 2.6 upgrade hoping all this would go away.
Same old same old…
Worse in fact. The WP2.6 editor still chews up the code when you have an iframe on the page. But now even the above “fix” doesn’t fix it!
I’ve just restored my 2.5.1 backup files and I’m sticking with it until Matt and his gurus come up with an editor that behaves itself.
Long ago I learned to turn off the visual editor and work without it. It mangles code, it double encodes UTF-8 to the rss feeds. The visual editor should put out EXACTLY the same code that the html editor does, with the same encoding, but it does not.
Just disable that visual editor and don’t ever go back there. You will be happier.
Sure that’s an option. However, the whole point of using the likes of WordPress as CMS is to get away from hacking about with HTML – otherwise we might as well have all stuck with Front Page!
I don’t pretend to be a coder, so I wonder if Vixthink or anyone else can come up with a variation of the iframe fix that will work in WP2.6?
i tried vizthink’s solution and put the iframe codes within
iframe code here
, switched to visual, happy that the iframe works, switched back to HTML for good measure..it didn’t eat up the coding but converted it to
<code><br /> If you can see this, your browser doesn't<br /> understand IFRAME. However, we'll still<br /> <A HREF="hello.html" mce_HREF="hello.html">link</A><br /> you to the file.<br /> </code>
did i miss out anything? will try wp-unformatted plugin next..sigh
It worked fine for me in WP 2.5.1 Upon upgrading to 2.6 the problem reared its ugly head once more. The wp-unformatted didn’t help either.
I just hope someone will come up with an answer that will work in the latest version.
- The topic ‘wysiwyg editor reformatting my HTML’ is closed to new replies.