In Firefox 3 there doesn't seem to be a problem, but in IE7, if the Teaser Break button is enabled in TInyMCE when a node is edited all the relative links get converted to absolute links. This applies to at least both "a href" and "img src" links.

Drupal 6.12
Wysiwyg API 2.0 and Wysiwyg API 2.x Dev
TinyMCE 3.2.3.1
IE 7.0.5730.13

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jared12’s picture

Component: Code » Editor - TinyMCE

That's probably what it should be.

greta_drupal’s picture

You just saved me sooooo much additional troubleshooting! Was having this problem and couldn't find the issue. I'm okay with disabling that button (to make IE happy), so a solution at hand.

The "support" team at SourceForge couldn't be bothered to answer a simply question about where to turn on/off URL conversion in TinyMCE code. (They actually answered "I'm too busy to be bothered".)

greta_drupal’s picture

Well, not really. The problem occurs whether or not the Teaser Break button is employed; rather whether a teaser break is inserted. Besides, the absolute links that are created are invalid. Example conversion:

href="MyCleanUrl" --> href="http://mysite.com/node/22/MyCleanUrl" = broken link

jared12’s picture

For me, the problem continues to be related to teaser break button, itself, regardless of whether or not an actual manual teaser break is employed.

For relative links, instead of:

href = "MyCleanUrl"

I include the leading forward slash:

href = "/MyCleanUrl"

This prevents the relative link from being appended to the current URL.

In my case, this works perfectly in Firefox and IE7 as long as the TinyMCE teaser break button is not included in the toolbar, but it gets converted to an absolute link in IE7 if the teaser break button is enabled.

aimutch’s picture

Is this a Wysiwyg problem? I'm having the same problem and it appears to have crept in when I moved from using TinyMCE directly to using the version integrated with Wysiwyg. But this also seems to be a problem in TinyMCE by itself.

http://drupal.org/node/442722 (supposedly resolved but not working for me)

and older report on the same problem:

http://drupal.org/node/133441

idcm’s picture

I was having a similar issue in wysiwyg+fckeditor and believe I found the solution. Some how the "apply_source_formatting" variable got set (I found this in the wysiwyg table in the settings field). I deleted that variable from the database and tada, all fixed. I am not sure what I enabled in fckeditor buttons and plugins to turn that on but that seems to have done the trick. Of course, the editor settings got set back to default but that's okay. I am being careful how I filter by buttons now.

I did some testing on some other sites where wysiwyg + fckeditor is turned on and they weren't having this issue. I don't have access to those databases right now to see if they have that setting so we will have to see.

I saw other issues reported for apply_source_formatting so who knows ...

Just wanted to post what I discovered and this looked like the right place. Hope it helps.

TwoD’s picture

You don't need access to the database to see if a setting makes it to the editor, just use a DOM inspector to look up Drupal.settings.wysiwyg.configs.editorName.format#. Just note that the settings stored in the database have slightly different names to work with the form (they're actually the serialized profile form), and that they're passed through the editor implementation's 'settings callback'-callback before being sent to the client.

In the case of FCKeditor, setting apply_source_formatting (source formatting option below Cleanup and Output) enables the options FormatOutput and FormatSource. It seems more likely that it's actually the Teaser Break plugin which triggers this as it does send the entire contents through jQuery (which in turn uses the browser's methods to serialize and parse the contents). Browsers don't always care about leaving things as relative when they can turn it to an absolute value. Might be a convenience thing on their side for caching or something...

I'm working on a patch for Teaser break for another issue, but it will probably have an effect on this as well. I'll get back here when I have more info.

idcm’s picture

thanks for the update. I will keep watching :-)

idcm’s picture

I am just sharing another observation regarding when unwanted urls appear. Just in case it provides insight into what you are working on.

I have a client who had checked all the boxes in the fckeditor buttons and plugins. He had not checked the Apply source formatting (nor had I). He didn't have the issue of unwanted absolute urls until I unchecked the autogrow option. I had never had autogrow checked.

It just seems to do with changes in the buttons and plugins. I had turned on a button, didn't like it, turned it off and suddenly unwanted absolute urls. Why? I have no clue.

TwoD’s picture

@idcm, thanks for your input.
Some plugins/buttons run code processing content even when they are not explicitly clicked (ie when they just appear to be sitting in the toolbar doing nothing). Teaser Break and Image Assist are examples of this. Those plugins need to check any content going in to or coming out of the editor to see if it contains (or should contain) the placeholder tags used in WYSIWYG mode. I don't think the Autogrow plugin does that tho. The Apply source formatting plugins certainly does this, and in the process of converting the contents to/from some other format (like a DOM tree) the browser can sometimes sneak in between and do some conversions on its own.

TwoD’s picture

Status: Active » Needs review
FileSize
1.86 KB

Would someone like to try the following test patch?
It's a simplification of the code in our TinyMCE implementation which finds elements having the drupal-content class and adds the mceItem class to prevent placeholder images from highlighting the Image button. The patch leaves the old code there for comparison and has some commented logging for Firebug. The patch sacrifices precision to keep the contents away from the browser's influence.

To test this, disable all Drupal plugins like Image Assist, Column Break or others which use the browser's DOM (jQuery) to locate/modify elements, or they will interfere.
Apply this patch.
Then use IE to insert some content which has a mix of relative and absolute href- or src-attributes, disable the editor and make sure the urls are not all absolute.

To use this with Teaser Break, please also apply the other test-patch from #573878: Teaser break causes invalid HTML.

The major difference between this implementation and the previous is which tags it modifies. The old code only adds the mceItem class to img tags having the drupal-content class, while the new code will add it to any element having the drupal-content class. A more complex regular expression could probably achieve the same thing, if needed.

sun’s picture

Status: Needs review » Closed (duplicate)

Although both issues contain valuable information, marking as duplicate of #510552: Invalid XHTML: missing trailing slashes, absolute urls and uppercase tags, as we think that we won't go with the approach of this issue.

You can follow up on that issue to track its status instead. If any information from this issue is missing in the other issue, please make sure you provide it over there.

vicorock’s picture

Thanks so much. Turning off the "Teaser Break" function worked like a charm. You've saved me hours of troubleshooting time!

timwood’s picture

I'm still experiencing this issue even with Teaser Break disabled. Any other suggestions on how to fix this issue? It's a real problem because at my organization most users are required to use IE and we don't want absolute links sneaking into our site content. I think I remember testing with CKEditor as well and still having the problem. Can someone recommend which "buttons and plugins" or "cleanup and output" options I might disable from the list below so I can get rid of the problem with links in IE?

  • TinyMCE 3.3.2
  • Wysiwyg 6.x-2.1
  • IMCE Wysiwyg bridge 6.x-1.1
  • IMCE 6.x-1.3
  • TinyMCE Node Picker 6.x-2.1 (this is going to be replace with Nodepicker once stable)
  • Path, Pathauth 6.x-1.3, Path redirect 6.x-1.0-beta6, Global Redirect 6.x-1.2
  • Link checker 6.x-2.4
  • jQuery Update 6.x-1.1
  • Affected browsers: IE 7, IE 8

Enabled buttons/plugins:

  • Node Picker
  • Table
  • IMCE
  • HTML block format
  • Inline popups
  • Fullscreen
  • Auto save
  • Remove format
  • Clean-up
  • Source code
  • Horizontal rule
  • Help
  • And a bunch of others.

Enabled Cleanup and output:

  • Verify HTML
  • Convert tags to styles
  • Remove linebreaks
  • Force cleanup on standard paste

Thanks,
-Tim

jared12’s picture

I've moved to CKEditor since I originally posted this issue, but it had the same problem.

I just applied this patch and it seems to have resolved the issue.

Drupal 6.16
Wysiwyg 6.x-2.1
CKEditor 3.2.1.5372
IE 7.0.5730.13

timwood’s picture

I was able to use the latest 3.x development release of Pathologic to "correct" the absolute path issue we were seeing with TinyMCE+WYSIWYG & IE7/8. Pathologic has a feature in 3.x to change all URL's to relative, you just provide it with all the possible host aliases a particular Drupal site will run at and it will change the URL's via the input filters.

-Tim

loopduplicate’s picture

But this means that rss feeds will only contain relative paths too, right? So if we want an rss feed on our page, this solution won't work, as far as I can tell.

From FCKEditor's help text in Drupal 6 under the configure tab of an input filter with pathologic enabled:
"
Output full absolute URLs
If checked, Pathologic will output full absolute URLs, with a protocol and server fragment (such as http://example.com/foo/bar); this is useful if you want images and links to not break for those reading the content in a feed reader or through some other form of aggregation. However, in cases where the site is being served via both HTTP and HTTPS, it may be necessary to uncheck this box so that protocol and server fragments are omitted in the paths Pathologic creates (such as /foo/bar) to avoid issues where the browser complains about pages containing both secure and insecure content.
"

timwood’s picture

loopduplicate,
You are correct. We recently discovered this problem with the feed and have yet to come up with a solution. In one site we've stopped allowing users to manage/insert images in the body of the content and only allow images via imagefield, which is better for standardizing image format and other things. This allows Drupal to generate the correct path every time. This still leaves a problem with links places into the body.

I was thinking a possible solution for adding the protocol and server fragment back to the RSS feed would be another module (yet to be written from what I can tell) that would only affect the RSS output of content. Even on a rather busy site I'd imagine the feed content is less accessed and therefore might not suffer from being excluded from drupal caching...

Our solution for now is publish the partially broken feed (although Google Reader corrects the links based on the site) and have users manage content with Firefox. :-(

robbyahn’s picture

Version: 6.x-2.0 » 7.x-2.2
Component: Editor - TinyMCE » Editor - CKEditor

CKeditor 4.0 has same issue.
I just untick (disable) the teaser break componenet.