dynamic &to

[Guest]

Welcome, Guest. Please login or register.
Did you miss your activation email?

1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[pixelchutes]

Are you running this in 0.96 ?.  Here's an outrageous little test.

Instead of having &from=`[+email+]` make it &from=`((email))` and update line 420 to read

Code:

<?php
$from = str_replace('((email))',$fields['email'],$from);
?>

Does that work?  If so I have the suspicion that the order in which place holders are evaluated has changed and the [+email+] is replaced before eForm sees it.

Sure enough. That worked. Hmm...it appears this is isolated to an 096 issue. Almost as if 096 parses snippet calls differently (processing order?) ...specifically noticable with snippets that have placeholders in the call. Any placeholder I pass as a snippet param is removed prior to even hitting the snippet-level...this is not the case on my 0.9.5[.1] build sites...hmmm

This might explain why my eForm 1.4.2 theory didn't work as intended (on 096) ...It is functioning fine, however, on 095 :/

[OpenGeek]

I think the problem you are running into is that your are calling $modx->stripTags() which erroneously did not remove placeholder tags, until revision 2166 from netnoise...

Code:

Index: /tattoo/branches/095dev/manager/includes/document.parser.class.inc.php
===================================================================
--- /tattoo/branches/095dev/manager/includes/document.parser.class.inc.php (revision 2033)
+++ /tattoo/branches/095dev/manager/includes/document.parser.class.inc.php (revision 2166)
@@ -2219,4 +2219,5 @@
         $t= preg_replace('~\[\!(.*?)\!\]~', "", $t); //snippet
         $t= preg_replace('~\[\((.*?)\)\]~', "", $t); //settings
+        $t= preg_replace('~\[\+(.*?)\+\]~', "", $t); //placeholders
         $t= preg_replace('~{{(.*?)}}~', "", $t); //chunks
         return $t;

If you can confirm this is the issue, and want to submit a patch for 0.9.6 final release, you have 2 hours.  Ha ha...just kidding (not really)   

EDIT: by patch, I mean a patch of eForm...

[pixelchutes]

Jason, Please see your PM. I have provided a link with a generic test case, not specific to eForm.

btw, I am confirming as we speak.

UPDATE:

I have commented out the PH section from stripTags:

    # Remove unwanted html tags and snippet, settings and tags
    function stripTags($html, $allowed= "") {
        $t= strip_tags($html, $allowed);
        $t= preg_replace('~\[\*(.*?)\*\]~', "", $t); //tv
        $t= preg_replace('~\[\[(.*?)\]\]~', "", $t); //snippet
        $t= preg_replace('~\[\!(.*?)\!\]~', "", $t); //snippet
        $t= preg_replace('~\[\((.*?)\)\]~', "", $t); //settings
        //$t= preg_replace('~\[\+(.*?)\+\]~', "", $t); //placeholders
        $t= preg_replace('~{{(.*?)}}~', "", $t); //chunks
        return $t;
    }

However, it didn't appear to have corrected the issue... hmmm

[TobyL]

@Jason, eForm only uses $modx->stripTags() on the POSTED values and not on the variables it receives from the snippet call so there must be something else going on.

Edit: Didn't see pixel's edit, so ignore me

[OpenGeek]

Yeah, I see that now, but can't see anything else obvious in the parser logic that has changed...   

[pixelchutes]

Can anyone else confirm on the 096RC3 build? I have a VERY simple test snippet + snippet call that illustrates the problem if anyone needs it.

Looks like PHx was the culprit! :x I wonder if there is a way to prevent this unwanted behavior?

[TobyL]

I've had a look through the PHx code. The problem as I see it is that  PHx doesn't distinguish between tags with a modifier and tags without modifiers.  Ideally PHx should leave tags without a modifier alone and let modx->parseDocumentSource() (or any snippets that use them) handle them.  I made some changes to the PHx code that does this for [+placeholder+] style place holders at least. This seems to alleviate pixelschute's problem.

Source from function ParseValues starting from line 83. Changes are commented.

Code:

<?php
   if ( preg_match_all('~\[(\+|\*|\()([^:\+\[\]]+)([^\[\]]*?)(\1|\))\]~s',$template, $matches)) {

      //$matches[0] // Complete string that's need to be replaced
      //$matches[1] // Type
      //$matches[2] // The placeholder(s)
      //$matches[3] // The modifiers
      //$matches[4] // Type (end character)

      $count = count($matches[0]);
      $var_search = array();
      $var_replace = array();
      for($i=0; $i<$count; $i++) {
         $replace = NULL;
         $match = $matches[0][$i];
         $type = $matches[1][$i];
         $type_end = $matches[4][$i];
         $input = $matches[2][$i];
         $modifiers = $matches[3][$i];
//MOD by JJC - skip if no modifier   
         if(empty($modifiers)) continue;
//end MOD
         $var_search[] = $match;

        //... skipped rest of code
   }

?>

Source from function Parse starting from line 51. Again, changes are commented.

Code:

<?php
function Parse($template='') {
   global $modx;
   // If we already reached max passes don't get at it again.
   if ($this->curPass == $this->maxPasses) return $template;
   // Set template pre-process hash
   $st = md5($template);
   // Replace non-call characters in the template: [, ]
   $template = preg_replace($this->safetags[0],$this->safetags[1],$template);
   // To the parse mobile.. let's go! *insert batman tune here*
   $template = $this->ParseValues($template);
   // clean up unused placeholders that have modifiers attached (MODx can't clean them)
   preg_match_all('~\[(\+|\*|\()([^:\+\[\]]+)([^\[\]]*?)(\1|\))\]~s', $template, $matches);
    if ($matches[0]) {
//MOD by JJC - skip if no modifier set - leave to document parser to deal with
   foreach($matches[3] as $key => $match)
         if( substr($match,0,1)!=':' ) unset($matches[0][$key]);
//end MOD
      $template = str_replace($matches[0], '', $template);
      $this->Log("Cleaning unsolved tags: \n" . implode("\n",$matches[2]) );
   }
  //... skipped rest of code
}
?>

This may not be the best and most generic solution but at least it avoids all kinds of workarounds without unwanted side effects (I hope anyway).

EDIT: According to BS this hack interferes with the recursive behavior of PHX. Look to the PHX support thread to see how things are going. I personally don't use PHX so I'll leave it to BS to tackle this issue further. I do think it is a "weakness" in PHX that needs addressing at some point.

[OpenGeek]

Good call TonyL; and just for reference, here is how I had similarly refactored the first portion of the phX functionality in 0.9.7, provided by the default modInputFilter class:

Code:

<?php
class modInputFilter {
    var $modx= null;
    
    function modInputFilter(& $modx) {
        $this->modx= & $modx;
    }
    
    function filter(& $element) {
        // split commands and modifiers and store them as properties for the output filtering
        $output= $element->get('name');
        $name= $output;
        $splitPos= strpos($output, ':');
        if ($splitPos !== false) {
            $matches= array ();
            $name= substr($output, 0, $splitPos - 1);
            $modifiers= substr($output, $splitPos);
            if (preg_match_all('~:([^:=]+)(?:=`(.*?)`(?=:[^:=]+|$))?~s', $modifiers, $matches)) {
                $element->_properties['filter_commands'] = $matches[1]; // modifier commands
                $element->_properties['filter_modifiers'] = $matches[2]; // modifier values
            }
        }
        $element->set('name', $name);
    }
}
?>

Only difference is I am doing this before the preg_match is ever executed (I wanted to avoid that overhead altogether, and the new parsing structure allowed me to do that easily).

[Uncle68]

I've read this thread but I still do not understand how to fix dynamic &to e-mail.

What do I have to do to make &to=`[+wu_email+]` to work? (I do have an input named wu_email in my template.)

Thanks!

[redman]

here is a snippet call that uses a dynamic 'to':

Code:

[!eForm? &sendirect=`1` &subject=`A friend has sent you something...` &thankyou=`STFemailOK` &formid=`STFform` &tpl=`STFform` &report=`STFemail` &to=`[+email+]`!]

in the above example, there is a form field called 'email' that takes the email address to use as a recipient.

it took me a while to work it out too. make sure you've got something similar to the above.

[Uncle68]

Thanks for the reply!

I believe that it is the &sendirect parameter that makes your snippet call to work, not the &to=`[+email+]` part. That is true for me at least, I've tried &to=`[+email+]` with no success. I need to be able to use form field values in the &to and &from parameters, and as far as I know it should work.

The &sendirect paramaters requires the email input to be named "email" and it's not possible to specify more than one e-mail addrerss with that one. For some reasons that's not enough for me, I need to be able to use for example &to=`[+first_email+], [+second_email+]` and so on.

From what I understand reading this thread this has been a problem for some others, but they seem to have resolved it, but I don't understand how.

[pixelchutes]

Thanks for the reply!

....I've tried &to=`[+email+]` with no success....

From what I understand reading this thread this has been a problem for some others, but they seem to have resolved it, but I don't understand how.

Exactly. This thread specifically targets the use of a placeholder (e.g. [+email+]) as a parameter in a snippet call (e.g. [!eForm? &to=`[+email+]`!])

The initial problem experienced was a result of the PHx plugin conflicting with the placeholder, and replacing it prior to ever being sent to the eForm snippet. The previous posts above are indicative of possible changes to PHx's parsing behavior to prevent the need for unneccessary "work arounds" at the snippet level.

[redman]

oh yeah... 

maybe you could use the 'sendirect' parameter, but also set up a function invoked by eFormOnBeforeMailSent to copy all of the email addresses into $fields['email'] that you want to send emails to. i haven't tried it, but it might work...

[pixelchutes]

oh yeah... 

maybe you could use the 'sendirect' parameter, but also set up a function invoked by eFormOnBeforeMailSent to copy all of the email addresses into $fields['email'] that you want to send emails to. i haven't tried it, but it might work...

You're exactly right. I had forgotten about sendirect param and ended up using it without a problem on another MODx instance. Luckily, eForm is one of the only snippets I regularly use that can require a placeholder as a parameter value, so sendirect was is nice save until this PHx issue can be resolved.

[TheWhippinpost]

Thanks for noticing this and reporting it.

I believe I've ran into the same problem when trying to use a PPP snippet placeholder within a snippet call to Googlemap.

For the hell of it, I attempted the above changes to PHx but it broke Jot output and didn't influence the problem to-hand.

I no longer believe it is a GoogleMap (snippet) problem but would appreciate sincerely if that could be confirmed by someone more intimate with ModX and possibly offer guidance too.

For quick reference; I do get a placeholder value within the GoogleMap snippet, but when the script queries the Google server, it's supposed to append the value onto the URL, instead, it actually appends the placeholder name, like thus: [+example+]

Many thanks.