WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#6737 closed defect (bug) (worksforme)

TinyMCE converts relative links incorrectly (adds wp-admin)

Reported by: Otto42 Owned by: azaozz
Milestone: Priority: high
Severity: critical Version: 2.5
Component: TinyMCE Keywords: 2nd-opinion has-patch
Focuses: Cc:

Description

TinyMCE has a feature that auto-converts relative links to absolute ones. This is a good thing for WordPress, since anybody using non-default permalinks needs this feature for their links to work.

The problem is that TinyMCE in 2.5 is converting all the relative links as if they are in the wp-admin path. This is breaking image insertion as well, for some people.

The root cause is the lack of a defined "document_base_url" setting. When TinyMCE cannot find one, it uses the current url of the page it's in, which happens to be the write page in wp-admin.

Possible, but untested, fix is to add this to the tiny-mce-config.php file:

'document_base_url' => get_option('url'),

This should set the site root as the correct base and allow it to convert the relative links correctly, as the user would expect it to convert them.

Attachments (1)

base-url.patch (1.2 KB) - added by azaozz 6 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 ryan6 years ago

  • Owner changed from anonymous to azaozz

comment:2 azaozz6 years ago

Another option is to add

'convert_urls' => false,

which would keep the URLs as entered. That was the setting in TinyMCE 2.x, but had to be changed as it wasn't working well with the "media" plugin. However since the last update to TinyMCE 3.0.7, it's working as expected.

So the question is: shall we force absolute URLs that will prevent them from breaking when custom permalinks are used (although a few users would complain about TinyMCE/WordPress changing their links), or shall we let the users enter any type of URL despite that it may break if permalinks are changed.

comment:3 Otto426 years ago

Another possibility: Hook it to a setting. The "WordPress should correct invalidly nested XHTML automatically" seems to apply here. If they have that turned off, then it would not adjust the urls at all. If they have it turned on, it would make them absolute.

Regardless of that, the document base needs to be set to make it work correctly. As it stands now, that's causing the wp-admin insertion resulting in invalid links most of the time.

comment:4 azaozz6 years ago

  • Keywords has-patch added

Yes, that seems to be the best solution: if balance_tags is on, URLs will be made absolute too, if not, they will be left as-is.

comment:5 azaozz6 years ago

  • Keywords needs-testing removed

azaozz6 years ago

comment:6 follow-up: Otto426 years ago

That patch would work, but seems a bit odd to me. I think this makes more sense:

  1. 'document_base_url' => get_option('url') should be in the TinyMCE initArray all the time. It doesn't make sense that this is set wrong, ever.
  1. // URL conversion settings 
    if ( get_option('use_balanceTags') ) {
     	$initArray['convert_urls'] = true;
     	$initArray['relative_urls'] = false;
    } else {
     	$initArray['convert_urls'] = false;
    }
    

comment:7 in reply to: ↑ 6 azaozz6 years ago

Replying to Otto42:

That patch would work, but seems a bit odd to me. I think this makes more sense:

  1. 'document_base_url' => get_option('url') should be in the TinyMCE initArray all the time. It doesn't make sense that this is set wrong, ever.

...

Unfortunately it's more complicated than that. If set, 'document_base_url' affects not only what's entered in the Link and Image popups, but all URLs used by the editor.

I've tested it quite a bit and it seems to work well with the current version, but it had some problems few weeks ago, especially when 'document_base_url' is different than the baseURL setting passed to the editor before init (baseURL refers to the installation directory and can be https:// too).

Also TinyMCE's documentation suggests that "document_base_url" should only be used when "relative_urls" is set to true:

This option is only used when the relative_urls option is set to true.
...
This (document_base_url) may affect how other paths are interpreted, such as 
calls to tinyMCE.windowManager.open, so you may want to use absolute paths.

Since we have "relative_urls" set to false, "document_base_url" may behave unexpectedly in some circumstances and the combination

'convert_urls' => false,
'relative_urls' => false,
'document_base_url' => get_option('siteurl'),

is not recommended.

I was reluctant to make this patch in the first place, but it seems to work well in the current (3.0.7) version. However we should avoid setting 'convert_urls' => false, together with 'document_base_url'. They both affect the way TinyMCE recalculates the URLs that come from the browser (each browser interprets and corrects the URLs internally a bit different).

Another possibility would be to pre-fill the site URL in the Image popup, similar to how "http://" is pre-filled in the Link popup.

Yet another possibility would be to make a small plugin to easily control all these settings, as the users that want to use the (not recommended) relative URLs seem to be just a few. That way they would be able to turn these settings on, test them and eventually turn them off if something doesn't work well.

comment:8 follow-up: lloydbudd6 years ago

Otto42, can you provide steps to reproduce the problem y'all are discussing?

Off hand it seems like a stretch to lump this into "correct invalidly nested XHTML automatically". What is invalid about the XHTML?

comment:9 in reply to: ↑ 8 ; follow-up: Otto426 years ago

Replying to lloydbudd:

Otto42, can you provide steps to reproduce the problem y'all are discussing?

Sure. Create a non-root relative link in a post. Like href="bobs/yer/uncle". TinyMCE will convert it into href="http://example.com/blog/wp-admin/bobs/yer/uncle", when you really wanted href="http://example.com/blog/bobs/yer/uncle".

This gets a lot of confused users on the support forums, who complain that it used to work correctly. Admittedly, they should not be using relative links in the first place, because with pretty permalinks those are unreliable to begin with, however if TinyMCE is going to convert those to full links, it should at least make a better guess about it than assuming the files are in the wp-admin directory.

Off hand it seems like a stretch to lump this into "correct invalidly nested XHTML automatically". What is invalid about the XHTML?

I agree that it is a stretch. The XHTML is valid, but the resulting link itself is not. But I don't think that it's worth adding another option. The idea behind using that option is that you're basically giving permission to "fix up" your invalid posts, and if you turn it off, then most likely you want it to leave your (potentially broken) relative links alone.

comment:10 in reply to: ↑ 9 azaozz6 years ago

Replying to Otto42:

Replying to lloydbudd:

Otto42, can you provide steps to reproduce the problem y'all are discussing?

Sure. Create a non-root relative link in a post. Like href="bobs/yer/uncle". TinyMCE will convert it into href="http://example.com/blog/wp-admin/bobs/yer/uncle", when you really wanted href="http://example.com/blog/bobs/yer/uncle".

That used to be the case in 2.5. In 2.5.1 TinyMCE leaves all links as is.

comment:11 Otto426 years ago

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

Well, 2.5.1 was not out when I reported this issue.

So did this get fixed then? What patch fixed it? Why is this still open?

Closing.

comment:12 Viper007Bond6 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:13 Viper007Bond6 years ago

  • Milestone 2.5.2 deleted
  • Resolution set to worksforme
  • Status changed from reopened to closed

comment:14 azaozz6 years ago

I think it wasn't closed because it refers to the bigger question how to handle relative URLs in WordPress and because the current solution is still not perfect.

For example, when pasting a link from the current domain with Firefox, the browser "corrects" it and pastes a malformed relative URL, regardless of what the original link is (seems like a long standing bug in FF).

That cannot be fixed with the current settings in TinyMCE (FF2 also lacks onpaste support), but perhaps we can have a new ticket for this specific problem.

Note: See TracTickets for help on using tickets.