Feature #39735
Urls in Newsletter too long
| Status: | Rejected | Start date: | 2012-08-12 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - | |||
| Votes: | 0 |
Description
Hi,
imo url's in the newsletter are too long. Possible solutions could be to implement an eID Script which handles click statistics ecc. instead of the call to extbase (btw. this would be good for performance too)
- or at least implement a hook so own handling can be implemented (e.g. external service like bit.ly)
Attached patch introduces a new hook.
History
Updated by Adrien Crivelli 9 months ago
Did you actually implement a service such as bit.ly ?
I would recommend against it, because it will drastically slow down the sending of Newsletter, because you'll have to generate hundreds, if not thousands, of HTTP request for each sending round. I would also recommend against storing a mapping table in database because it can quickly grow as a huge amount of "relatively unnecessary" data (that was actually the case in tx_directmail, and it's one of the improvement done in Newsletter).
Overall I don't see the point in "hiding" the URL from the end-user, because the average user will actually almost never see it. And he's not supposed to bookmark/share/store those links. But it's still readable for power-user (read "me" ;-) ). I am personally not keen on clicking shorten URL because of theirs shortcomings.
However, after saying all that, I guess implementing a hook, would not hurt that much. But I would like to know about your use-case and experience first...
PS: eID Script is out of the question. I wrote that extension with Phoenix in mind, so I will avoid "legacy code" as much as possible (as hopeless as I am for an actual "easy" port to Phoenix... but that's another story...)
Updated by Adrien Crivelli 4 months ago
- Status changed from New to Rejected
This ticket is rejected for lack of interest from all involved parties.