next »

[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.

[Dimmy]

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.

I tried this hack but it does not work in my case. looks like the plugin is not working anymore the phx tags are not processed at all.
is there another way to fix this? or maybe somone could atach a hacked/working phx parser that works well togetter with eform on one page, for me to use?

Dimmy

[SteveoSupremo]

So I was going to post something similar to this until I read this thread....  I too am using modx .96 and PHx 2.1.2 and I can't get the &from=`[.email.]`  or &subject=`[.name.]`to work as well.

 it seams about a month since the last post.  so has anyone come up with a viable work arround or updated PHx or something?

thanks
SteveO

[pixelchutes]

So I was going to post something similar to this until I read this thread....  I too am using modx .96 and PHx 2.1.2 and I can't get the &from=`[.email.]`  or &subject=`[.name.]`to work as well.

 it seams about a month since the last post.  so has anyone come up with a viable work arround or updated PHx or something?

thanks
SteveO

Not ideal, but I have created a work around specific to eForm when PHx is enabled. This should be considered temporary until a proper fix is formally released.

I added the following code around line # 94 of the eForm snippet itself (not the eForm include file)

if( $params[from]{0} == '(' ) $params[from] = str_replace( array('((','))'), array('[+','+]'), $params[from] ); // pixelchutes PHx workaround

NOTE: This implementation is specific ONLY to the &from parameter. It can easily be modified to account for multiple parameters.

Then, simply pass placeholder names like ((this)) instead of [+that+] when passing as an eForm parameter.

This is not a *solution* to the problem, rather an eForm specific work around. I recommend modifying the eform snippet description to denote that you have modified it from its original state, something like this:

<strong>*custom* 1.4.4</strong> Robust form parser/processor with validation, multiple sending options, chunk/page support for forms and reports, and file uploads.

[SteveoSupremo]

Thanks pixelchutes

Code:

if( $params[from]{0} == '(' ) $params[from] = str_replace( array('((','))'), array('[+','+]'), $params[from] ); // pixelchutes PHx workaround

worked well I did mod it a little more to include

Code:

if( $params[from]{0} == '(' ) $params[from] = str_replace( array('((','))'), array('[+','+]'), $params[from] ); // pixelchutes PHx workaround
if( $params[fromname]{0} == '(' ) $params[fromname] = str_replace( array('((','))'), array('[+','+]'), $params[fromname] ); // pixelchutes PHx workaround

I just need to figure out how to get it to work in the subject as well

THanks again
SteveO

[Dimmy]

MM I did a bit more drastic thing and changed the eform.inc.php, so that instead of [+placeholder+]  it looks for ++placeholder++ works great on all places so validationmessage should also be called ++validationmessage++ same goes for all the placeholders used in the call like

Code:

&to=`++email++` &from=`++email1++` & fromname=`++name++` &subject=`++name++ wants to show you this awesome page`

and placeholders used in reports and chunks etc.

This is not a permanent solution but just until there is a PHx version that leaves them in place.

greets Dim

[Dimmy]

Thanks pixelchutes

Code:

if( $params[from]{0} == '(' ) $params[from] = str_replace( array('((','))'), array('[+','+]'), $params[from] ); // pixelchutes PHx workaround

worked well I did mod it a little more to include

Code:

if( $params[from]{0} == '(' ) $params[from] = str_replace( array('((','))'), array('[+','+]'), $params[from] ); // pixelchutes PHx workaround
if( $params[fromname]{0} == '(' ) $params[fromname] = str_replace( array('((','))'), array('[+','+]'), $params[fromname] ); // pixelchutes PHx workaround

I just need to figure out how to get it to work in the subject as well

THanks again
SteveO

try this:

$params[subject] = str_replace( array('((','))'), array('[+','+]'), $params[subject] );

I use this in my snippet:

Code:

if( $params[to]{0} == '(' ) $params[to] = str_replace( array('((','))'), array('[+','+]'), $params[to] ); // PHx workaround
if( $params[from]{0} == '(' ) $params[from] = str_replace( array('((','))'), array('[+','+]'), $params[from] ); // PHx workaround
if( $params[fromname]{0} == '(' ) $params[fromname] = str_replace( array('((','))'), array('[+','+]'), $params[fromname] ); // PHx workaround
if( $params[replyto]{0} == '(' ) $params[replyto] = str_replace( array('((','))'), array('[+','+]'), $params[replyto] ); // PHx workaround
$params[subject] = str_replace( array('((','))'), array('[+','+]'), $params[subject] ); // PHx workaround

greets Dimmy

[Compeek]

Thanks for these solutions, guys. A year and a half later, and they're still necessary! I suppose it's frustrating the PHx still hasn't fixed this, but at least there's people on top of things.

[pixelchutes]

Thanks for these solutions, guys. A year and a half later, and they're still necessary! I suppose it's frustrating the PHx still hasn't fixed this, but at least there's people on top of things.

@Compeek,

You may prefer to use this simplified version (now comes standard with eForm 1.4.4.6):

// pixelchutes PHx workaround
foreach( $params as $key=>$val ) $params[ $key ] = str_replace( array('((','))'), array('[+','+]'), $val );