WYSIWYG editor losing HTML on 2.1

Sincerely hope that this is being addressed, as it does not seem like a “nice-to-have”, but a *totally mission-critical element* in a piece of software that has writing blog posts and pages as its main purpose…

Frankly, I was a bit shocked to find this after upgrading from 2.0.7 (at least the somewhat clunky “old HTML” editor window/WYSIWIG form combo worked mostly – though it seemed to do a few weird things to certain HTML structures as well).

In regard to tec-tec’s post, is it true that the “Code” portion of the form doesn’t screw up the HTML? If so,can anybody who actually wrote the .php/JS stuff for the editor tell us how to do a rig/workaround (e.g. in the general-template.php file) to only display that “Code”/HTML option until this is resolved?

I’m a bit bemused why folks don’t just go turn it back on after upgrading to 2.1x?

Users -> Your Profile.
Top checkbox – check it. Done.

Hurray! but that still doesn’t solve this problem:

<i class="foobar">foo bar</i>

gets edited to

<i>foo bar</i>

really really really annoying. can’t use inline styles(excapt on span and div), can’t use javascript, can’t use anything that would have made posts and pages more interesting.

If it were to prevent anything funny in the comments, i would’ve understood. but why do it for posts. Trust the blogger to know what he/she is doing will ya?
and even if it isn’t valid xhtml, let em take the risk. It’s their blog after all.

that said, it there an option to disable that undue html chaperonage?

if there isn’t, what files/functions/piece of code can i cannibalise from wp2.0 and reuse in my wp2.1 installation. or is there a plugin that can disable all those unwanted features and make wordpress behave like the blogger dictates and not the other way around?

scratch that last part, i just found a possible workaround

Thanks for the tip HandySolo, I wasn’t aware that this could be set there. So even though that solves the immediate crippling problem, now it’s all HTML all the time, which is of course a bit of a loss, especially with posts to be done quickly.

I still believe that fixing the WYSIWIG should be very high up on the agenda.

Best wishes.

Any chance of this getting fixed any time soon?

Please add my vote for a fix — and see also the Ideas section — the first page of the Popular list has

• Access to TinyMCE Plugins and Options
• Choose a better WYSIWYG editor
• and, Let us force a line break

all marked “under consideration”.

Thanks, all, for WordPress — but access to the HTML in the pages/posts does seem important to many.

My work around for <br> tags that don’t work is:

<p>&nbsp;</p>

seems to add a line break in most browsers.

there is no reason that html code should change when switching from rich text editor to html code.

can you imagine if any other html editor on the market did this?

obviously it doesn’t have to be this way because as someone said earlier, if you view source on the web page the correct code is there, so therefore they could have it retain the html code when switching to wysiwyg mode if they wanted to.

why have yet another beta without fixing existing code first? waste of users’ time having to re-edit posts all the time. pushing me toward Typo and Ruby on Rails.

if I was the only one using the blog, then maybe I could put up with it, but try explaining it to 2000 users. Basically you have to say your blog is broken and will remain so for the immediate future unless they want to learn html and that if they don’t like it, nothing you can do about it. And if you leave rich text editor on for them, get prepared for piles of email about how their code gets lost switching from rich editor to html. Yes, yes, Mr. Customer, I know it looks amateurish, but hey I’m using free software and you have to expect this level of inconvenience.

Not really a way to move a platform forward, when the core function, writing posts, doesn’t work properly for users.

Dan

Well, no one is more suprised than me to find a working version of 2.2.2 without this problem. I had to do a fresh install of 2.2.2 (not an upgrade) into a blank directory. That is the only way to get rid of the problem as far as I can tell. I think the problem began around the upgrade to 2.1.2

WordPress Support: Look for the answer somewhere around the upgrade process from previous versions to 2.1 or 2.1.2 to not have a repeat of the same issue in the future. The solution is not always offering an upgraded version, if the upgrade process is the problem.

Users: You want to fix this problem? Switching to default theme won’t work. Doing any kind of upgrade won’t work. (for now at least until they figure out what went wrong, which they might never bother to do)

You need a fresh install of 2.2.2 into a blank directory.

I know it’s depressing if you have a big or complex blog to migrate over, but I’m afraid you will just have to do it and move on. On the bright side, you can stop tearing apart your theme looking for the answer and it is NOT browser related as some have suggested in other threads.

Dan

Not sure if the fresh install thing is necessarily true — at least for 2.3. I installed 2.3 for the first time — no upgrade, and I have the problem, too.

Only thing that works for me is disabling WYSIWYG altogether and writing HTML. Definitely non-optimal for casual use. I’m really surprised to see this issue drag on for so long.

Working in FireFox for the Mac I can’t get HTML to show when editing a page. Need to drop in the trigger for a contact form (e.g., <!– ddfm2 –>) and am having no luck at all getting it to work — in either “visual” or “code” view. The latter just gives me different editor buttons but no HTML tags!

This has been a real problem: how to implement any plugin that requires a trigger in the post or page? Tried creating a custom field on the off chance it would work — it didn’t. Any help?

The “disappearing HTML” thing has everyone chasing their tails. Perhaps if we can put that into its own box we can then get on with problems like the one Organica brought up.

In “WYSIWYG is stripping html from posts” it’s come down to this (thanks to kmessinger):

“Sometimes when I come back in the code mode it looks like the s are gone but in the wysiwyg they are still functioning and in the actual post all is ok.
So, the key I think is not to flip back and forth between code and wysiwyg or if you do, save (publish) in between.”

So …

Attempt at persistent resource on related issues at:

https://codex.www.ads-software.com/How_Wordpress_Processes_Entry_Text