Ticket #2372 (closed defect (bug): fixed)

Opened 6 years ago

Last modified 5 years ago

<a href= changes to <a xhref= !

Reported by: carnaticwm Owned by: skeltoac
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

  • Owner changed from anonymous to davidhouse

Valid. Weirdest bug ever.

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"

Forgive my terrible TracWiki markup. Sheesh.

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 !

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");

I don't even begin to understand this... where's our resident TinyMCE guru?

  • Owner changed from davidhouse to skeltoac
  • Priority changed from normal to lowest
  • Severity changed from normal to minor
  • Status changed from new to closed
  • Resolution set to wontfix

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.

  • Status changed from closed to reopened
  • Resolution wontfix deleted

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.

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?

  • 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.

  • Status changed from reopened to closed
  • Resolution set to worksforme
  • Milestone set to 2.1

Can't reproduce thsi on trunk anymore

comment:13 follow-up: ↓ 14   intellivision5 years ago

  • Status changed from closed to reopened
  • Version changed from 2.0 to 2.0.4
  • Resolution worksforme deleted
  • Milestone changed from 2.1 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   intellivision5 years ago

  • Version 2.0.4 deleted
  • Severity changed from major to minor
  • Milestone 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" />
  • Status changed from reopened to closed
  • Version set to 2.0.4
  • Resolution set to worksforme
  • Milestone set to 2.1

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   markjaquith5 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   Viper007Bond5 years ago

Replying to markjaquith:

2.0.x still has life left in it.

Oh, well ignore me then. :P

  • Status changed from closed to reopened
  • Resolution worksforme deleted

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.

  • Status changed from reopened to closed
  • Resolution set to fixed

This has been fixed in 2.1.

What was the fix? Is it possible to fix it for the 2.0.x branch without too much difficulty?

It was something in TinyMCE core.

  • Status changed from closed to reopened
  • Version changed from 2.0.4 to 2.0.5
  • Resolution fixed deleted

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.

  • Status changed from reopened to closed
  • Version changed from 2.0.5 to 2.0.4
  • Resolution set to fixed

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.

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.

Note: See TracTickets for help on using tickets.