Plugin Author
DCoda
(@dcoda)
Can I ask what version you are running.
You need to be running version 1.7.1. Subsequent version had problems depending on how your php was configured and have been removed until things can be sorted for all systems. And older versions are not support as we want people to upgrade.
I have just tested version 1.7.1 and the responses do update correctly.
As for the private response, it too is working, I take it that you have set the form to private. Please note that the form will still be displayed to attract vistors into signing up, the private message is displayed instead of the submit button only.
If you are still having problems then it must be something to do with your configuration and we will need more information about that to sort the problem.
Regards
D
we are using WP development version (3.1-RC2-17283).
and 1.7.1
Plugin Author
DCoda
(@dcoda)
Not sure what the problem could be as when i read the post i tested 1.7.1 on our current dev version with is 3.1
Does the problem happend with all forms you create?
what is the form name, sometimes spaces or other characters have been causing problems with the saved settings. But this would also affect the fields too.
Please check that you have selected the correct form in the page. This is a mistake I have made myself.
Regards
D
Hello DCoda,
I’m working with latte62 on this issue we’re having. Can you tell me where/how the custom responses get saved? For example, the thank you repsonse that is served upon submission.
I don’t see it in the database table for the form we’ve created. We have updated/saved the thank you response in our form, but it seems to still be loading up what is in the wp-survey/library/survey/Views/SurveyMe/Responses/ThankYou.phtml template file. This is happening for all the forms we create and we have double checked the naming. If I manually edit the file mentioned above, I do see those changes. Otherwise changing the custom response of our form doesn’t seem to be affecting anything that we can see.
Thanks!
Plugin Author
DCoda
(@dcoda)
The custom responses are saved in the wp-options table along with all of the form settings.
Its odd that it is saving the changes to the form but not the responses.
Once a survey is created and saved it should always use the saved copy.
For now if you change the originals, but remeber to take a copy as updating will overwrite them.
Hopefully this might be solved in the next release, but its hard to understand what the difference is about your system.
-D
Thanks. I am seeing our custom responses in the wp_options table. So the issue seems to be with the loading of them. Any advice on how to debug that? I can’t tell where it pulls that data.
Plugin Author
DCoda
(@dcoda)
This has all changed in the version we are currently working on.
But I’d be very interested to know what the problem is since it should work the same on all systems. That being said we did have to scrap a few versions due to the way INI support was implemented differently.
The settings are loaded from the defaults and combined with any changes here.
/library/survey/s9v/forms.php -> function settings
The decision to display the responses from saved responses or load them from files is made here.
/library/survey/s9v/forms.php -> function renderScript
I take it the rest of the settings are okay
DCoda,
I think I might have identified and fixed the issue. It took a lot of debugging and some guessing, so I’ll run it past you for feedback.
In wp-survey/library/survey/s9v/form.php, the render_Marker($match) function has a while loop that looks like this:
do {
$this->view->Settings = $this->s9v_forms->settings ();
$this->s9v_forms->set_form ( strtolower ( $this->view->Settings ['form'] ) );
} while ( strtolower ( $this->s9v_forms->form () ) != strtolower ( $this->view->Settings ['form'] ) );
That loop seemed to be resulting in the default values for the custom thank you response. Tweaking it a little seems to fix it for me. This is what I’ve tried and seems like is working in place of the above while loop:
$name = FALSE;
while (!$name) {
if(strtolower ( $this->s9v_forms->form () ) == strtolower ( $this->view->Settings ['form'] )) {
$name = TRUE;
}
$this->view->Settings = $this->s9v_forms->settings ();
$this->s9v_forms->set_form ( strtolower ( $this->view->Settings ['form'] ) );
}
As an FYI we are running PHP 5.2.16.
Plugin Author
DCoda
(@dcoda)
I’m glad you managed to sort this.
I’m not seeing any logical difference between both sets of code, so it must be down to the syntax.
Settings have totally been rewritten in the current development version so this should not happen when it is release, though I would recommend that you take a copy of your own changes just in case.
DCoda, do you have an estimate as to when the new version will be available?
Plugin Author
DCoda
(@dcoda)
No estimate.
This is a big redesign to minimise issues that keep cropping up due to different os’ and configs of php.
There is a lot of testing involved and we want to make sure it is right when it is released.
Plugin Author
DCoda
(@dcoda)
Actually as a very rough timeline.
All the new features are now set. And we are currently bringing all our current plugins up to the same version of the library framework.
This should be completed by the end of the week. Then full testing of all plugins on in the development environment with any fixes necessary.
Then testing on a secondary server to check for problems with other os’ and configurations.
Then finally we will release some of the smaller plugins that use the same framework to see how they go down in the wild.
If all goes well we then release the formplugins.
Regards
D
