Nginx compatibility for “Cookies for Comments” plugin

Whether you are aware or not, spammers are more interested in your site than anyone else. You’ll understand this more vividly, when your blog starts to become famous and brings more and more visitors week after week, month after month, year after year.

The most annoying thing about spam comments is the amount of time that you need to waste in dealing with it. There are some bright minds in WordPress that help you save your time with spam comments. One such person is Donncha, who put together a nice plugin named Cookies for Comments that blocks the spam at the server level, in such as a way, it doesn’t even reach WordPress. Because, all the work is done by the server itself. Here, we show an example code for Apache and Nginx web server. It could be migrated any web server in general.

Integrating with Apache is straightforward. The code to configure Apache is displayed at the bottom of plugin’s settings page at It’d look like this…

# If you're feeling adventerous, you can add the following two lines before
# the regular WordPress mod_rewrite rules in your .htaccess file.
# They will stop comments from spambots before they reach
# the database or are executed in PHP:

RewriteCond %{HTTP_COOKIE} !^.*abcdefghijklmnopqrstuvwxyz0123456789.*$
RewriteRule ^wp-comments-post.php - [F,L]

In the above code, the value of abcdefghijklmnopqrstuvwxyz0123456789 may change for each site. It is also part of the name of the cookie set by this plugin.

In Nginx, the code is little different. Here’s the actual code…

# support for cookies for comments plugin!
location = /wp-comments-post.php {
    if ($http_cookie !~* "abcdefghijklmnopqrstuvwxyz0123456789") { return 403; }
    # rest of the code to process PHP.

Considering Akismet can not be used on a commercial site, this solution works great. With Akismet, there is a lot going on behind the scene. With ‘Cookies for Comments’ plugin, a cookie is set for all the visitors and it is checked when a comment is posted by the same visitor. Since, this plugin sets a cookie for all visitors, you may use GDPR consent to include this cookie at the top of every comment form. At least, you could inform about cookies before they comment like how it is done on this site’s comment box…

comment form with cookie warning
Sample comment form showing a warning of cookies being used!

By adding just two lines of code, we can save a lot of trouble and frustration in the long run. If you have any other method to tackle spam, please share it in the comments!

Handling WordPress Cron failures using wp-cli

To understand WP cron, let me quote the following text from Cavalcade documentation

wp-cron is not actually a real task scheduler, and doesn’t actually operate like cron. Instead, it’s a pseudo-cron system, which is run as a loopback HTTP call when you access a page on the site (essentially, the page “forks” itself to run scheduled tasks). This is fine for high traffic single-sites, but lower traffic sites might not have their cron activated if the site isn’t viewed.

As you can see, even if a site has moderate traffic, if the site uses aggressive caching techniques, it is possible for real traffic to never hit PHP or WordPress to process a request. When wp-cron fails, a number of things can fail… a scheduled may not get published on time, a newsletter may not be sent as scheduled, an important WordPress security may not be applied, a backup schedule may have been missed, etc.

Cavalcade offers an excellent way to prevent such failures. It is more suitable for multi-site networks with hundreds of cron entries. For single sites, it is easier to handle a failure in wp-cron using wp-cli tool and a server cron.

Most common alternative is to disable internal WP cron and trigger it externally using wp-cron.php file and a server cron. If you are using this alternative method, then please remove cron entry and remove the corresponding entry in wp-config.php file, as wp-cli wouldn’t work if internal cron is disabled.

Let’s make sure we are ready to use the internal wp-cron by running the following command…

wp --path=/path/to/wordpress cron test

You’d see a success message… “Success: WP-Cron spawning is working as expected.“.

Most common error message is… “Error: The DISABLE_WP_CRON constant is set to true. WP-Cron spawning is disabled.” In this case, please disable the line in wp-config.php that disables wp-cron.

Now, it is time to set up a server cron that runs every minute like this…

* * * * * /path/to/wp-cli --path=/path/to/wordpress cron event run --due-now &> /dev/null


The 5 stars indicate a schedule to execute the command every minute. The command that follows executes cron events that are due now. Please make sure you provide full path to wp-cli and your WP site installation directory. I have tested the above in multiple sites on various servers. So far, it has been the most effective way to handle the failures in WP-Cron gracefully on single sites. If you run a multi-site network or a complex site with hundreds of crons, I’d highly recommend Cavalcade.

Excluding iPad from wp_is_mobile!

Mobile Detect Logo
Mobile Detect Logo by Dragoș Gavrilă!

wp_is_mobile function in WordPress considers iPad as mobile! This scenario creates issues on iPad, iPad Pro, or any relevant tablets. To be precise, iPads are shown a mobile version of a site rather than the desktop version! Searching the internet didn’t yield a clean way to overcome this situation. Heck, there are even plugins to detect mobile devices and to exclude iPads from being mobiles.

Continue reading “Excluding iPad from wp_is_mobile!”

WP Rocket – Nginx configuration

I prefer open-source software and have been a long-time advocate of OSS in general. Recently, I started liking WP Rocket plugin that offers some unique features. I already have a perfect Nginx configuration for WP Super Cache plugin (that I consider as the best full-cache plugin till date). Since, WP Rocket uses disk caching like WPSC, I wanted to quickly convert the existing configurations to fit WP Rocket. I did succeed in it and you can find it in my WordPress-Nginx repo. Here I explain how WP Rocket stores the cached content and how it could be integrated into Nginx.

Continue reading “WP Rocket – Nginx configuration”

Introducing Preload Fullpage Cache

Situation #1

Right after creating my first WordPress plugin, Auto Maintenance Mode, I came across a situation on a high-traffic blog where the visitors just rush to the website immediately after a blog post is published and shared (automatically) via social media. It created chaos in the server and the initial visitors didn’t get the cached version of the blog post, because it wasn’t even ready.

Continue reading “Introducing Preload Fullpage Cache”

WordPress Plugins and Themes – Bad Business Practices

It isn’t uncommon to see freemium plugins in the official WordPress repo. The basic functionality of the plugin would be free. Some fancy features would come with a premium price. There is nothing wrong with such business model. What’s bad (business model) is switching the free features into paid features without notification. How does it feel if WordPress Foundation started charging a small fee to use the theme customizer?

Continue reading “WordPress Plugins and Themes – Bad Business Practices”

Recommend Settings for Redis Object Cache Plugin

WordPress Object Cache system allows transients to be stored in object cache backend, such as APC, Memcached or Redis. Without an object cache, the transients are stored in the database itself. This is the default. You could verify this yourself by looking at the (wp_)options table in the database. Fortunately, we have options to store these transients in the memory using one of the backends mentioned above. Among these, Redis has become stable and is production-ready. There are two WP plugins available that use Redis as WP Object Cache. First one is Eric Mann’s plugin. The second plugin is by Till Krüss who forked the former and made it better.

Continue reading “Recommend Settings for Redis Object Cache Plugin”

Automatic Maintenance Mode

Often, I create a development site, such as, or, before making any change in the production site. I even have a dedicated server to host the dev site of all my clients. If you don’t have a development site on your own, please do create it. It’d save you a lot of time in the future. Your production site might become overnight success and you can’t afford to tryout important changes in the production site.

Continue reading “Automatic Maintenance Mode”