v3.2 SSV, IV and SL are breaking plugin execution

Hi,

I have a form using both the "confirmation" plugin and the "profile page" plugin as well as server side validation (SSV). When I submit the form with an existing value, SSV generates an error and the form gets automatically redisplayed.

However when the form is automatically redisplayed (with the SSV resulting error at the top) it seems like the profile plugin is not doing its work. The symptom that I see is that only the SSV error is displayed but not the form.
This is caused by a piece of php code at the beginning of the form which uses {} that need to be replaced by the profile plugin with valid values. If the profile plugin is not doing its work the {} parts are not replaced thus invalidating my php code. Result: no form displayed.

When I switch off the confirmation plugin the profile page plugin works fine in the described scenario.

Is this a known issue ? Does anyone know how to resolve this. It seems like a bug to me.
(Oh and no it is not an option to move to v4).

Polderguy

Hi polderguy,

The Confirmation plug-in has been a problem for a long time :-( If I remember correctly it tries to replicate much of the ChronoForms code inside the plug-in and does a mediocre job with it. I think that the main problem is that Emails don't work correctly.

I suspect that the problems with handling this correctly were one of the reasons that Max re-built CFv4 in a much cleaner more modular form.

There are no fixes that I know of except to code your way round it (or not to use it); Max hasn't done anything with the CFv3 code for a couple of years now so I think you can conclude that it's now in it's final version.

Bob

Bob,

As always thank you very much for your response. Really appreciate it.
I only noticed your response today since I did not receive an automatic email informing
me that there is a reaction to my post. Weird, I'm pretty sure this worked in the past.
Perhaps it was filtered from my inbox as spam this time ...

Anyway I digged a little deeper into this issue and actually found the solution.
(And while debugging this one I also nailed another php warning error which was caused
by my SSV php code snippet ... yeahaa).
I must confess that this topic turns out not to be a bug after all.
Basically I have to write PHP code (in my form) that deals with the possibility
that {} is not substituted by the Profile Page plugin. This way the php code will
never get invalidated and thus break my form.

To give you an idea I replaced the following line of PHP code in the form:

$user =& JFactory::getUser({user_id});

with:

$userid = (int) "{user_id}";
$user =& JFactory::getUser($userid);

$user will end up with a different value when {user_id} is not substituted, but in
my case that's ok. At least the PHP code is now valid and therefor no longer breaking
the form when SSV returns an error.

Funny, how the smallest things can have the biggest impact.

Case closed.

Regards,

PolderGuy

Hi Polderguy,

In general you can't mix PHP and 'curly bracket' syntax as the PHP is run before the curly bracket substitution takes place. You an either use values from the $form->data array, or create your own as you did here.

Bob

Bob,

This is definately not true. Try it and you'll see.
The Profile Page plugin is doing the curly bracket substitution BEFORE the form is rendered.
It is only when the form is rendered that the php code is evaluated.

You can see in the code of the showForm() function inside the chronoform.php file that first
the plugins are run ($MyPlugins->runPlugin('', array('ONLOAD', 'ONLOADONSUBMIT'));) and then
the form is rendered (HTML_ChronoContact::showform( $MyForm->formrow, $posted);).

I know for sure it works this way since I have a form that clearly shows results that can
only be displayed when the {} parts in the php code are substituted before the php code is
evaluated.

Digging deeper into this topic I found there are actually 2 issues here:

1. There is definately a bug in the code of the plugins.php
In this file while looping through all plugins enabled on the form, at the end of a loop
the following code is executed:

<?php
...

//check for any errors reported by current plugin and halt the loop
if($MyForm->formerrors){
	break;
}
?>

Since the SSV code generated an error this means only the first plugin (confirmation_page)
is run when redisplaying the form. In other words the code does not distinguish between a SSV
error or a plugin error.
This is why my profile_page plugin (or any other plugin) is not run after the SSV error.
When I switch off the confirmation plugin the profile page plugin will be run again since it
is the only one and thus first.

In short, when a SSV error occurs while submitting a form, the form gets redisplayed (showing
the SSV error at the top of the form) and then only the first plugin associated with that form
will be run. I'm pretty sure this is not correct.

When a SSV error occurs and the form gets redisplayed ALL plugins associated to the form should
run. And it seems it is not only SSV breaking plugin execution.
When a form is submitted there are 3 checks done (in order of appearance/execution):

1. Submissionslimit (SL)
2. Imageverification (IV)
3. Serversidevalidation (SSV)

When SL and/or IV produce an error the same problem occurs.

2. I'm passing a URL argument (&id=111222) in the form which is picked up by the Profile Page
plugin to lookup and substitute several curly bracket (hidden) fields in the form.
When a SSV error occurs on submitting the form the URL argument is lost.
The same issue occurs when I click on the Back button from the confirmation page.

It looks like there is a setting called Relative URL on the general tab in v4 that offers
some control over URL arguments. But I don't believe this is available in v3.2.

I would appreciate your thoughts on this.

(Oh, I've changed the title of this topic to match my latest findings)

Regards,

Polderguy