Feature #22286
closed
URLs with tel:... and sms:... not supported in core
Added by Stefan Neufeind over 14 years ago.
Updated over 8 years ago.
Description
Those URLs get mangled. RTE (and possibly parts of core?) parse them as ?id=tel:... and are true that's not a valid page-ID :-)
Those two URI-types existed for quite a while and become more popular again with smartphones nowadays.
PS: Maybe also other URI-types should be allowed, e.g. sip:... or xmpp:... It would mean to "simply" leave them untouched.
(issue imported from #M13829)
Files
For add tel: et sms: URI, you can modify this file in typo3 4.2.X .t3lib/class.t3lib_parsehtml_proc.php, in function transform_rte
before :
if(strtolower(substr($link_param, 0, 7)) == 'record:' ) {
$href = $link_param;
}
---
After
---
if(strtolower(substr($link_param, 0, 7)) 'record:' || strtolower(substr($link_param, 0, 4)) 'tel:' || strtolower(substr($link_param, 0, 4)) == 'sms:') {
$href = $link_param;
}
You can find an extension that use a hook for manage that.
Tested only on >= 4.2.10
Should we maybe add a configruration via TypoScript so additional "protocols" can be added easily? Imho then they could also be availble in the "add a link" popup-dropdown in RTE etc.
Should commonly used "protocols" like tel be added to the core by default?
Hi guys,
thanks for your thoughts about that problem.
Chances to get a nice solution integrated in TYPO3 are best, if you ask these questions in Core List; here in the bugtracker it is unlikely that people respond.
Just take e.g. the patch above as basis, attach it to a mail and send it to Core List.
For more information please check out http://typo3.org/teams/core/core-mailinglist-rules/
This is already working in the RTE since TYPO3 4.4.0. You may enter links as external url's with procoles such as skype, tel, sip, sms...
This is also true in the link browser in general. sms:what-ever may be entered as external link where ever a link wizard is available.
Entering <a href="tel:12345"> in a normal RTE-window in 4.5.0-alpha2 and saving results in
<a href="http://localhost/?id=tel:12345" rteerror="No page found: 0" style="background-color: yellow; border: 2px solid red; color: black;">
So I assume the protocols still need to either be whitelisted (?) somewhere or are still handled wrong in the core? Last time I checked (in 4.3.x) TYPO3 tried to resolve those URLs back and forth which caused it to treat those URLs as internal pages - and it didn't find the ID referenced.
Use the external tab of the link dialogue to enter the link.
I did. And the generated code is fine until it comes to saving (and loading again).
Yes, you're right. It seems that if you enter tel:123456 (or any other sip, sms, skype), then it works.
But if the string following the : is shorter than 6 characters in length, then it does not work...
- Target version deleted (
4.4.0)
The tel: protocol in RTE still looks to me. I didn't even know that tel: is already implemented until I found this feature request.
When you use a whitespace in the telephone number, RTE marks the link as bad.
It's not that much, but when you try to insert a telephone number this way, you won't get an idea what is wrong.
Update: When I insert a '/' in the telephone number, it becomes not marked as bad, but somehow the website's url gets prepended.
Christian, what version did you try against?
Just tested against current TYPO3_4-5 as well as master (to become 4.6). The following worked fine for me in rtehtmlarea and also successfully made it's way to the frontend:
<a href="tel:+49-12345" external="1">tel</a> <a href="sms:+49-12345" external="1">sms</a>
So from my side it looks working for me meanwhile, so we could close it.
- Status changed from Needs Feedback to Closed
- TYPO3 Version set to 4.3
Closing the issue for the sake of a clean bugtrack - feel free to open it once you can provide further feedback
Just if someone else will come here after the 5 years.
It's working (7.6 LTS). The only issue is, that the Wizard will show
http://
in front of it, even if it's not there.
Just test whether everything else works as expected after saving.
Also available in: Atom
PDF