Ryan Hellyer

Glad to hear it’s working well for you 🙂

Is it possible that you have JavaScript turned off? the .hide-if-no-js class is presumably used for hiding content when JavaScript is turned off.

I can’t replicate this problem sorry. I installed Gutenberg and the Unique Headers plugin appears to be continuing to work as expected. This makes sense to me, as I wasn’t aware of them removing any hooks like those used in the Unique Headers plugin just to implement the Gutenberg interface.

• This reply was modified 8 years, 2 months ago by Ryan Hellyer.

Dangit. That’s not good :/ I’m not sure why this problem is occurring for you, but I will find some time in the next day or so to test this and get back to you about it.

Sorry I didn’t respond here already. I responded on the post linked to from here, but forgot about this one. I got a response from a WooCommerce person there who pointed out that newer versions of WooCommerce support an alternative system which uses WordPress pages.

You can read more about that here:
https://woocommerce.wordpress.com/2017/12/09/wc-3-3-will-look-great-on-all-the-themes/

This should work just fine with the Unique Headers plugin then.

I could theoretically add support for the original WooCommerce setup, but I don’t really feel that is a good idea, as WooCommerce should making their plugin work within the WordPress post system IMO, not creating magic pages which don’t actually exist within WordPress itself. If I did it for WooCommerce, I’d need to do it for every plugin which chose to do things that way, and it would take an enormous amount of work to keep up with them all. By forcing them to do things the WordPress way, will make the plugins more compatible with everything else.

I think some of these things will improve in WooCommerce over time, since it’s now maintained by Automattic.

Darn it. I was thinking this would be a simple change (it was), but I stumbled across a bug which is preventing the CAPTCHA fallback system from working. I’m trying to implement a fix for that now too, and will deploy both changes later.

The problem with basing it on time, is that aggressive caching systems don’t work with it. An old time stamp can become cached, and then the server will reject any comment submissions as it will look like the user is serving a stale time stamp.

It would be possible to bypass the cookie system entirely, but then you lose a tiny bit of protection too. An alternative protection system, could be to make the browser solve some sort of puzzle, which would add a little extra load and make it cost spammers more to process any javascript on the page. You can’t add too much extra load though, as it would cause problems on older mobile devices which may slow down when trying to crunch the calculation.

The plugin does use openssl_encrypt when it falls back to a captcha, but it would cause the plugin to fail on a lot of sites if it were implemented for the primary comment field (the captcha loads on an error page if the original comment form is rejected).

Thanks for bringing up the cookie issue. I hadn’t thought of that in relation to gpdr since it’s not there for storing any sort of useful data. At the very least, it may pay for me to add a better description to the plugin readme to ensure users understand that no personal information is stored in that cookie.

Awesome to hear it’s working so well for you 🙂 Thanks for the kind words.