Setting cron to be run as root

In Linux based distros, its very simple to setup cron for repeated tasks by using crontab -e for editing the crontab of the current user as you are logged in. You can view the contents of your crontab by crontab -l.

But if you need to call something with root privileges, its as simple as sudo crontab -e. This adds your changes to root user's crontab. To view root user's crontab, you can again do sudo crontab -l and you can see the difference.

Bonus tip: The first time you open crontab for editing, it opens it in vim. Those of you who are hardcore guys, know their way around, but they are not reading this anyway. I am not hardcode, I do know basic vim commands, but I like to use nano. If you are on the same boat as me, use this export EDITOR=nano. Now go get shit done!

Verify sending domain inside Mandrill without email hosting

Mandrill has enforced upon us that the only way to verify a sending-domain (domain used to send emails from) is by getting an email sent by them on an email of the sending-domain in use. So, if you use example.org or something.example.org to send emails, you can now only verify your sending-domain, by receiving an email from them on anyemail@example.org or anyemail@something.example.org in which you have to click on a verification link to validate your ownership of the domain.

Now that's not ideal. Add a TXT record is enough for verification purpose, and that's essentially the step that proves the ownership of domain through this step only but this is how it is.

The only issue with this approach is that one must have email hosting or an email inbox setup to receive emails on that domain. If you already have a working email on the sending-domain, you don't need to read the rest of the post. Simply, enter the working email for verification and get it over with. But if you don't, then instead of setting up email hosting somewhere for just verification purpose, you can utilize this trick I discovered. Its quick enough & free alternative to do so by simply using Inbound emails feature in Mandrill accounts.

Here is how to do it:

Add your domain under "Inbound domains"

screen-shot-2016-11-23-at-12-51-01-am

Now add MX record for your sending domain as per the instructions

screen-shot-2016-11-23-at-12-51-37-am

Add those MX records in your DNS and then validate those records are reflecting by clicking on "Test DNS settings".

Once confirmed, simply setup a route for that domain, by clicking the arrow on the right of "Test DNS settings" link.

screen-shot-2016-11-23-at-12-55-48-am

Configure webhook POST URL to a URL you obtained on https://requestb.in

screen-shot-2016-11-23-at-12-56-07-am

screen-shot-2016-11-23-at-12-57-20-am

Now go to verification of send domains, enter the email address you configured and wait for the email to come at your https://requestb.in/XXXXXXX URL.

screen-shot-2016-11-23-at-12-57-58-am

Find the link, copy and paste it in the browser.

And you are done!

Store Just WordPress Transients Persistently

WordPress comes with an option of keeping cache in a persistent storage, if provided. It provides a great deal of performance since everything that WordPress was doing repeatedly on each page request now can be saved in the persistent cache storage (APC / Memcached / Redis) and retrieve easily & very fastly without doing much work.

The way to activate that is to drop an object-cache.php file in your wp-content directory which does the heavy lifting for you. Following plugins are available if you want to get started with it:

You don't have a reason to not use object caching unless you are stuck with a plugin which doesn't follow WordPress standards and causes the site to malfunction when a persistent cache storage is used. An example of such a plugin is Wishlist Member plugin.

It simply doesn't work well with persistent object cache because it updates the options table directly by making SQL queries instead of using functions like get_option(), update_option() etc.

I needed to solve the problem, where we could atleast store some of stuff in the persistent cache & hence improving performance. The site for which this was done, is a learning portal where all members are logged in, hence full pages were generated dynamically every single time. To take off some of the load, I developed a plugin in which transients are stored in memcached (persistent storage) so that they can be retrieved very quickly without making SQL queries to the database.

I suggest you use this plugin or use it as a starting point to build what you need. Plugins of this kind, require installation & verification by a developer since its a very barebones-prototype plugin, which does the job of saving transients and retrieving them quickly.

Plugin's repository - https://github.com/ashfame/Store-Just-Transients-Persistently

It also overrides wp transient delete-all WP-CLI command so that you can flush transients from both database and memcached (persistent cache storage in use).

Its always a good idea to contribute back your work to the plugin if you build on top of it or extend it, so that other community members can gain from it.

Let me know if you have a question that I can help answer.