Feature #2624
Dynamic markers in recipient field
| Status: | Resolved | Start date: | 2009-02-12 | |
|---|---|---|---|---|
| Priority: | Could have | Due date: | ||
| Assignee: | Alex Kellner | % Done: | 0% |
|
| Category: | Backend Modul | |||
| Target version: | - | |||
| Votes: | 0 |
Description
Hi,
It could be useful to have dynamic markers in the recipient field of Powermail.
At the website I'm working on, we're using an external PHP-function to generate the recipient of a contact form based on the nearest page author in the rootline of the referer-page (can you follow? ;-) )
For this, I use a dynamic marker and needed to have that filled in in the recipient field too.
Therefore I added the line:
$emails = $this->dynamicMarkers->main($this->conf, $this->pibase->cObj, $emails); // set dynamic markers receiver
in pi1/class.tx_powermail_submit.php just before:
$emails = $this->div_functions->marker2value($emails,$this->sessiondata); // make markers available in email receiver field
I don't know whether you'd like to add this to Powermail by default, but I'll leave that up to you.
Associated revisions
[Bug 2624] Crash in the EM, r=saskia
[Bug 2624] Crash in the EM, r=saskia
History
Updated by Alex Kellner over 4 years ago
- Status changed from New to Accepted
This is realy a nice idea - but it seems you're using an old version of powermail - I would use this lines:
$emails = str_replace(array("\r\n", "\n\r", "\n", "\r", ";", "|", "+"), ',', $this->cObj->data['tx_powermail_recipient']); // commaseparated list of emails
$emails = $this->div->marker2value($emails, $this->sessiondata); // make markers available in email receiver field
$emails = $this->dynamicMarkers->main($this->conf, $this->cObj, $emails); // set dynamic markers receiver
$emailarray = t3lib_div::trimExplode(',', $emails, 1); // write every part to an array
And I would extend the subject in the same kind.
Updated by Alex Kellner over 4 years ago
- Status changed from Accepted to Resolved
- Assignee set to Alex Kellner
Resolved in 1.4.9
Updated by Bart Laarhoven about 4 years ago
- Status changed from Resolved to New
It is correct, we use a somewhat patched version of Powermail 1.3.9, therefore we cannot just upgrade.
But I think you use the wrong order in your solution. If I have a field uid345 and a "dangerous" powermail dynamic marker called dangerousmarker (with information I'd not like to share with the user), and I'd like a user to be able to set the subject of his own and my mail, I could make the subject something like "###UID345###".
But, if the user is really evil, he could fill in the uid345-field with "###POWERMAIL_TYPOSCRIPT_DANGEROUSMARKER###" which would lead into complete drama because the user can see my dangerous information! ;)
So, I'd suggest to change the order of the lines (the dynamicMarkers-line and the marker2value-line) to make sure that the UID-markers are filled in as the last ones. That also makes it possible to use uid-fields in the dynamic markers, which could be of some use. Probably. Maybe. (Didn't give that enough thought yet)
Is this reason enough to reopen this issue? :)
Updated by Alex Kellner about 4 years ago
I'm not realy convinced about your example case.
"Dangerous typoscript" (strange term) must be added from an admin (editors don't have access to the T3 setup) - and admins should be trustful users!?
Updated by Bart Laarhoven about 4 years ago
True, but "dangerous" is indeed not the right term. I mean information that should not be exposed to the user.
For example, as I said in the original ticket, we use a dynamic typoscript marker to select the email address where the mail should go to, based on the referer of the page and the authors in TYPO3. We don't want the users to get the email address, we'd like them to use the (powermail) mail form. If a user is able to enter the correct marker (###POWERMAIL_TYPOSCRIPT_SOMETHING###) into a field he is able to edit, the whole idea is gone and your "secret" information is exposed to the user.
Of course, the user has to make an educated guess for the correct marker etc., but why not make it just impossible for a user instead of making it difficult.
Updated by Alex Kellner about 4 years ago
- Status changed from Accepted to Resolved
Finally resolved in 1.4.10