HTML Code Reformatted by Visual Editor

First off, it’s not ‘a problem’ so to speak – it’s designed (and desired for the vast majority) behaviour.

Second, it’s not WordPress that does it, it’s the TinyMCE editor that is used by WordPress.

There is an HTML tab that you can click and use instead of the visual editor, perhaps you can try that one?

Also, I may be getting the wrong end of the stick as your rant is not particularly concise, but you seem to be complaining that the visusal editor strips all of your HTML tags, and then later you mention that it is not practical for you to have to code everything in HTML as you are the only one that knows it? You seem to have contridicted yourself.

1. I find your response to be incredibly rude and condescending. When someone comes seeking assistance, to insult them by calling their request a “rant” is totally inexcusable.

2. It is a problem, or there would not be many different threads here on www.ads-software.com complaining about it, dating back years. How could rewriting someone’s carefully formatted code be a “feature”? That makes no sense at all, especially when the rewrites make the page or post in question completely illegible.

If this so-called “feature” is really a “feature”, please tell me the purpose of the visual editor fouling up a person’s carefully formatted code and forcing them to totally rewrite it each time a page or post needs a minor edit?

3. If you actually read what I wrote, you would not have insulted me by telling me about “the little HTML tab”. My words made it very obvious that I use that tab, but when WordPress opens a post or page to edit, it automatically opens in Visual Editor mode, fouling up the html I’d carefully formatted when I initially wrote the post.

4. I haven’t contradicted myself at all. What I said was that I often work with teams, and those team members do not know html, so it is not practical to ONLY use html on each post, as often others will want to do a simple edit and they require the use of the visual editor.

It is not at all unreasonable to expect WordPress to respect the code entered by the person who has created the post, and not completely change everything each time a post or page needs editing.

One should not have to worry about a post being totally messed up just because one has to switch to a visual editor. Especially when recent versions of WordPress are not even allowing me the option of opening them in html mode to start with, and immediately foul up the code as soon as the posts opens for editing.

Now. I’d seriously like someone who’s polite and willing to listen to peoples’ concerns without insulting them to respond. Maybe even someone who’ll actually read my words and know what they’re talking about.

Yes, NOW I am ranting. I wasn’t before, however, I was just honestly seeking some friendly advice about something that is a legitimate and long-standing bug in the WordPress visual editor.

I’m sorry if you find my response rude, that was not my intention. I was mearly pointing out that I found your post difficult to understand adn I feel that others will as well.

If what you are reporting really is a bug that goes back years, do you not think that it would have been addressed by now? What I was pointing out is that although it may not be desired behaviour for you, it is for the majority of usrs. And also that it is not WordPress that does this, but rather the TinyMCE editor that WordPress uses.

I too have users who know little or no HTML so must use the visual editor, but we can switch between it as we see fit, and which ever editor that was used last on the post is selected the next time it is edited. Perhaps you have an issue with the WP core (A file that is not often caught on the update)? It may be worth doing a reinstall of WP completely.

And please, for your own health, calm down, take a deep breath and smile – life is too short ??

It makes no sense at all to see this as a “feature”, and if TinyMCE is the issue, which I’m sure it probably is, then the programmers of that interface have been ignoring a problem for years. A simple search in these forums will find quite a few complaints about the issue. I most certainly performed said search before I came here and posted, as pretty much every example I found of people complaining over the years had been “closed to comments” without the problem having been resolved.

I use WordPress on several different sites, on several different servers, and they all have the same issue, or variations on the theme, so it’s not a problem with the core installation. On some, the post will in fact open in the last mode it was saved in (but visual editor still trashes custom html code). On others, posts/pages will always open in the visual editor and immediately foul up the code regardless of how they were last saved, not even giving me an option to choose html first. It is not just one site/server, so again, it’s not the core installation.

Perhaps if I explain what led me to come here and ask about the problem, my initial post will make sense.

One of the sites I use WordPress for is a national organization. I work there with a team, some of whom do direct edits, others will email me and request that I make the changes. There is an event coming up, with four different entry categories. I therefore had to create four different pages, with four different entry forms, each linked to the organization’s paypal account. I spent several hours working on these forms, and had them all working just fine on the WordPress site.

This morning a minor edit was requested, just the need to change some of the initial wording and adding some links. The change on these four pages should have taken me a few minutes. It was a simple matter of editing text and inserting links.

I spent over two hours fixing the pages, having to completely recreate all four forms numerous times, because even though these posts were created and saved in html mode, WordPress (or TinyMCE as it were) opened each one in the visual editor and completely trashed the form code (I had even originally inserted the forms between ‘preformatted’ tags, knowing that this has been an issue for years, and hoping that would help, but WordPress/TinyMCE stripped those tags as well).

Perhaps now that the issue has been illustrated more clearly, it will make sense as to why I came asking if anyone has a workaround to the problem of the WordPress visual editor messing up the code. This is far from the first time this has happened, and some variation on the problem has occurred on every site I use WordPress with (on various different servers).

Thank you for your concern about my health, but I’m sure it would be much more beneficial to said health not to have to spend two hours rewriting code for every five minute text update I have to do. ??

For this particular occasion, have you considered a plug in to allow you to do the forms? That way you can display them on the page using Short code, thus negating the need for a large chunk of code to be written in the editor.

TinyMCE has a configuration setting that allows you to put in your own custom HTML code. As a security feature, it will only allow certain HTML tags by default(valid elements )
You can modify initArray ( Wp-root/wp-admin/includes/post.php — line 1553) to add, remove, change elements of the config before tinyMCE.init .
In the past , I had made a try and messed up my WordPress installation . Give it a try , you may be more experienced than me and get the results .
I think the “value —extended_valid_elements— ” of $initArray is the solution . Let me know if you get results ….
Back-up first …

And then backup the file in question if it works, as the next WP update may overwrite that file.

This happens when you post Java code as well. In particular, the following code loads a Mathematica CDF file. Once I switch to visual and back, it has extra stuff put into it that keeps it from running. (Sometimes one switch back and forth does not trash it but two switches do.)

The code:

<script type=”text/javascript” src=”https://www.wolfram.com/cdf-player/plugin/v2.1/cdfplugin.js”></script><script type=”text/javascript”>// < ![CDATA[
// < ![CDATA[
var cdf = new cdfplugin(); cdf.embed(‘https://www.abstractmath.org/Mathematica/SecantInCircle.cdf&#8217;, 600, 660); cdf.setDefaultContent(‘https://www.abstractmath.org/Mathematica/SecantInCircle.jpg&#8217;);
// ]]></script>

The modifications happen inside the <script></script> block. This is what it looks like after several switches to visual:

<script type=”text/javascript” src=”https://www.wolfram.com/cdf-player/plugin/v2.1/cdfplugin.js”></script><script type=”text/javascript”>// <![CDATA[
// < ![CDATA[
// < ![CDATA[
// < ![CDATA[
// < ![CDATA[
// < ![CDATA[
// < ![CDATA[
// < ![CDATA[
// < ![CDATA[
// < ![CDATA[ var cdf = new cdfplugin(); cdf.embed(‘https://www.abstractmath.org/Mathematica/SecantInCircle.cdf&#8217;, 600, 660); cdf.setDefaultContent(‘https://www.abstractmath.org/Mathematica/SecantInCircle.jpg&#8217;);
// ]]></script>

It is easy to repair by hand but it shouldn’t happen.

I object strongly to the “you should code in html” attitude. WordPress is for the general public, not coders.

I’m afraid I have to agree with DragonDreamz completely.

There IS an issue with TinyMCE overwriting existing HTML code without allowing for any kind of “leave this alone, really, it’s good” option in the visual mode.

WE can all code in HTML just fine (well, most of us) – but like SS says – our clients can’t. Which is why they’re paying US to setup and maintain a site, right?

Saying “there’s not problem” is just an excuse for poor coding in the editor itself. I know there’s always one more thing to fix with any software project – but it’s obvious DD knows what she(?) is doing. This isn’t a user issue. It’s a software issue, pure and simple.

(And yeah, DD – you’re perfectly clear. ?? )

Have anyone tried to switch off Visual in profile by ticking “Disable the visual editor when writing” and see it alters your html code.

Thanks, AK_Jenny. ?? And I see SixWingedSeraph is now having the same issue.

What I wound up having to do with the pages/forms in question was set up a subdirectory, format form pages outside of WordPress, and post links to the pages. Nothing allowed the forms to stay formatted within the WP interface and I could not get that particular site to default to the html editor no matter what I did. By the time a suggestion came through about plugins (which didn’t feel like a logical workaround with these particular forms, which were quite extensive), I’d already just given up and decided to hand-code the separate web pages. It worked. Not as integrated, but it worked.

It is an issue that a simple search here will show has been cropping up again and again for years, though. The first step in tackling a problem, of course, is to admit there’s a problem to tackle.

LOL

Seraph, I really do hope you’re able to get your site to work. Best of luck!

(And PS, yes. She. The horse is a he, though. ??

You need to check if there is theme options if not then footer.php is where you can make the changes.

After running into the same issue and reading this thread, I opted for trying a different editor than the default TinyMCE

I installed “CKEditor for WordPress“, and while it doesn’t show the custom HTML properly in Visual mode, it does leave it untouched, so even if I (or anyone else) edit the post via Visual mode, all remains good as long as the custom code areas remain untouched.

+ The CKEditor feels a little better anyway (but keep in mind I only worked with it for a couple of hours so far).

DD – it seems you’ve enabled your scenarios already, but hopefully this will come in handy for the next person in line that goes through the same problem.

Ultimate TinyMCE (WordPress plugin) seems to be the solution. It has a feature/plugin called code magic html editor.

CodeMagic is an advanced source code editor plugin for Tinymce. It integrates CodeMirror library for syntax coloring and Jsbeautifier library for code formating and indentation.

This is a very cool option which will add the following features to the HTML Magic Editor Box:
Realtime syntax coloring using mixed HTML/CSS/JS mode.
Proper code formating and indentation.
HTML tags code hinting and auto completion.
Undo/Redo history.
Search and replace functionality.

So just use this instead of the standard wordpress html editor.

Ive read a lot of forum comments regarding this topic, with lots of people trying to justify tinyMCE ruining html code. Which is not justified at all, I do not see why the standard html editor does not work just like code magic html editor.

If its a question of protecting clients from themselves, then there should be an option to allow html editing to be controlled by user level, ie Admin only or whatever.

That is more logical and rational than ruining the code.

Now someone please make a plugin that changes the html editor to code magic html editor.

—

Also this plugin seems to be proving very useful: Preserved HTML Editor Markup

I’m using both these plugins together.

WordPress REFUSES to open up a post edit in html mode.

DragonDreamz, although that often appears to be the case, I don’t think this is quite accurate. In my experimenting to solve the “visual editor totally butchers the code” issue, I have discovered that when you go into a page/post to edit the content, the editor returns to whichever mode was last used when anyone edited anything (page/post) on the site. So the fact that you lasted edited page “X” in code mode means nothing if someone else edited page “Y” in visual mode: WP will put you into page “X” in visual mode because that is the mode that was used last.

The short and dirty workaround is: When you go into a page and it is in visual mode, change to code mode, do not save the content of the page (that is important), then leave the page. You will of course get the error message about leaving the page without saving the content. That is what you want to do!! Then, you can return to the page. The editor will appear in code mode with the last saved code in the editor. You will get the message that there is a newer autosaved version, but you can get rid of that by doing a quick save on the original code.

The only other option I know of (save the possible solution offered by the above mentioned plug-ins, which I have not tested) is to simply disable the visual editor for all users. But lets face it, most of the time that is not a practical solution.