TinyMCE converts relative links incorrectly (adds wp-admin)

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.

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.

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.

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.

2.

// URL conversion settings 
if ( get_option('use_balanceTags') ) {
 	$initArray['convert_urls'] = true;
 	$initArray['relative_urls'] = false;
} else {
 	$initArray['convert_urls'] = false;
}

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.

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?

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.

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.

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.

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.