#2372 closed defect (bug) (fixed)
<a href= changes to <a xhref= !
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | normal | Milestone: | 2.1 |
| Component: | General | Version: | 2.0.4 |
| Severity: | minor | Keywords: | |
| Cc: |
Description
Greetings,
version.php contains
$wp_version = '2.0.1';
$wp_db_version = 3437;
At post.php
1) type <a href=
2) click HTML
3) CANCEL
4) the <a href=" has changed to <a xhref=" !
Why ???
Cheers, Kishore.
Change History (24)
comment:1
davidhouse — 7 years ago
- Owner changed from anonymous to davidhouse
Definitely valid. Definitely the Wierdest bug ever. A few points:
# I don't understand why someone would be typing <a href= into the visual editor in the first place and then clicking the HTML button. These circumstances seem so unrealistic.
# If you enter the full tag
<a href="http://wordpress.org>WordPress</a>
, click the "HTML" button, and click "Update" button from the HTML editor, TinyMCE saves the proper "href" instead of "xhref"
comment:4
carnaticwm — 7 years ago
wantmoore states "I don't understand why someone would be typing <a href= into the visual editor in the first place and then clicking the HTML button. These circumstances seem so unrealistic."
ah. i should have explained the background
even though i like the visual editor... it is faster to type the html sometimes instead of the mark and link etc.
this definitely worked some days/weeks ago and no more !
if i type the entire html for creating a text with link and save... it is xhref in the post and it doesnot work as expected !
i donot type the fragment and click on html. that was just the shortest way to reproduce the issue !
comment:5
markjaquith — 7 years ago
mark-jaquiths-powerbook-g4-15:~/sites/wp mark$ grep -iR 'xhref' *
wp-includes/js/tinymce/.svn/text-base/tiny_mce.js.svn-base: h = h.replace(/\shref=/gi, " xhref=");
wp-includes/js/tinymce/.svn/text-base/tiny_mce.js.svn-base: if (h.indexOf(' xhref') != -1) {
wp-includes/js/tinymce/.svn/text-base/tiny_mce.js.svn-base: var xhref = tinyMCE.getAttrib(n[i], "xhref");
wp-includes/js/tinymce/.svn/text-base/tiny_mce.js.svn-base: if (xhref != "") {
wp-includes/js/tinymce/.svn/text-base/tiny_mce.js.svn-base: n[i].href = tinyMCE.convertRelativeToAbsoluteURL(tinyMCE.settings['base_href'], xhref);
wp-includes/js/tinymce/.svn/text-base/tiny_mce.js.svn-base: n[i].removeAttribute("xhref");
wp-includes/js/tinymce/tiny_mce.js: h = h.replace(/\shref=/gi, " xhref=");
wp-includes/js/tinymce/tiny_mce.js: if (h.indexOf(' xhref') != -1) {
wp-includes/js/tinymce/tiny_mce.js: var xhref = tinyMCE.getAttrib(n[i], "xhref");
wp-includes/js/tinymce/tiny_mce.js: if (xhref != "") {
wp-includes/js/tinymce/tiny_mce.js: n[i].href = tinyMCE.convertRelativeToAbsoluteURL(tinyMCE.settings['base_href'], xhref);
wp-includes/js/tinymce/tiny_mce.js: n[i].removeAttribute("xhref");
comment:6
markjaquith — 7 years ago
I don't even begin to understand this... where's our resident TinyMCE guru?
comment:7
davidhouse — 7 years ago
- Owner changed from davidhouse to skeltoac
- Priority changed from normal to lowest
- Severity changed from normal to minor
- Resolution set to wontfix
- Status changed from new to closed
TinyMCE uses xhref as a temporary attribute in order to work around a Mozilla bug.
If there is realistic scenario where this causes a problem to a WordPress user, reopen. Otherwise, please submit your bug report to the TinyMCE project at Sourceforge.
- Resolution wontfix deleted
- Status changed from closed to reopened
I think this bug seems to create broken links for a Debian user.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367001
It creates useless links for me too.
I think it is because of the "rich editor". This bug doesn't exist with the rich editor off.
comment:10
skeltoac — 7 years ago
hendry: what version of WP are you using? If not latest, please test with latest because this issue has been addressed. If still a problem with latest, what steps to replicate?
comment:11
hendry — 7 years ago
- Priority changed from lowest to normal
- Severity changed from minor to major
I just tried 2.0.3 and the problem still exists with the "Rich text" interface!
I've received so many complaints about the "Rich text" interface that I don't want it in default wordpress installs.
comment:12
Nazgul — 7 years ago
- Milestone set to 2.1
- Resolution set to worksforme
- Status changed from reopened to closed
Can't reproduce thsi on trunk anymore
comment:13
follow-up:
↓ 14
intellivision — 7 years ago
- Milestone changed from 2.1 to 2.0.4
- Resolution worksforme deleted
- Status changed from closed to reopened
- Version changed from 2.0 to 2.0.4
Happens to me and my contributors of my WP install. WP 2.0.4, Firefox 2.0.
type
<img src="http://mail.google.com/mail/help/images/logo1.gif" />
you get
<img xsrc="http://mail.google.com/mail/help/images/logo1.gif" />
comment:14
in reply to:
↑ 13
intellivision — 7 years ago
- Milestone 2.0.4 deleted
- Severity changed from major to minor
- Version 2.0.4 deleted
Replying to intellivision:
Happens to me and my contributors of my WP install. WP 2.0.4, Firefox 2.0.
type
<img src="http://mail.google.com/mail/help/images/logo1.gif" />you get
<img xsrc="http://mail.google.com/mail/help/images/logo1.gif" />
comment:15
Viper007Bond — 7 years ago
- Milestone set to 2.1
- Resolution set to worksforme
- Status changed from reopened to closed
- Version set to 2.0.4
2.0.4 is old (please use the latest version) and the 2.0.x line will be seeing no more releases as far as I know.
In 2.1, this is not an issue as there is no more HTML button. Closing, please don't reopen.
comment:16
follow-up:
↓ 17
markjaquith — 7 years ago
2.0.x still has life left in it. Re-open only if this can be recreated in 2.0.5
comment:17
in reply to:
↑ 16
Viper007Bond — 7 years ago
comment:18
bertilow — 6 years ago
- Resolution worksforme deleted
- Status changed from closed to reopened
I was just bit by this bug in WP 2.0.5 (at "http://lingvakritiko.com"). I was flabbergasted. I will now try to turn off the Rich Editor for all users. This bug most definitely has life in it.
comment:19
matt — 6 years ago
- Resolution set to fixed
- Status changed from reopened to closed
This has been fixed in 2.1.
comment:20
markjaquith — 6 years ago
What was the fix? Is it possible to fix it for the 2.0.x branch without too much difficulty?
comment:21
matt — 6 years ago
It was something in TinyMCE core.
comment:22
lawfont — 6 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
- Version changed from 2.0.4 to 2.0.5
I've just been bitten by it - user editing in rich text mode all the way. No use of "html button" at all.
WP version is 2.0.5.
So long as this version remains the latest stable version, the ticket should remain open, and the fix applied for 2.1 should be migrated across to 2.0.5. If nothing else, could you point out what the fix to TinyMCE was, so I can make it myself if need be. Thanks.
comment:23
Viper007Bond — 6 years ago
- Resolution set to fixed
- Status changed from reopened to closed
- Version changed from 2.0.5 to 2.0.4
The fix was upgrading all of TinyMCE (as the problem wasn't WordPress related), which I believe we don't want to do in WP 2.0.x for a number of reasons.
comment:24
markjaquith — 6 years ago
If a TinyMCE upgrade is outside of 2.0.x's scope (and I think that it is), we could fix this on the PHP side...
$content = str_replace('<a xhref=', '<a href=', $content);
It's a band-aid, but if TinyMCE isn't going to be upgraded, it may be a necessary band-aid.

Valid. Weirdest bug ever.