TYPO3 Core

Attached patch adds a setting RTE.default.proc.preserveExternalURLs, which if set to 1 fixes this issue. If someone needs the URLs to be relative, it can be set to 0.
This setting will need to be documented when the patch is commited

Version 2 of the patch sets the new setting to 1 by default (thereby fixing the issue)

This issue seems to be related to http://bugs.typo3.org/bug_view_advanced_page.php?bug_id=11009, or at least might be ....

11009 is resolved on my installation, but this issue is still present. Also, this was filed long before 11009 even appeared.

I don't think this issue is related to issue #11009 which is specific to Firefox.

http://bugs.typo3.org/view.php?id=11009 (ff setting a internal link ends up as external link with http://www.domain.de/typo3/http://www.domain.de/link.html)

is still not resolved for version typo3 4.3 (latest from svn) and ff 3.5.2 mac!

this bug is allready quite long out there, wow. right now no passion to pick it up.

all the best
andreas

patch not working on 4.1.12

domain rewriting still happening.

i tried applying 9455_v2.diff on 4.2.8 but no effect

i think that External URL should not be touched in any way by the htmlarea...

my problem is this:

i have to link a complicated parametered subpage, like:

http://www.mysite.com/index.php?id=mypage&no_cache=1&myparam=747

what does htmlarea does?
it sees this ?id= and considers it as a page, so he thinks it's better to touch it as it was an internal URL, breaking everything (giving the yellow box around the link as error)

I confirm the problem is present in version 4.2.8 and it is a different problem than 0011009.
I had issue 0011009 which is now solved on my system, but I now have this issue which is reproducible both using firefox, google chrome (webkit) and IE6.

I have tried applying 9455_v2.diff on 4.2.8 as well, but for me also the issue remains unfixed. I do have emptied my browser cache before testing.

I also confirm this is a major bug because it prevents editors from creating links in RTE content elements on multisite typo3 setups when they are working on other sites than the very first website defined in the tree.

The problem seems to lie in the fact the type of links to pages inside a secondary website is misinterpreted by the RTE and returned in the HTML code as an external link prepended with the domain name used to login in the typo3 interface. Regarding this aspect, this bug might in fact be related to bug 0011009 which wouldn't be completely solved.

A SUCESSFUL WORKAROUND for properly editing the links of a RTE tt_content element on a seconday website is to login into typo3 by using the secondary website's domain name : http://mysecondarysite.com/typo3/

If the link is a page link and the link is set using the pagetree and typolinkEnableLinksAcrossDomains is set on both sites, then the links are rendered correctly whether they are edited through the main domain or the subdomain.

Please test attached patch: typo3core_bugfix_9455_trunk.patch

Hello Stanislas,

Thanks for working on this issue. I have just applied your patch, cleared all caches both with Typo3 and my browser, but the fix didn't make it.
The main domain name is still being inserted in my RTE HTML when creating links inside websites belonging to other domains. Notice all domains have a separate tree in my installation.

Regards,

More Info on that:
This bug(s) appear as i remember since firefox version 3.x

The internal- and/or external-link will be rewritten in rtehtmlarea (1.8.2) no mather which typo3 version (>4.1).
If i use a sys_domain it's rewritten like: http://www.domain.net/typo3/http://www.domain.net/?id=33 - otherwise it's http://typo3/http://www.domain.net/?id=33

I did now a serial with tests:
Main result: rtehtmlarea in the latest svn of the typo3 4.3 version (1.8.3) FIXED the problem!! Internal and External Links work as they should (also with realurl).

Main problem: This works only for Typo3 4.3 alpha or Typo3 4.3 beta.
I don't know if this is a hint for you Stanislas to find a solution for older Typo3 Versions.

all the best
andreas

Stanislas,

Based on reading, I don't think the patch resolves the issue completely. Here is a scenario:

tt_news record is posted by a user logged into domain1, in the domain1 page tree. The record is displayed in domain1, as well as domain2, which pulls records from domain 1 page tree as well. The link in domain2 will be incorrect.

As far as I see there is no way to solve this problem except by keeping all absolute links absolute.

i fully agree with Dan.. at least there SHOULD be the possibility to insert an URL and to know that htmlarea or anything else won't touch it... (maybe a new category: ABSOLUTE urls? )

Maybe... Is it time to redesign the link wizard?

Dan,

I do not understand your scenario. What type of link are you referring a link to a page in the page tree or a link to a file, and is it targeting domain1 or domain2?

Stanislas

A link to a page. The page is in domain1, so it becomes relative. It works when the record is displayed in domain1 page tree, but not in domain2

Dan,

I may be wrong, but I don't think that this is a problem of the link wizard, but one of transformation of links into typolinks on the way to the database. As I mentioned, all links entered in the RTE must be with absolute href. The question really is how to convert those to typolinks, avoiding when possible absolute urls, so as to benefit from the features associated with the typolinks.

Stanislas

Correct, that is a problem with the transformations. So what I was saying is there should be a way to have a field for links that will not be transformed, or better yet leave absolute links the way they are.

Beitrag:
Ausschnitt aus der Datenbank (Typo3 4.3 apha2 / rtehtmlarea 1.8.3) - sys-Domains werden verwendet - alle Links korrekt im Frontend:
<link 61 - internal-link>...</link>
<link h t t p : //w w w.univie.ac.at - external-link-new-window>222</link>
<link fileadmin/Doc.rtf - download "Initiates file download">333</link>

I am attaching a new patch with a completely different approach:. Any link entered in the External Url tab of the RTE link wizard will be preserved.

Such link will not be transformed in a typolink. The RTE will add an attribute named "external" that will prevent any transformation on the way to the database. The attribute will simply be removed.

On the way from the database to the RTE, if an a tag has an href with a scheme (other than mailto), it will considered as external. The "external " attribute will be added for the RTE to know.

Waiting for comments and test results.

Hi Stan,

Applying your patch against the genuine t3lib/class.t3lib_parsehtml_proc.php file from typo3_src-4.2.8 fails :

[root typo3_src-4.2.8]# patch p0 < typo3core_bugfix_9455_trunk_v2.patch
(Stripping trailing CRs from patch.)
patching file t3lib/class.t3lib_parsehtml_proc.php
Hunk #1 succeeded at 656 (offset 1 line).
Hunk #2 succeeded at 1593 (offset -3 lines).
(Stripping trailing CRs from patch.)
patching file typo3/sysext/rtehtmlarea/extensions/TYPO3Link/class.tx_rtehtmlarea_typo3link.php
Hunk #1 FAILED at 87.
1 out of 1 hunk FAILED - saving rejects to file typo3/sysext/rtehtmlarea/extensions/TYPO3Link/class.tx_rtehtmlarea_typo3link.php.rej
(Stripping trailing CRs from patch.)
patching file typo3/sysext/rtehtmlarea/mod3/class.tx_rtehtmlarea_browse_links.php
Hunk #1 FAILED at 247.
Hunk #2 FAILED at 703.
Hunk #3 FAILED at 882.
3 out of 3 hunks FAILED -- saving rejects to file typo3/sysext/rtehtmlarea/mod3/class.tx_rtehtmlarea_browse_links.php.rej

Have you generated it using a diff on the genuine t3lib/class.t3lib_parsehtml_proc.php file from typo3_src-4.2.8 ?

Might be usefull : As far as I remember, this bug wasn't present in releases prior to 4.2.6. This is a regression.

This is truly a link transformation problem as the RTE is no longer capable of figuring which domain makes authority in the rootline of the page being currently edited when inserting a simple page link.
Knowing wich domain makes authority can be questionable as there might be several domain records in the rootline. I'd say the domain which should be selected should be the deepest in the rootline and closer to the current page being edited. It should also be the first entry in the list / sorting value if there are several domains at the same level of the rootline.

When solving this issue, it would be nice to check if the RTE also correctly figures the good domain name for a page link to a page that is located in a different rootline than the page currently being edited, as this is more or less related to this issue. It has never been working properly if I remember well. Can anyone confirm ?

Alban,

Read bug description - its reported for 4.2.1.
Besides, RTE doesn't chose the domain name, it just strips it out. The problem in this case is that it strips it out when it shouldn't

@Alban: the patch is generated against current trunk.

I think that if the href is entered as external, there is no reason for the RTE transformation to modify it.

Attached patch (typo3core_bugfix_9455_4-2-8_v3.patch) should work for 4.2.8

Tested for various links, mostly works
There was still one case where it took out the domain - I'm looking into it.

Thanks guys. I have just applied the patch and here are my results :

- (MAIN site rootline) : Link to page in same site : works when page is rendered, but bad domain name is still present into RTE's representation of the link in the html code display (bad domain name diplay in RTE HTML issue applies to all the following tests, so I will not repeat it again at each test result).
- (MAIN site rootline) : Link to page in secondary site : does not work (returns correct rewrited URL prepended with MAIN site domain name instead of secondary site domain name.

- (SECONDARY site rootline) : Link to page in same site : works when page is rendered.
- (SECONDARY site rootline) : Link to page in MAIN site : does not work (returns correct rewrited URL prepended with SECONDARY site domain name instead of MAIN site domain name.

@Alban

I don't understand your test cases. Please detail. Are you using the external link tab of the link wizard?

If you are using the page tree to link cross-domain, you should set typolinkEnableLinksAcrossDomains in your TS templates. I think what domain you get inside the RTE for such links is irrelevant.

Hi Stanislas,

Using typolinkEnableLinksAcrossDomains did the trick for links across websites so it solves the 2 nonworking issues of my previous post. I don't get why this option is not enabled by default in Typo3 though, because I see no benefit having it disabled, and lots of headaches figuring out it exists when you need it !

The only issue I see which remains is the following :

In more detail, say I have 2 rootlines :
- the first uses domain name "www.domain.com" (this is the MAIN rootline / MAIN website and this is the domain name being used by editors to login into the backend interface)
- the second uses domain name "secondary.domain.com" (this is the SECONDARY rootline / website.

In the RTE, on a page of www.domain.com, if I create a link to another page located in the same website, I will have displayed in the RTE HTML code :
<a title="Opens internal link in current window" class="internal-link" href="http://www.domain.com/?id=the_page_id&quot;>
This is fine.

Now, still in the very same content, if I create a link to another page located in the SECONDARY website (note : typolinkEnableLinksAcrossDomains is enabled), I will have displayed in the RTE HTML code :
<a title="Opens internal link in current window" class="internal-link" href="http://www.domain.com/?id=the_page_id&quot;>
This is NOT fine as the domain name in the link should be "secondary.domain.com". However, when generated in frontend, the link is now properly directed to secondary.domain.com so the link works. It is just badly displayed in the RTE HTML representation.

Thanks a lot to both of you for fixing the main issue by the way. This one was really problematic here (we are managing 5 websites in the same Typo3 installation).

@Alban: Thank you for testing. I think that if the domain is not exact while inside the RTE, it does not really matter. On saving, the link is transformed in typolink. And the link cannot be activated from within the RTE, so no linking error may happen.

@Dan: Please report the one case where the domain was still taken out when using the externalk link tab.

The one link it didn't work for was a local domain link with RealURL. My local installation is in http://localhost/t3, and a link http://localhost/t3/news/local.html was transformed to:
<link news/local.html - external-link-new-window "Opens external link in new window">http://localhost/t3/news/local.html&lt;/link>

I tried it on a 4.2.8 patched installation.

Dan,

Was the link entered using the external url tab?

There is one problem I can see with this approach: if a link was entered before the patch was applied, and was already transformed into a typo3link, then it will not be preserved. Perhaps, this is not a real issue as it was not possible to preserve those external links before the patch was applied anyways.

I will review the 4.2 version of the patch.

Yes, it was. It was a freshly saved record after the patch was applied.

Thanks!!

This is a duplicate of 11231.
I applied the patch (TYPO3 4.2.12) and still have the same problem:

- In the database the external link is stored as: <link aktuell/veranstaltungen/ _blank external-link-new-window>Agenda / Veranstaltungen</link>
- The RTE shows the correct link: <a href="http://www.domain.tld/aktuell/veranstaltungen/&quot; target="_blank" class="external-link-new-window">Agenda / Veranstaltungen</a> (domain.tld is the same domain as my backend domain)
- In FE the domain is being rewritten to the subdomain of the page the content is displayed: <a href="http://www.subdomain.domain.tld/aktuell/veranstaltungen/&quot; target="_blank" class="external-link-new-window">Agenda / Veranstaltungen</a>

What did Dan do to finally make it work?

I got the problem on a TYPO3 v 4.1.3.
can anyone tell me the correct patch to apply to correct this point.
(and of course, the client, don't have a budget for a typo3 upgrade at the moment)

Attaching new versions of the patch in order to fix small glitch.

Fixed in SVN TYPO3core trunk (TYPO3 4.4) (revision 7575) and branch TYPO3_4-3 (revision 7576).