Posted 6 years ago #
Can anyone think of any reason why worpdress would be removing the target attribute from anchors?
I have a series of posts where we enter 'target="_blank"' in the anchor but after saving it the target attributes are removed.
We've run into this problem using the web based editor as well as the xmlrpc interface
TIA
Posted 6 years ago #
If you're using the wysiwyg, yes, this will happen. Try when needing to add the target attribute disabling the wysiwyg for that post.
Posted 6 years ago #
>> 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
Posted 6 years ago #
>> 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.
Posted 6 years ago #
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?
Posted 6 years ago #
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.
Posted 6 years ago #
>> 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.
Posted 6 years ago #
>> 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. :-)
Posted 6 years ago #
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.
Posted 6 years ago #
>> 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?
Posted 6 years ago #
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.
Posted 6 years ago #
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...
Posted 6 years ago #
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
Posted 6 years ago #
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.
Thus my original post, which had more words after "per se" :-)
Or is it a case where the editor is trying to keep your xhtml compliant?
Posted 6 years ago #
HandySolo: I wasn't trying to correct what you said, I was merely emphasizing it. I think that's exactly what's going on: it's enforcing XHTML compliance.
This topic has been closed to new replies.
