webaware

G’day Eric,

You have JavaScript errors on your page, caused by overly-aggressive optimisation of your script loads. Please tell Autoptimize to exclude the jquery script so that it can load in the head where it needs to load for scripts on your page.

cheers,
Ross

No worries!

G’day Alex,

Your theme is suppressing the validation message. Use your browser’s Inspect Element tool to see what I mean: right-click on the Cardholder Name field, and look below it for a div element with classes gfield_description validation_message and you’ll see the validation errors on that field. It comes from your stylesheet:

.multistepform .validation_message {
    display: none !important;
}

cheers,
Ross

Thanks for the update. I’ve heard of that option in W3TC stuffing up other things too. Essentially it seems to break transient caching. Given that transients are stored in the database unless you have memcached / redis / apt etc. (which are better), I don’t understand what W3TC is trying to achieve there.

Well done on figuring it all out!

cheers,
Ross

G’day Liam,

If the whole eWAY transaction is completing, then the transaction component was successful and it’s likely something else within the checkout page that is failing. And error 500 is a server-side error, so check your server logs to see what they say.

You can find your website error log through your hosting control panel, usually under a button called Logs. If you’re not sure where to find it, you can tell WordPress to write errors to the file wp-content/debug.log by editing your wp-config.php file. Find the line that says:

define('WP_DEBUG', false);

And replace it with this:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

NB: you should change it back when you’re finished, because debug mode slows your website down a bit!

cheers,
Ross

The 3 errors in the static analysis bit probably just means the phpMyAdmin doesn’t understand MySQL delete syntax very well; ignore those.

The actual problem reported is that you’re getting a deadlock. Quite likely, there are so many rows to search for and delete that it’s taking too long and hitting lock conditions with other processes.

If your system can withstand a little downtime, you can try locking the options table during the delete operation, like this:

set autocommit=0;
lock tables wp_options as t1 write, wp_options as t2 write;
delete from t1, t2 
	using wp_options t1 
	join wp_options t2 on t2.option_name = replace(t1.option_name, '_timeout', '') 
	where (t1.option_name like '\_transient\_timeout\_%' or t1.option_name like '\_site\_transient\_timeout\_%') 
	and t1.option_value < '1509330263';
commit;
unlock tables;

cheers,
Ross

Thanks for your feedback. I suggest that it might be more effective to provide feedback to eWAY themselves, however. Your review makes it look like I’m somehow responsible for your bad experience with eWAY.

cheers,
Ross