The problem that I was having was that I have a development site running in /drupal/ on my dev server. Whenever I inserted links then Tinymce would put the link as /drupal/files/file_i_am linking_to. Or with relative URLs enabled then it would added drupal/files/file_i_am linking_to (no beginning /).

This would be fine except if I am editing a page with the URL "mysite.com/drupal/some_category/some_page" then the link would either be :

mysite.com/drupal/files/file_i_am linking_to (valid link)

OR

mysite.com/drupal/some_category/some_page/drupal/files/file_i_am linking_to (invalid link)

The problem with the valid link is that I will be moving my site out of the drupal folder for the production server and all of the pages I have created link to mysite.com/drupal/files/etc.... instead of mysite.com/files/etc.

I found a lot of help from this discussion -- http://drupal.org/node/32320

I have ultimately resolved my issue and just wanted to post the changes I have made. This is working on my site and I have not tested it with clean urls disabled.

Edit the file "tinymce.module" in "sites/all/modules/tinymce/tinymce.module"

Starting on line 493, change the following code:

$init['relative_urls'] = 'false';
$init['document_base_url'] = "$host";

Replace it with:

$init['relative_urls'] = 'true';
$init['document_base_url'] = $_SERVER['HTTP_REFERER'];
$init['convert_urls'] = "false";

This change tells tinymce to use relative urls. The HTTP_REFERER variable will get the clean url of the page you are editing when you click the Edit link on your page instead of somthing like /node/58/edit (which is what the URL looks like on a page in Edit mode). The convert_urls flag tells tinymce not to mess with urls that are already in your page.

This allows you to use relative links everywhere, even to other pages on your site. So if you are editing the page mysite.com/some_category/some_page and you want to link to mysite.com/some_category then you can insert a link pointing to "../some_category" instead of the absolute path to the file.

I hope this helps anyone who was having the problems I had to sort through.

CommentFileSizeAuthor
#2 tinymce_rel_url_0.diff766 bytesGoofyX
#1 tinymce_rel_url.diff766 bytesGoofyX

Comments

GoofyX’s picture

GoofyX commented
StatusFileSize
new tinymce_rel_url.diff766 bytes

Nice work rickymuggs.

Here's the patch to the proposed change. TinyMCE must work with relative urls. I've been developing a 5.1 site locally at my PC and after I transfered it to the production server, the urls would not work, because they were all absolute. Your changes made TinyMCE work the way it should with the urls.

Just a point to remember is that when creating urls (through TinyMCE) that begin with / (e.g. /path/to/my/link), then only the last portion is kept (link). So, when creating urls, do not include any leading / (path/to/my/link will work fine).

GoofyX’s picture

GoofyX commented
StatusFileSize
new tinymce_rel_url_0.diff766 bytes

I'm sorry, there is a typo in my patch. This is the right one.

Also, after applying the (correct) patch, I see that the behaviour with the leading / is different now (TinyMCE keeps the link as is), so please disregard my last comment about the leading /. Sorry. :-(

kreynen’s picture

kreynen commented

I'd like to get feedback from more people about this including this.

I tend to modify my local host file (hackers DNS!) and set up virtual hosts in Apache when I'm working on my laptop or a development server so my local/dev directory structure mirrors the site the work is going to end up on. I understand that not everyone can/wants to do this when developing.

What's the downside of this approach to relative URLs?

GoofyX’s picture

GoofyX commented

kreynen, one solution is to develop the site the way you describe, but for a lot of people, and for me I guess, it's easier to develop in their account (/~ notation) and then transfer the site to the production server. Think of the case when you have the site at http://www.mysite.com and for some reason you want to transfer it to a subdirectory, eg. http://www.mysite.com/oldsite. In this case, the above scenario fails.

Why not make this a module option? It would be the simpler (and "diplomatic") solution of all (and make default the current option).

kreynen’s picture

kreynen commented

Just to be clear, I'm not against this. I've just never needed it. If I was moving from www.mydevsite.com to www.myrealsite.com/drupal I would update the links in all the body copy of all the nodes with some php and a regular expression.

I tend to default to Moxie's judgment since they've probably seen it all and decided to make this the relative_urls/document_base_url/remove_script_host the default configuration for a reason.

If this was an option, what exactly would the option be called? Use Clean URL from pre-edit referer and do not change other URLs? Yes/No

GoofyX’s picture

GoofyX commented

Just to be clear, I'm not against this. I've just never needed it. If I was moving from www.mydevsite.com to www.myrealsite.com/drupal I would update the links in all the body copy of all the nodes with some php and a regular expression.

Yes, but this could be dangerous.

To be honest, I've never read TinyMCE's FAQ. As far as I'm concerned, the best solution is to give the user an option, so that he could select the behaviour himself. For example (select box):

URL conversion options:

  • Relative URLs (This will convert all URLs within the same domain to relative URLs. The URLs will be relative from the document_base_url.)
  • Absolute URLs (This will convert all relative URLs to absolute URLs. The URLs will be absolute based on the document_base_url.)
  • Domain Absolute URLs (This will convert all relative URLs to absolute URLs. The URLs will be absolute based on the document_base_url with domain.)
  • No URL Conversion (This option will preserve the URLs as they are in a separate attribute while editing, since browsers tend to auto convert URLs.)

This could be a set of options relating to TinyMCE's behaviour for URLs (some examples could also be included so that the user could better understand what each option means). The FAQ is pretty explanatory (thanks for pointing this out!).

What do you think?

kreynen’s picture

kreynen commented

It seems reasonable. The semester is over so I'm going to have time to implement some changes to TinyMCE that I have been using in my projects. Some of these are big... JQuery support, Expert (non GUI) configuration, check for print $scripts in the theme, and possibly including TinyMCE itself in the module (no more 2 step install). IMHO, including TinyMCE with support for all valid XHTML would clear up a lot of the confusion between Drupal's input filters and TinyMCE's supported elements. I've been configuring TinyMCE to allow everything and doing all filtering with Drupal. While this wouldn't work for other CMSes that use TinyMCE, it works for Drupal.

I slogged through ALL of the issues in the TinyMCE project queue during OSCMS and found several reoccurring issues. Some had fixes that were never included. Others looked they might be even hard to solve if we rolled in some of Nedjo's patches. I held off on doing anything until I had some idea of what the solution for the Top TinyMCE Issues were. m3avrck recently rolled in several suggested patches into the Development Snapshot including fixes for source formatting, tokens in path to custom CSS, localization, converting fonts to styles, install issues, compressor working, instructions for CSS file, and not honoring #resizable.

It is really rare that something with an easy fix like this wouldn't have come up before now. I just keep thinking there must be a downside to this, but I'm not seeing it.

emdalton’s picture

emdalton commented

I'm looking forward to this fix (assuming there isn't an unexpected downside). We just migrated from a test server to what we hope will be our permanent server and I'm having to go in and manually edit every TinyMCE-formatted link on the site. :( Since another move could happen at any time, I'm hoping this will be fixed before then... and that the fix will be smart enough to update all pages as they are edited.

Any kind soul who'd like to provide a utility to strip out the absolute url prefix from all our pages would be heaped with blessings, as well. :)

(Meanwhile, I'm going to try to see if I can construct a filter to do this.)

emdalton’s picture

emdalton commented

If you need to edit all existing nodes to remove the absolute portions of paths, etc, try the suggestion here: http://drupal.org/node/135396

GoofyX’s picture

GoofyX commented

What's the status of this bug? Today, I again came across to the relative/absolute links problem and I had to look in the site for a solution...

pomliane’s picture

pomliane commented
Status: Active » Closed (won't fix)

This version of TinyMCE is not supported anymore. The issue is closed for this reason.
Please upgrade to a supported version and feel free to reopen the issue on the new version if applicable.

This issue has been automagically closed by a script.