If you’re using the wysiwyg, yes, this will happen. Try when needing to add the target attribute disabling the wysiwyg for that post.
>> If you’re using the wysiwyg, yes, this will happen.
This happens even when using the xmlrpc interface.
Is there some way to disable this as it seems rather heavy-handed to be messing with my HTML
>> If you’re using the wysiwyg, yes, this will happen.
So why the heck does the WYSIWYG editor have an option to do this? I can add the target attribute in the WYSIWYG editor and then it just removes it?
That doesn’t make any sense at all.
Just confirmed it. Add a link with a target attribute in the WYSIWYG editor and then save it and the editor removes the attribute.
Where do you report bugs and does anyone know of a fix for this?
Is it a bug, per se? Or is it a case where the editor is trying to keep your xhtml compliant?
Out of curiosity, what happens if you go to Options -> Writing and uncheck the option: "WordPress should correct invalidly nested XHTML automatically"?
Same or different behavior?
Bugs to: http://trac.wordpress.org/
I don’t know what the “xmlrpc interface” is or does, but usually you can get around the stripping code problem by disabling the wysiwyg editor and using the normal one.
>> Is it a bug, per se?
If the editor adds a tag attribute and then rips it out then I can’t see that it is anything other than a bug.
>> Out of curiosity, what happens if you go to Options -> Writing and uncheck the option: “WordPress should correct invalidly nested XHTML automatically”?
Its not checked.
The bug only happens, it appears, when I add a post with the WYSIWYG editor. I’ve added a draft post using w.bloggar and then editied it repeatedly and while the editor does indeed modify the HTMl adn moves the tag it does not remove it.
I need to confirm this with another site author who is using ecto on the Mac.
It only removes it, AFAICT, when I use the WYSIWYG editor.
>> I don’t know what the “xmlrpc interface” is or does, but usually you can get around the stripping code problem by disabling the wysiwyg editor and using the normal one.
Well if I’m going to do that then I’ll just not use the web based editor at all as its a bit of a PITA to edit anything other than a small post in the text view of the web based editor.
Well yeah, not to digress but… I’ll agree. I think the wysiwyg thing delivered with 2.x is the devil.
The non-wysiwyg one is tolerable for shorter articles.
Otherwise, I tend to use the Performancing plugin for Firefox or w.bloggar.
Sorry for the digression. 🙂
pixelgeek: yes, it’s all a PITA. For short posts, the plain ol’ plain ol’ works okay (at least for me – I don’t post graphics, music, video etc. – and I have autolinks for links, or in a pinch the quickbutton for links works fine). For longer posts I compose in notepad2, then upload using the plain html interface.
Occasionally, I’ve been known to go into the database to edit a post, depending on situation.
But really, the wysiwyg shipped with 2.0.2 is fair useless.
>> But really, the wysiwyg shipped with 2.0.2 is fair useless.
Is it a new feature or did it just not get tested before the release?
Well, it’s new in the 2.0 branch. As to testing, I couldn’t really say. One assumes things get tested. This has so many bugs, one would equally assume one was wrong….
All I really know about the wysiwyg is that I’ve had the same one on other programs I use, it’s always been a POS, so even if I’d WANTED to use a wysiwyg with WP, I would have given this one a pass.
But that’s just me: while I don’t hand code, I can so I know what’s good coding. The included wysiwyg doesn’t produce good code. One could justify that by saying “it makes posting life SO much easier for those who aren’t web-savvy” or whatever. But since it does just the opposite, it’s a complete bust.
i had say the rich text editor should not be the default option in the blog. it sucks to disable it for new users added to the blog…
It appears that this happens no matter what editor or input method you use as long as the authors are not at least an Editor.
Somewhere in the code the backend strips out attributes from anchors
Is it a bug, per se?
I don’t use the RTE nor am I familiar with it but it’s very likely to be by deliberate design and not a bug at all.
Unless, of course, it deliberately claims to produce non XHTML compliant code, which is pretty unlikely. Keep in mind that in XHTML the target attribute is depreciated and is destined to be as dead as disco one day.
