I have been using TinyMCE for a while now, and recently tried to update the TinyMCE libraries on a site I manage from 2.0RC1 to 2.0.1. I noticed that after the upgrade, if I went in and edited any node with an internal realtive link in it, such as ?q=node/33, it would become ../?q=node/33 or /?q=node/33 in the editor. Also, any links with a tilde in them have the tilde replaced by %7E. These problems do not appear while using TinyMCE module 4.6 and TinyMCE library 2.0RC1. Is there a fix for this? I am using Firefox 1.5 and the server is using Red Hat Enterprise Linux 3/Apache2/PHP 4.3/MySQL 4.

Comments

wslntheline’s picture

Component: Miscellaneous » User interface
Category: bug » support
Priority: Normal » Critical

Sorry to bump this, but it an issue I'd like to fix because there are features that I need in the new TinyMCE Library version. Is this the wrong place to post this?

wslntheline’s picture

Guess I'm going to start looking elsewhere for an editor.

veelo’s picture

I am running into this problem too, on Drupal 4.7.0-beta4. We need to fix this.

Bastiaan Veelo.

veelo’s picture

Relative URLs should work when you can use clean URLs, and skip the ?-mark. Unfortunately, our server does not support mod-rewrite yet.

Could this be related to node/42129, node/34110 and node/23182?

I will look into these switches.

Bastiaan Veelo.

veelo’s picture

Here is a workaround that prevents "?q=" to turn into "/?q=" in relative links, assuming your Drupal theme is a phptemplate one, say drupal/themes/mytheme:

1) Create the file drupal/themes/mytheme/template.php if it does not exist already.

2) Add the following function to drupal/themes/mytheme/template.php.

<?php
/**
  * Catch the theme_tinymce_theme function from tinymce.module, and reimplement it.
  */
function phptemplate_tinymce_theme($init, $textarea_name, $theme_name, $is_running) {
  // New stuff:
  //$init['convert_urls'] = 'false';
  $init['relative_urls'] = 'false';

  // The rest is just pasted contents of tinymce.module:theme_tinymce_theme():
  switch ($textarea_name) {
    // Disable tinymce for these textareas
    case 'log': // book and page log
    case 'img_assist_pages':
    case 'caption': // signature
    case 'pages':
    case 'access_pages': //TinyMCE profile settings.
    case 'user_mail_welcome_body': // user config settings
    case 'user_mail_approval_body': // user config settings
    case 'user_mail_pass_body': // user config settings
    case 'synonyms': // taxonomy terms
    case 'description': // taxonomy terms
      unset($init);
      break;

    // Force the 'simple' theme for some of the smaller textareas.
    case 'signature':
    case 'site_mission':
    case 'site_footer':
    case 'site_offline_message':
    case 'page_help':
    case 'user_registration_help':
    case 'user_picture_guidelines':
      $init['theme'] = 'simple';
      foreach ($init as $k => $v) {
        if (strstr($k, 'theme_advanced_')) unset($init[$k]);
      }
      break;
  }

  // Add some extra features when using the advanced theme.
  switch ($theme_name) {
    case 'advanced':
      //$init['extended_valid_elements'] = array('a[href|target|name|title|onclick]');
      break;
  }

  // Always return $init; !!
  return $init;
}
?>

I have not checked the thilde thing you reported, but you can experiment with other tinymce options in the same way. Maybe the "convert_urls" that is uncommented above will help.

Regards,
Bastiaan Veelo

wslntheline’s picture

Thanks for the help. I'll hve to try this when I get a break from my College studies. I'll be sure to post a follow-up.

m3avrck’s picture

Please try adding these to your _tinymce_theme():

$init['document_base_url'] = "base_path()";

Base URLs in Drupal have recently changed, I believe this will fix it. If you guys can test and confirm I'll commit the fix. Note, you don't need $init['relative_urls'] = 'false'; ... that actually won't fix the problem at the root. Just add the above and please let me know, thanks!

m3avrck’s picture

Ooops, didn't realize this was already in CVS! But the code was wrong because Drupal HEAD recently changed, should be working now. Please test and verify, thanks!

veelo’s picture

Yes, the single line $init['document_base_url'] = "base_path()"; works as advertised by you --- in Drupal 4.7.0-beta4.
I thought I had seen relative_urls working as it should, but later I noticed it prepended the absolute path.

Thank you for the correct fix.

Bastiaan

PS I also like $init['remove_linebreaks'] = 'false'; and $init['apply_source_formatting'] = 'true';It may be worth to have these be the default. What do you think?

veelo’s picture

Sorry to post out of topic, but it seems remove_linebreaks and apply_source_formatting do not go well together. When combined you get extra empty lines upon each editing. I am going with remove_linebreaks only.

Bastiaan Veelo.

Wesley Tanaka’s picture

relative_urls = 'false' is necessary if you ever use tinymce to store content that might possibly show up in two different paths. I think that's pretty common if clean URLs are on.

Let's say I have a drupal site rooted at http://example.com/ (i.e. not in a subdirectory)

I create a forum topic (node 45795) with TinyMCE, and within that topic, a link to "/node/123". TinyMCE decides that should be converted to just "123".

From /node/45795, "123" expands to /node/123, and all is good.

Now I promote the forum topic to the main page, and the link shows up in the snippet. But the main page is http://example.com/ (or http://example.com/node). From this context, "123" gets expanded to "/123" which is incorrect.

Thus it would be nice if relative_urls = false were set as the default.

m3avrck’s picture

wtanaka, I'm not sure I understand your logic.

relative_urls is set to TRUE by default through TinyMCE: http://tinymce.moxiecode.com/tinymce/docs/option_relative_urls.html

All of these URLs are relative to document_base_url: http://tinymce.moxiecode.com/tinymce/docs/option_document_base_url.html

Which is set to base_path(). This is how all of the links in Drupal currently work, relative to this path.

If relative_urls was set to false, everything would be saved as an absolute URL. If you ever try to change your URL or your site structure, you'll have lots of broken links.

As such, it doesn't make sense to set this to false as a default.

I tested quite a few examples with clean URLs enabled and disabled and I have no problem with making links such as 'node/1' and so forth, indepedent of how many folders down.

Wesley Tanaka’s picture

Perhaps I should have been more concrete.

1. Turn on clean URLs.
2. Create a new "story" node. Edit the body with tinymce. As the body's entire content, make the link [a href="http://example.com/node/12345"]fish[/a]
3. Check the checkbox to promote the node to the front page.
4. Save the node.

Now I believe with relative_urls turned on, if you go inspect the content of the database, you'll see that the node contains the body [a href="12345"]fish[/a]

Let's say that the node you just created is "23456"

5. Go to http://example.com/node/23456. Click on the fish link. All is well.
6. Go to the home page http://example.com/. Click on the fish link (since 23456 has been promoted to the home page, it should show up just fine). You get taken to a page that doesn't exist.

m3avrck’s picture

Status: Active » Fixed

wtanaka, you are indeed right. I tried the latest 2.0.4 libraries and got a few erradict results following your tests.

I set relative_urls = false and it seemed to fix things.

However, the surprising thing, relative_urls = false does *not* produce truly absolute urls of the form http://www.example.com/sub/dir/node/1 but rather /sub/dir/node/1 , which is exactly what it should have been doing.

Strange, I've emailed Johan (creator of TinyMCE) to make sure this indeed the case and to update the docs accordingly.

Also, patch has been committed.

Thanks!

Wesley Tanaka’s picture

There's a separate setting, though I forget what it's called, that controls whether or not the domain part of the url is stripped if it's identical to the domain that tinymce is being served from.

m3avrck’s picture

Right I thought there was, perhaps that has changed because I have tried relative_urls before and I didn't get results like this.

I've followed up with Johan though, to get to the root of this and make sure we have the best compatible URLs with the rest of the Drupal.

Thanks again!

Anonymous’s picture

Status: Fixed » Closed (fixed)