|
Jeffrey Carter
|
March 15, 2016 at 8:37 am
The error is a common one, but thus far the common fix (disabling caching for the affected pages) has not fixed the problem. The error is “An error has occurred: First Name: Field is required” etc. Even with all of the question fields complete, this error occurs for all the fields when “proceed to payment options” button is pressed.
With all caches flushed and CDN files replaced, I can’t shake the error… Even on a fresh browser.
I suppose we could be having a conflict with another plugin, but I’m not seeing any javascript errors.
But my hunch is that we are still having a caching problem, and I have a setting messed up… though what?
Here is the output of w3-total-cache for the /registration-checkout page showing caching off.
<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/
Minified using disk (Request URI is rejected)
Page Caching using disk: enhanced (Requested URI is rejected)
Database Caching using memcached (Request-wide Request URI is rejected)
Object Caching 5471/5535 objects using memcached
Content Delivery Network via static.rockbrookcamp.com
Application Monitoring using New Relic
Served from: rockbrookcamp.com @ 2016-03-15 09:21:58 by W3 Total Cache -->
I am running w3-total-cache 0.9.4.1 and this:
WordPress Version:
4.4.2
PHP Version:
5.4.45
MySQL Version:
5.5.47
Event Espresso Version:
4.8.35.p
Is there another tweak to my caching plugin I can try? Or, is there a way to track down some kind of incompatibility?
Thanks,
Jeff
|
|
Josh
|
March 15, 2016 at 10:04 am
Hi Jeff,
I wanted to let you know that we’re looking through the site right now. Part of the problem is caching because the cache exclusion rules for specific pages only affect the Page caching feature of W3TC. The database and object caching will need to be disabled for this one site in order to use Event Espresso because those can’t be disabled on specific pages.
I’ll update this thread with more information as we continue to troubleshoot.
|
|
Jeffrey Carter
|
March 15, 2016 at 11:11 am
Thanks Josh,
I would prefer to not turn off the caching for the entire site, if possible
One idea: I have had some luck fixing another plugin by adding a database stem to “Ignored Query Stems” in the w3-total-cache database settings. Perhaps there is something specific about the EE database access that can be defined?
Another idea: I wonder if this can be traced to using memcached… ?
|
|
Josh
|
March 15, 2016 at 11:30 am
You can use Page caching, and you’re welcome to try to get database caching working, but it’s not supported because Event Espresso relies on everything to be dynamic.
The other issue we’re seeing is there’s something from the WordPress child theme that’s causing some breakage. You’ll note that if you use the Theme Test Drive plugin and as the admin use the Genesis parent theme in test drive mode, the registration form validation works as expected.
|
|
Jeffrey Carter
|
March 15, 2016 at 11:40 am
I thought we had database caching working since it too has a per page exclusion option, and it looks like the debug data from w3-total-cache is showing this. Object cache seems different though.
I’m not sure how to fix a theme related issue. Is there something I can investigate?
|
|
Josh
|
March 15, 2016 at 12:07 pm
It may help to contact the author of the child theme to investigate. It appears that there’s an interaction between something in the child theme and another function on the site that’s causing some invalid html on the page that handles the registration, which is leading to the form validation not working.
|
|
Josh
|
March 15, 2016 at 12:20 pm
Update:
We’ve narrowed the theme issue down further to the sidebar widget content. You’ll note that right now, the registration-checkout page has been set to show no sidebar (and therefore no sidebar widgets). With this change, the form validation works as expected.
|
|
Jeffrey Carter
|
March 15, 2016 at 12:30 pm
Good catch! Now if we can narrow down which sidebar widget, we can retain the main structure of the page. Since 3 of the installed widgets are custom and from a much earlier version of the site, I can imagine there’s an issue. Do you have a sense of how to narrow down the issue further?
|
|
Josh
|
March 15, 2016 at 12:44 pm
Can you try systematically removing one widget at a time from the sidebar on that page and then test for breakage each time?
|
|
Jeffrey Carter
|
March 16, 2016 at 7:41 am
OK, I found the culprit. It was a “Network Wide Recent Posts” Widget. I’m not sure why it was causing the trouble, but with that widget removed from the sidebar, the registration is working even with w3-total-cache activated as page, database and object caching.
Problem solved! Thanks for helping troubleshoot the issue.
|
|
Josh
|
March 16, 2016 at 8:13 am
Hi Jeffrey,
If you get any feedback from registrants where they say they can’t register (because of errors) you’ll likely need to turn object caching off.
|
