Project

General

Profile

Actions

Bug #78043

closed

Can't create local anchors using RTE

Added by David Voigt over 7 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Link Handling, Site Handling & Routing
Start date:
2016-09-22
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
7
PHP Version:
5.5
Tags:
rtehtml
Complexity:
medium
Is Regression:
No
Sprint Focus:
On Location Sprint

Description

I can't create internal anchor links using the RTE because TYPO3 always prepends links to content elements with the URL with which I'm currently logged in. This is the result I expect:

<a href="#c123">

This is what I get:

<a href="http://domain.tld/index.php?id=1#c123&quot;>

I'm creating an email newsletter, but imho this has nothing to do with it. When I look at the source code of the generated page in my browser, all anchors are prefixed. My page does not have a <base href="...">

It makes no difference if I'm using realurl or not, or if I even have a URL record in my system's root page, I have tried it with and without.

# we don't need baseURL here
config.baseURL >

# we need this so images and other resources are being loaded in email newsletter
config.absRefPrefix = http://domain.tld/

# Set this to 0 for local anchor functionality (this doesn't have any effect)
config.prefixLocalAnchors = 0

Using TYPO3 7.6

There have been a few related tickets but those were very old (TYPO3 4.x) and are therefore likely to have different causes.

This might be related with https://forge.typo3.org/issues/65934 but using compatibility6 extension didn't affect this behaviour.


Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Bug #62723: Cache poisoning with prefixLocalAchorsClosed2014-11-05

Actions
Related to TYPO3 Core - Bug #65934: Move prefixLocalAnchors to compatibility6ClosedBenni Mack2015-03-23

Actions
Related to TYPO3 Core - Bug #84111: CKeditor: custom section / anchor links (external) will result in page=current#section linksClosed2018-03-02

Actions
Actions #1

Updated by Markus Klein over 7 years ago

Hi!

Can you please describe how you enter those links? Are you using the link wizard?

Actions #2

Updated by David Voigt over 7 years ago

Hi, yes, I am using the link wizard, internal link -> select my page -> click on the little arrow -> choose a content element on the local page.

When I instead edit the links in RTE source view and save it, RTE changes this

<a href="#c123">

to this:

<a href="http://domain.tld/#293&quot;>

which doesn't help, either.

Actions #3

Updated by Markus Klein over 7 years ago

Well, in DB it does not store an a-tag but the custom <LINK ...> syntax. (At least in CMS 7 and lower)
So it does not matter what is shown to you in RTE.
It solely depends on your Template (TypoScript) how the links are rendered in FE, but by default a page is prefixed.

In your manual case the domain is prefixed in FE, due to your absRefPrefix.

What is your actual goal you want to achieve? I propose to get in touch with us on Slack to have direct support.

Actions #4

Updated by David Voigt over 7 years ago

I'm not talking about what is shown in RTE, I'm looking at the generated source code. I need this functionality for creating pages I want to send out as HTML email newsletters (direct_mail, but it doesn't matter). That means, images need to have absolute paths, as do external links, but local links (anchors) absolutely can not.

If I simply remove the absrefPrefix, images lose their absolute path and can't be loaded from the server. In the past, all local anchor prefix could be controlled with config.prefixLocalAnchors = 0 but this has no effect anymore. I think this is an issue that potentially affects everybody who wants to create email newsletters with TYPO3.

Actions #5

Updated by Markus Klein over 7 years ago

https://typo3.org/community-support/
https://forger.typo3.org/slack

Thanks for explaining the usecase. I have to look up the code changes of the past.

Actions #6

Updated by David Voigt over 7 years ago

I think this functionality has been removed. There's a related issue btw, prefixLocalAnchors has been moved to compatibility6, but it doesn't work with the extension installed, either. Edit: I have investigated the code and compatibility6 is not supposed to, or going to bring back "local" local anchor functionality.

Actions #8

Updated by Markus Klein about 7 years ago

  • Assignee set to Markus Klein

I'll put that one on my "agenda". I will try to work on this one during the typo3camp vienna.

Actions #9

Updated by Riccardo De Contardi almost 7 years ago

I performed the following test with the latest master:

1) TS Setup:

config.absRefPrefix = /
config.prefixLocalAnchors >
config.baseURL >

2) I added a link named "totop" using the "flag" icon in CKEditor.

Result

<a href="/index.php?id=1&amp;L=0" id="totop" name="totop">Test</a>
Actions #10

Updated by David Voigt almost 7 years ago

Riccardo De Contardi wrote:

I performed the following test with the latest master:

Not sure how this helps, that's not a local anchor (should begin with # as shown), and you won't be able to load images from the server with absRefPrefix = /

Actions #11

Updated by Markus Klein almost 7 years ago

  • Complexity set to medium
  • Sprint Focus set to On Location Sprint
Actions #12

Updated by Riccardo De Contardi almost 7 years ago

Ok sorry I performed a different test on 7.6.20; please note that I use the standard RTE configuration; I just added as page TSConfig:

RTE.default.showButtons = *

I added a text with media content element and then a link to a content element; results:

on RTE:

<p>Lorem Ipsum <a href="http://typo3.7.test.it:8888/?id=18#37" class="internal-link" title="Opens internal link in current window">Dolor</a> Sit Amet</p>

on frontend:

<p>Lorem Ipsum <a href="index.php?id=18&amp;L=0#c37" title="Opens internal link in current window" class="internal-link">Dolor</a> Sit Amet</p>

Actions #13

Updated by Anja Leichsenring over 6 years ago

  • Sprint Focus deleted (On Location Sprint)
Actions #14

Updated by Laurent LEREVEREND about 6 years ago

  • Tags set to rethtml

Hi,
I think it's not resolved. I've the same problem. Read the original description.

David Voigt have maybe find an alternative solution ?

Actions #15

Updated by David Voigt about 6 years ago

Now that two people have the same problem, maybe that creates enough pressure to have this fixed.
Local anchors are in the HTML standard, and a trivial matter. I would write the anchors by hand, but the RTE "fixes" them. Possible solutions:

- not use RTE
- don't use local anchors
- don't use TYPO3

None of which fix the problem. We have since (it's been over 1 year) moved to Mailchimp.

Actions #16

Updated by Markus Klein about 6 years ago

  • Status changed from New to Accepted
  • Assignee deleted (Markus Klein)
  • Target version set to Candidate for patchlevel

Lol... pressure is there, no worries, on a lot of work fronts.
But time limitation is there too.

If the matter is very urgent to you, find a (paid?) dev to implement it and things are resolved.
I make my living from paying customers and not from free TYPO3 bugfixing.

Actions #17

Updated by David Voigt about 6 years ago

It was a joke. Sorry.

Actions #18

Updated by Riccardo De Contardi about 6 years ago

  • Related to Bug #84111: CKeditor: custom section / anchor links (external) will result in page=current#section links added
Actions #19

Updated by Susanne Moog over 5 years ago

  • Sprint Focus set to On Location Sprint
Actions #20

Updated by Nicolai Schirawski over 5 years ago

  • Tags changed from rethtml to rtehtml
Actions #21

Updated by Nicolai Schirawski over 5 years ago

In both TYPO3 8.7.20-dev and 9.5.1-dev, local anchors can be set in two different ways:

- first by choosing "internal link" and selecting a content-Element on the current site
- second by choosing "external link" and typing "#ID" into url-field, where ID is the uid of the content-element.

Both links will be rendered the same in FE:

- either "domain/index.php?id=1#c3" (8 LTS)
- or "domain/#c3" (9 LTS)

Both are valid and if there are no other use-cases, the ticket should be closed, I think.

Actions #22

Updated by Anja Leichsenring over 5 years ago

  • Status changed from Accepted to Resolved
Actions #23

Updated by Benni Mack almost 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF