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.

Override WP-CLI commands

If you already don't know about WP-CLI, its a pretty great tool to manage a WordPress install via terminal commands. This essentially gives you a lot of power enabling you to interact with the WordPress install just by commands and not having to interact with UI at all. Read more at WP-CLI's homepage.

It can also be extended to add custom commands. The usual way to do can be read in detail here - https://github.com/wp-cli/wp-cli/wiki/Commands-Cookbook but the essence is to create a new PHP Class extending from WP_CLI_Command and then just add that class as a handler for a command by calling WP_CLI::add_command().

Now for instance, what if you want to redefine an existing wp-cli command? The way to do that is to create a new PHP Class as if you were creating a new custom command, and then instead of extending it from WP_CLI_Command, extend it from the PHP Class which defines the command you want to override. Simple enough! Here's an example:

wp transient delete-all lets you delete all transients from the database. Yes, database. If you know about persistent caching storage options with WordPress like Memcache or APC, then transients are not actually stored in database anymore. They are simply stored in the persistent cache storage. And since the delete-all subcommand of transient command only runs a SQL query to delete them from database, it simply does nothing if the site uses persistent cache storage (Object cache drop-in object-cache.php, if that reminds you of it).

So you can define a new PHP Class something like this:

<?php
if ( defined('WP_CLI') && WP_CLI ) {
class Transient_Mod_Command extends Transient_Command {
public function delete_all() {
// new definition of delete-all subcommand
}
}
WP_CLI::add_command( 'transient', 'Transient_Mod_Command' );
}
view raw override-wp-cli-command.php hosted with ❤ by GitHub

Pretty straight-forward, right?

Using the same technique, you can add new sub commands to an existing command as well by simply defining a new method.

On the transient issue note, why that shouldn't be fixed in WP-CLI itself is a question that intrigues me as well. From a quick look at their Github issues, seems like they want to support it in a way it works correctly with persistent cache storage, but haven't got to that place yet. I will see how soon I can create a patch for it and send a pull request.

Have fun with WP-CLI!

Filtering transient expiration time in WordPress

As of now WordPress, doesn't offer a filter to control the expiration of the transient while its being set, so I quickly wanted to share a quick snippet I found on Trac, written by Andrew Nacin.

Here is the snippet:

<?php
add_action( 'set_transient_my_transient', function( $value, $expiration ) {
$desired_expiration = 600;
if ( $expiration != $desired_expiration ) {
set_transient( 'my_transient', $value, $desired_expiration );
}
});
view raw filtering-expiration-transient-wordpress.php hosted with ❤ by GitHub

Basically, 'set_transient_' . $transient hook is fired once the transient gets saved, so it saves itself again resulting in recursion as the same hook will be fired again, but before it saves itself again, it checks whether the $desired_expiration is different from the $expiration with which it's being saved. Smart!

On a side note, if you ever need to do this, don't use anonymous functions because that takes away the ability to unhook your function by someone else. Its just a quick way to demonstrate the idea.

Concerned Trac Ticket - https://core.trac.wordpress.org/ticket/21330

Quickest way to get timestamp of a time in a particular timezone in PHP

Playing with timezone conversions can be crazy, it still confuses me every time and I have to wait a minute to run some test code to figure out what's it that I am trying to do here.

Anyway, the quickest way I have to get timestamp of a time in particular time zone is

DateTime and DateTimeZone classes are what you need to know when dealing with timezones, ditch any other method of doing conversions in PHP. Seriously, there are no better ways of doing it.

And just a tip, if you already don't know, timestamp from different timezones for a single point of time is same. It doesn't depend on the timezone. Did you know? 🙂

Let me know in the comments if you have a question.

How to use a single image on Facebook when your website is shared

Ideally, you would want to use context specific images to be shown on Facebook whenever any page of your WordPress website is shared on Facebook, but if for some reason you want only a single image to be shown irrespective of the context, that can be configured using my plugin - Facebook Like Thumbnail though it specifies context specific images by default.

You need to install the plugin, configure the default image to be used from the settings page. And then paste the following code in your functions.php file:

This short-circuits the logic of the plugin and specifies the default image specified in settings to be used for all pages.

I see this use-case as being very limited to what everyone would want, so I don't want this to be added as another option in the plugin itself, but it can be achieved using short-circuit opportunity offered by the plugin's architecture. Even if you want to plug in custom logic to figure out the image to use, that's possible too.

Let me know if you run into any issues.