Project

General

Profile

Actions

Bug #24989

closed

external="1" on crypted emails

Added by gert about 13 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2011-02-09
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.5
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

If you crypt your emails for spam-protection (eg with http://jumk.de/nospam/ ) rte will insert an indelible external="1" into the a element.

There external="1" should be removable on other links as well.

(issue imported from #M17524)

Actions #1

Updated by Stanislas Rolland about 13 years ago

I don't understand this issue. How is the link entered in the RTE? Is this external attribute rendered in the frontend?

Actions #2

Updated by gert about 13 years ago

The link is entered manually in the html-view. The external-attribute with the value "1" is rendered as target="_blank" in the fe. Unless it's suppressed with rtekeep="1" or by specifying a target (which has precedence over external).
But an indelible external shouldn't be there in the first place.

Actions #3

Updated by Stanislas Rolland about 13 years ago

Why enter links manually in html view? You have options to render encrypted emails in the frontend.

If I understand well, the external attribute is not rendered in the frontend. So what is the problem?

Normally, the external attribute should not even be in the database, only in the RTE.

Actions #4

Updated by gert about 13 years ago

"Why enter links manually in html view?"
I like it that way. For one point, it's faster. There are other points, but that's not the point.

"You have options to render encrypted emails in the frontend."
I believe you mean I have options to render emails encrypted in the frontend. I know that.

"So what is the problem?"
The problem is that I have to add rtekeep="1". It's just nonsense to equip email links with a target="_blank".

"Normally, the external attribute should [...] be [...] in the RTE."
No, it should not be in the rte when it's an email-link. And it should not be indelible.

I hope you agree that a suggestion for alternative solutions is not an appropriate way to deal with bugs.

Actions #5

Updated by Stanislas Rolland about 13 years ago

How to reproduce this?

What do you enter as link in html view?

Actions #6

Updated by gert about 13 years ago

you can eg enter

<a href="javascript:linkTo_UnCryptMailto('nbjmup;nvtufsAnvtufs/di');" >muster [at] muster [dot] ch</a>
and you get

<a href="javascript:linkTo_UnCryptMailto('nbjmup;nvtufsAnvtufs/di');" external="1">muster [at] muster [dot] ch</a>

The external-attribute is indelible.

This bug does not occur with typo3 4.3 (I didn't try other versions).

(When I reported I thought the external attribute is added by default for http links. This is however not the case. )

Actions #7

Updated by Stanislas Rolland about 13 years ago

I see. The protocol is not mailto, so that TYPO3 does not consider this to be an email link.

The external attribute does not go into the database and is not rendered in the frontend.

The link is considered as an external link. Therefore, if you use the constant editor, you can set

styles.content.links.extTarget =

in your TS template and no target attribute will be rendered on external links.

Actions #8

Updated by gert about 13 years ago

"TYPO3 does not consider this to me an email link."

Yes, exactly. That's what i refered to as bug. Why would typo3 want to treat all href's it doesn't understand as external links?
It should not force an external attribute when it doesn't understand the meaning of the href-value.

Actions #9

Updated by Stanislas Rolland about 13 years ago

The external custom attribute is used to ensure that the domain of url's entered in the external url tab of the link dialogue are never modified by the RTE transformation. This external attribute exists only inside the RTE. This is not a bug and will not be changed.

Removing the target attribute on the frontend is a matter of configuring frontend rendering. Perhaps there should never be a target attribute when the protocol is not http(s). If you think so, please post a feature request for content rendering.

Actions #10

Updated by Alexander Opitz about 10 years ago

  • Status changed from New to Needs Feedback
  • Target version deleted (0)
  • TYPO3 Version set to 4.5
  • Is Regression set to No

Hi,

as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (6.1.7)?

Actions #11

Updated by Alexander Opitz almost 10 years ago

  • Status changed from Needs Feedback to Closed

No feedback within the last 90 days => closing this ticket.

If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.

Actions

Also available in: Atom PDF