TYPO3 Core

Bug confirmed by me.

Any other workaround excepting external links?

The situation is absolutely the same if using RealURL...
Maybe, it is core problem?

Well, suppose you have three sites in one tree. One site uses simulateStatic, another - realurl, third - nothing. How to generate links from one site to another? It will require parsing TS setup for that another site. Thus core chooses easy way: generate "?id=" links.

To Dmitry Dulepov:
this way will require additional parsing even if all three sites have realurl.
And in this case the easy way doesn't mean the best way. Yes, additional pasing, so what? it will happen only one time till next "clear cache".

it is SEO issue and it is very important.

It is easy only until someone needs to make a patch :)

There are many important issues. Use external links for now if it is so important. Or make a patch.

Using of "id"s is the easiest solution, but stultify’s the feature simulate static in multi-domain installations.

On my sites all trees and domains use shared setup with
config.typolinkCheckRootline = 1
config.simulateStaticDocuments = 1

IMHO in this case using of "id"s doesn’t simplifies significantly the core, but vastly complicates my job.

"It is easy only until someone needs to make a patch :)"

i knew that you will say it :)

Maybe not so important, but still:

IMO, it is not very likely that someone having 1 TYPO3 installation serving few domains would use different methods for building URLs. It would be or RealURL, or simulateStatic, or none. Don't think someone would combine these technologies for different domains.
And post of hygro above only prove this...

Even if thing seems obvious to fix, it is usually not so in typo3. Usually many things should be taken into account such as workspaces, hidden/deleted flags, permissions for FE users, etc. So to generate such URL properly, typo3 must temporarily switch to the context of that site. It will almost double amount of executed sql queries and impact performance.

I am sure that this bug should (must?) be fixed, I just do not know any simple way to do it.

Since theorectically it is possible to use all these techniques in one tree, it has to be considered. typo3 does not make weak assumptions, it is not phpNuke like ;)

I did not suggested just to presume something. Of course, agree that config from another domain should be analysed.

Concerning easy solition - isn't it possible to implement following: when building such cross domain link, force engine to "think" that we are actually building local link with in the context of target domain. Then it would use correspondent technic to build it (RealURL or simulateStatic or nothing depending on configuration) as it usually does with internal links. And then add domain name to finish link.
Could it be implemented in such way, how do you think?

It will produce wrong url if another domain uses different linking method. Link generation must be done in the context of another site...

Misunderstanding: I've wrote "with in the context of target domain", so in the context of "final point" of the link...

Reread this: http://bugs.typo3.org/view.php?id=3491#19428

the problem for me is, as i am using the same domain and only subdomains, the rte cuts away the domain name on external links.
that means en.test.com/abc.html -> abc.html and will be opened on de.test.com/abc.html where there is no such file.
therefore i can only add correct links using plain html and that is really painful

keyword:t3dd06

Klauss, I am not sure but it can be either rte or separate core bug.

Klaus, could you please have a look at whether the domain-name is cut off after saving in the RTE or only when displaying (i.e., is the domain-name still visible in RTE-source-code after saving)?

This could at least give us a hint where to search for the bug (I don't have a similar situation somewhere so I can't test it by now).

the domain name is cut off by the rte as far as i can remember. that's why the only working workaround is to disable the rte / use a html field

can somebody give me a hint, where the corresponding line of code is (that does not use realurl / simulate static documents to create the link)

Klaus, for typo3 4.0.0 it's in typo3/sysext/cms/tslib/class.tslib_content.php, around line 5230:

$this->lastTypoLinkUrl = $this->URLqMark('http://'.$tCR_domain.'/index.php?id='.$page['uid'],$addQueryParams).$sectionMark;

so here is my fix for the problem (dunno if it also works with realURL):
I changed the two lines at typo3/sysext/cms/tslib/class.tslib_content.php, line 5255 (commented lines are the original of typo3 4.0):

//$LD['target'] = $target;
$LD = $GLOBALS['TSFE']->tmpl->linkData($page,$target,$conf['no_cache'],'','',$addQueryParams,$theTypeP);
//$this->lastTypoLinkUrl = $this->URLqMark('http://'.$tCR_domain.'/index.php?id='.$page['uid'],$addQueryParams).$sectionMark;
$this->lastTypoLinkUrl = $this->URLqMark('http://'.$tCR_domain.'/'.$LD['totalURL'],'').$sectionMark;

in my installation it works with and without simulateStaticDocuments
can someone confirm this?

Klauss, does it work if second domain does not have simulateStatic enabled? Does it work if one domain has simulateStatic and another realurl?

i wasn't able to get real url to work on my demo installation, perhaps someone else could try. i will try to find out what happens when linking to pages with different ts setup.

linking between two pges with different simulatestatic options does not work. but during my testing i also recognized, that this does not work when linking in the same domain (different pages with different simulatestatic options).

so if this feature isn't integrated (to check if the linked page has a different simulatestatic option), than i would perhaps suggest to provide a typoscript option to enable the linking between domains with simualte static (i guess real url will hook in there).

comments?

Hey ...

I suppose with "<<Linking>> between domains" you mean creating shortcuts from one page to a page in another domain - if this is the problem I guess you should try this:

http://think-open.org/kraftb/index/T3X_kb_domainLinks-0_0_0.t3x

Then just set:

config.domainTarget = _top

instead of:
config.typolinkCheckRootline = 1

typolinkCheckRootline MUST NOT be set - else it won't work.

We discussed this on the core list recently. The problem which Dmitry points up is that one would have to parse the TS of the other tree in order to see wheter the "linktarget" page has also simulate Static set.

The extension above does not care about this so you are required to have the same realURL or simulateStatic settings in all your sites (in the same installation of course)

There would be a way which would make it possible to have mixed normal/simStatic/realURL multi-domain sites - the solution would be to allow a list of sites in the config.simulateStaticDocuments TS setting like:

config.simulateStaticDocuments = www.siteA.com,www.siteC.com

instead of a simple boolean value - but the admin would have to keep track of the different settings in the different domains
(an easy to handle solution would be to make 1 TS Template Record called "simulateStatic Settings" (or realURL) and there set the config.simulateStaticDocuments TS value.

Then just include this TS record in every root-template.

greets,
Bernhard

what i mean is when creating a shortcut (link) between two pages in the same tree but with differen ts settings of config.simulateStaticDocuments it is also not parsed correctly.

therefore the solution to make the simulateStatic settings global would make sense (or implement it on a page basis, but that would cost performance).

nevertheless, the current implementation is not good.

so changing

$LD['target'] = $target;
$this->lastTypoLinkUrl = $this->URLqMark('http://'.$tCR_domain.'/index.php?id='.$page['uid'],$addQueryParams).$sectionMark; [^]

to

$LD = $GLOBALS['TSFE']->tmpl->linkData($page,$target,$conf['no_cache'],'','',$addQueryParams,$theTypeP);
$this->lastTypoLinkUrl = $this->URLqMark('http://'.$tCR_domain.'/'.$LD['totalURL'],'').$sectionMark; [^]

would fix the problem. still it should be implemented that the simulate static document setting is global for the whole pagetree

Klaus, this code assumes that typo3 always runs under non-secure connection, which is wrong.

The extension by Bernhard Kraft doesn't work on my server :-/ (it doesn't change anything).. T3 4.0.4

@Dmitry Dulepov
you are right, but the original code also preprends http:// and so no secure connections would work

I have the same problem like Klaus Hinum describes here:

http://bugs.typo3.org/view.php?id=3491#9569

If I switch of the htmlArea and write <link http://test.com/abc.html&gt;Test&lt;/link> everything is allright. But if the link is written in the RTE it is cut to <link abc.html>Test</link>.

It would be nice, if an external link would be saved as it is.

Klaus Hinum has discussed that with Stanislas Rolland in the [TYPO3-RTE] "bug? - links between subdomains" (30.04.2006 11:50), but with no solution.

I've tried both Bernhard's and Klaus' solutions and they don't create RealURL paths, just standard index.php?id=...

By the way extension aoe_realurlpath 0.1.0 produce "good" links to other domains, I mean without ids. Also the ext handles workspaces.

Uploaded patch. It will work with simulateStatic out of the box. TS template must have "config.typolinkEnableLinksAccrosDomains=1" and it automatically implies "config.typolinkCheckrootLine=1"

It will not work wirh realurl out of the box because page is outside of rootline. But this will be fixed if patch is accepted for TYPO3 core.

Dmitry, don't forget the documentation!

Sorry to be a stiggler, but couldn't help noticing:
config.typolinkEnableLinksAccrosDomains = 1
should be:
config.typolinkEnableLinksAcrossDomains = 1

... just in case the incorrect version finds its way into TS :-s

Nice work by the way. I've been looking forward to this change! :-)

true, thanks for the hint at the typo!

Sorry for the typo... I just woke up to early to get this bug fixed in time for beta2. It was outside of my schedule... :( Typo fixed in 4.2 branch.

Documentation is being updated now in the wiki.