WordPress Rich Text editor bug – very serious!

For some reason, whenever I put the code in to embed the video it would seriously screw up my CSS.

There’s your ‘bug’ ;’) It’s the ‘code’ you’re entering…

More info here:
https://validator.w3.org/check?verbose=1&uri=http%3A%2F%2F7andacrescent.com%2F

Plenty of threads here, and examples that work and are valid too… None handy to me, but a search will turn them up.

The reason that I thought that it wasn’t was because I saw editing buttons above my post box.

There are buttons in both editors… it’s not a bug, it’s just that the buttons are different in each. It’s the output in the text input box that makes the two editors different.

Just an FYI…

It’s not the code that is the issue. When entered in the text box in any browser that still renders the Rich Text editor, even though it has been disabled in the Users tab of wp-admin, the CSS would get screwed up. But when entered in using the Safari browser, which doesn’t render the Rich Text editor at all, the CSS WOULD NOT MESS UP. So it is not the code, it’s WordPress.

If the Rich Text editor is disabled in the User tab, then IT SHOULD NOT STILL BE SHOWING BUTTONS FOR EDITING. That is not what disabled means. Having the Rich Text editor buttons still be visible even though they’re supposed to be disabled does not sound correct. Why give the option of disabling the editor if you’re still going to render them anyway, just not as pretty as before. That makes absolutely no sense whatsoever. Disabled means disabled. Don’t show anything except a box that I can type hard code into.

But that still doesn’t explain the aberrant behavior. If that is the way that the post editor works (rendering a text editor panel even though it’s been disabled) then the code to embed a video into a page should work no matter what browser I’m using. But it doesn’t. The code only worked properly when I brought up my WordPress admin panel in Safari. As I stated earlier, the post only saved properly in Safari. None of the other browsers that I brought the WordPress admin panel up in would save the post correctly. SO IT MUST BE SOMETHING INSIDE THE POST EDITOR CODE.

This is the code that Flash generated for my video:
https://7andacrescent.com/images/7CrescentCode.jpg

This is the code that wearetheweb.org uses to display they’re video:
https://7andacrescent.com/images/wearetheWebCode.jpg

There are no structural differences inbetween the codes. They were both generated by the Flash program. Neither one displays correctly when entered in any browser other than Apple’s Safari. If you’d like to test their code out, the address is wearetheweb.org (I AM NOT AFFILIATED WITH THIS ORGANIZATION IN ANY WAY); The only thing that I can gather is that there is a bug in the code that makes up the post editor in WordPress admin. If there have been so many threads discussing the same issue, as you have tried to point out, then obviously IT’S NOT THE "object" & "embed" CODE, IT’S WORDPRESS.

All I am asking is that someone from the development team explain to me:

A) Whether that is how the editor is supposed to function or not. Meaning the editor still displays formatting buttons, even though the Rich Text editing has been disabled in the User tab of WordPress admin. If someone (from the develoepr team) says that that is how it’s supposed to function then:

B) Tell me that you have gone over the code anyway just to make sure that what I’m describing isn’t actually happening. If it’s not then I’ll chalk it up to “user error” (meaning I WAS DOING SOMETHING INCORRECTLY) and I’ll apologize for being so rambunctious. But if it’s not user error, then LET IT BE KNOWN and LET’S GET IT FIXED!

I really, really, really like WordPress. I think it’s solid and exactly what the world of Blogging needs right now. But let’s face it: code bugs are a reality. You catch some and you lose some. But this is where the community comes into play to help the developers find and kill all of the bugs that they missed. IF THIS IS A BUG, it isn’t one that will make a person stop using WordPress, lol! It just makes things extremely difficult for those of us that work with Multimedia files on our blogs. I say better to be safe than sorry and just check the code anyway. What could hurt?

If you think it’s a bug, report it here. Dev’s will ‘see’ it much quicker there anyway.

If the Rich Text editor is disabled in the User tab, then IT SHOULD NOT STILL BE SHOWING BUTTONS FOR EDITING. That is not what disabled means. Having the Rich Text editor buttons still be visible even though they’re supposed to be disabled does not sound correct. Why give the option of disabling the editor if you’re still going to render them anyway, just not as pretty as before. That makes absolutely no sense whatsoever. Disabled means disabled. Don’t show anything except a box that I can type hard code into.

If you disable the rich text editor it is disabled!

Compare the button bars you see in your two images with it disabled the buttons are different and the text you enter in the text field is plain html.

I don’t think I’m explaining things clearly. Let me try this again.

If I disable the Rich Text editor, then there shouldn’t be ANY BUTTONS AT ALL appearing in the Write tab of WordPress admin. This is what disabled means to me. What I keep hearing everyone say is that the buttons appear differently and that is disabled. But that isn’t disabled. What happened is that the nice, pretty formatting buttons got replaced with buttons that are rendered in the style of whatever browser you happen to be using at the time. That is not disabling the Rich Text editor BECAUSE YOU CAN STILL USE THE BUTTONS TO FORMAT THE TEXT.

Yes, plain text does appear in the text box as opposed to the text that appears when the Rich Text editor is enabled. I UNDERSTAND THAT. But what I am saying is that because the Rich Text editor is still functioning (which it is. It just doesn’t pre-parse the text) it is interfering with certain bits of hard coded (X)HTML, which happens to be the <object> and <embed> tags. Now the reason why I have come to this conclusion is because of Apple’s Safari browser, which is well documented as not being able to render WordPress’ text editor format panel inside the Write tab of WordPress admin. When you embed a multimedia file inside your post using the <object> and <embed> tags while WordPress admin is open in Safari, WordPress has no problems whatsoever saving the code correctly. It is only when you try to do the same action in any other browser that WordPress has a problem with the code.

So what I am stating here is that the viewing of the buttons that are used to format text whether the Rich Text editor is disabled or not is a symptom of the problem which I believe to be a bug within the code that makes up the Rich Text editor. It’s like, you know you are sick because you sneeze and cough. Those are symptoms of the problem and not the problem in and of itself. In order to get rid of the sneeze and cough, you have to find out what is causing you to be sick and fix the problem. Voila cough and sneeze gone.

I think you’re explaining yourself ok. It’s the logic I can’t follow.

Once again, if you want anything addressed by anything other then the volunteers here, then report it here to the dev’s.

Thanks Yosemite. I reported the bug to trac yesterday after you dropped the link for me.

“It’s the logic I can’t follow.”

I’m trying to explain what I see as consise as I can. I wish I had that iChat theater that’s gonna be in Leopard so that I can visually show what I’m talking about. Sometimes screenshot’s just don’t help…..

For the sake of continuity, when you report a bug, you should post a link to the bug report here.

I think this might be a part of your confusion:

“If I disable the Rich Text editor, then there shouldn’t be ANY BUTTONS AT ALL appearing in the Write tab of WordPress admin. This is what disabled means to me.”

*You* think there’s shouldn’t be any buttons at all when the RTE is disabled. However, there are buttons. They are more plain code-compliant buttons that are there for simple ease of use for the person writing the posts. You don’t have to use them if you choose not to. But they were put there by the coders because many people *do* use them to place tags in there, so they don’t have to constantly type them out by hane.

There is a *big* difference between using the RTE and having it sidabled, regardless of the buttons being there. They’re only there for simplicity’s sake, and some people do use them – but it does not mean that you’re in RTE mode.

Both screenshots you sent are exactly what they should look like. Your RTE *is* disabled, whether you think those buttons should be there or not.

“When you embed a multimedia file inside your post using the <object> and <embed> tags while WordPress admin is open in Safari, WordPress has no problems whatsoever saving the code correctly. It is only when you try to do the same action in any other browser that WordPress has a problem with the code.”

Out of curiosity, what *is* “the problem” you’re having? Is it that it doesn’t validate? Is somethign deleted? What’s going on, exactly? Maybe if there were some clarification of *that*, it would help with this issue a bit.

I *do* understand what you’re sying though – you think that there should be absolutely no buttons whatsoever when RTE is disabled, and because they are there, something’s messing with certain code. But I think maybe if we knew what the “problem” was – what was being messed with and how – then maybe it would help to figure out if this is really a bug, or something that *is* wrong with the code.

Next to Yosemite, that has been the most helpful post I’ve seen, lol!!!! Thanks, doodlebee, that has clarified somethings for me. What I’ll do is recreate the errors and post some screenshots up. Don’t know why i didn’t do that in the first place….. shame on me.

@yosemite: I did link to the thread in the trac, so if and when the devs see the ticket they should come here as well.

Soooooo……

For some reason, I can’t seem to reproduce the errors that I got the other day. I don’t know why…I haven’t changed anything about my WordPress install and that is the god’s honest truth. I have tried to reproduce the error on every browser on my iMac as well as some of our lab PC’s and it’s been a no-go.

Soooooo……

I would like to apologize for taking up everyone’s time. I’m going to chalk this up to user error (meaning that I must’ve done something stupid) and go sulk in a corner. No, seriously, I really would like to apologize to everyone that posted as well as to Matt and the rest of the Dev team. I thought for sure that it was a bug there, but since I can not reproduce the error, I have no proof. If I sounded condescending or assinine or offensive, please know that that was not my aim. I just wanted to get the problem solved that I thought existed.

no need to apologize – and you didn’t sounds “asinine” or anything ?? I was just curious as to what the error was ?? I do know that, when using XHTML (especially the stricter types) that one of those suckers is totally invalid – I always forget if it’s the “object” tag or the “embed” tag. So I was curiosu if *that* was your issue – it just wasn’t validating and possib;y sending your page into quirks mode. ??

But asking a question, ‘specially if you think it’s going to help others – isn’t a bad thing at all ??

It’s the embed tagset that’s invalid. The object tagset is still okay to use.

Tnank you! I always forget which one it is. Like in French class in high school – I always forgot which was “socks” and which was “shoes” – chausseur or chaussette? (Please forgive my spelling if you’re French – it’s been a *long* time LOL – but I always remember forgetting which was which there!)