Mandrill decides to discontinue service as a separate product

Mandrill has decided to discontinue their service as a separate product and is becoming a transactional email add-on to paid MailChimp accounts.

This means the free 15000 emails/month service which Mandrill offered will soon be no longer available. All Mandrill users will be required to have a paid monthly MailChimp account.

Here are the timelines

  • Starting March 16, all new Mandrill users will create accounts through MailChimp.
  • Also starting March 16, Mandrill users can merge their existing Mandrill account with a MailChimp account.
  • Current users will have until April 27 to merge the accounts.

So what are the alternatives:

Generally Mandrill is used to send transactional emails like password reminders, notifications, etc taking the load off your own webserver. There are quite a few services which allow to send such transactions emails

  1. Amazon SES (this is the option recommeded by MailChimp)
  2. MailGun (10,000 emails/month free)
  3. SendGrid (12,000 emails/month free)

Moving wordpress site to a new server

Moving wordpress site or  any other site requires transferring atleast below mentioned files and settings to the new server

  1. Code and Media files residing in your public_html directory
  2. Database
  3. Cron Jobs
  4. Any Back up scripts or other shell scripts, snippets, config files, etc residing outside your public_html directory

Some hosting companies like Siteground also provide free website transfer. However for number of reasons like complexity or security you may decide to perform the migration yourself.

Below steps explains moving wordpress or any site from one server to another without using FTP or without requiring to download an upload files on your PC.

Here are the steps for moving wordpress site

1. Clean up your old server and remove any unnecessary files or directory

2. Create a tar file from the entire public_html directory contents

SSH to your legacy server and run below command

3. Create an SSH key

To accept data from the legacy server, an SSH key from the legacy server is required to be added to the known hosts file on the new server. This key can be directly appended to the text in the known hosts file if you have access to it or some hosting providers provide a panel to add the key and to restrict the connection from certain IP addresses. Here you can provide the legacy server IP address.

The above command will generate dsa key. You can create either RSA or DSA key. Some hosting companies only accept certain type of key.

After running the above command the key will get created in your .ssh directory. Copy the contents of the public key and add them to the new server to accept connections from the legacy server

4. Moving wordpress public_html folder contents

Above command will copy the public_html contents from the legacy server to the new server’s public_html directory. You will required to Unarchive the contents on the new server.

5. Export database on the legacy server

Here you can use utility of your choice or you can just create a mysqldump of your database. If you are using some utility like SXD then create a copy of database on the legacy server using SXD.

Then move the database to the new server using below command

6. Import the database on the new server

First create a blank database on the new server and then import the database. If you have database backup created using SXD then install SXD on the new server and import the database on the new server through SXD.

7. Other Data (outside public_html)

If the data is not too much you can just tranfer this data using FTP or follow the same process as explained in Step 4

8. Cron Job

Lastly create similar cron jobs on the new server and check if they are working


Adding a plugin textdomain / translation into wordpress

A plugin textdomain is required if you need to translate your own plugin in different langauges i.e. to internationalize the plugin.

Here are the required steps

Step 1: Decide the plugin textdomain name

e.g. my_plugin_textdomain

Step 2: Initialise the languages directory for the plugin textdomain

Add below code to your plugin

Create languages folder within your plugins directory.

Step 3: Create PO file for the languages

If you are creating a language translation for German then you would need to create a po file with below name


Download a sample PO file

Open the file in a suitable text editor and add the necessary translations in the file

Step 4: Create MO file

Once all the translations are added to the PO file open the file in Poeditor and just save the file. Poeditor will automatically create corresponding mo file. Upload both the files on your plugin languages folder


For the translation to show up for the corresponding words or phrases __(“sample text”) is to be used within the plugin code.

When to use Database Triggers ?

What are Database Triggers ?

A Database trigger is an SQL code which is made to run just before or after a certain event. That event could be an INSERT, UPDATE or a DELETE query on a particular database table.

Thus a trigger is used to automate some of the events on your server/site/application.

Examples of some Database triggers

  1. Sync user details from one table to another when a user updates them
  2. Geocode users location and store them in a separate table
  3. Maintaing log of certain events e.g. a product addition, updation or deletion (In this case we wish to know who did the change)

When to use Database triggers

There are few pros and cons about using database triggers.


  1. Yes they can automate quite a lot of activities
  2. For things like maintaining logs if you are doing this through your code then most probably you need to add the piece of code in a number of files. e.g. If you are maintaing a log about article updates then there may be a number of files in your code related to updating articles. You will need to add the log related code in every file. But if this is done through trigger then you do not need to worry about updating your code.
  3. In the above example if the log table structure changes then you just need to update your trigger code and you are done.
  4. Triggers are very handy in case you have completely different systems on different platforms and coding is not really possible. This is mostly the case in large organisations.


  1. Since the trigger is not part of your normal code it may create lot of confusion later as to how certain things are happening especially if you are new to the system and things are not properly documented. Due to this lot of people prefer to write event driven procudures in their code instead of creating triggers as that way they are in full control of the application.
  2. If the business logic changes then the triggers can be difficult to handle/update. At that point of time it may happen that a certain event may not be possible through a trigger and you may need to revert back to your usual way to handling events through your code. This may further increase development time.


Based on the above pros and cons we can understand that using a trigger or not is not really a straightforward decision. It really depends on case by case basis.

  1. If you are coding in an object oriented manner then most probably you are writing all your events in structured manner and there is no duplication of code. In that case it becomes quite easy to add the event based procedures within your code.
  2. However in some cases the code is not object oriented as it may be quite an old application. In that case you can make a judgement call whether its the time to update the code or create triggers.
  3. In case 2 if the code is done by some other developer then it is likely that you would use triggers.
  4. For applications built on different platforms or different scripting languages sharing common resources triggers can be handy to achieve some form of integration.




WordPress REST API v2 Examples

Here are a few examples on how to use WordPress REST API v2

First of all Download and Install the plugin just like any other wordpress plugin

Get list of posts

Get list of pages

WordPress REST API for Custom Posts

Prerequisite: REST API support needs to be added to custom posts while registering the custom post.

Below parameters add the necessary support. For detailed instruction please refer Adding REST API support to Custom Post Types

Suppose we have a Custom Post Type news, below parameters would add the necessary REST support to the Custom Post Type


This allows the Custom post type to be accessed through the REST API

rest_base => Optional Parameter

This allows to change the REST API route. For e.g. if the custom post type is news. We can define a custom route to access the books post using rest_base parameter e.g. news_api


This is only required to be changed if you are using a custom namespace i.e. other than wp/v2

Once the necessary support is added as shown above the Custom Post Type is ready to be accessed through the REST API

Add REST support for custom taxomonies

Add below parameters to the custom taxomony newstags

Here are a few examples for a news custom post type

Get list all posts for the custom post type news

Get first 5 posts for the custom post type news

Get list all posts for the custom post type news from a certain category

Get a single post from the custom post type news

Get posts from the custom post type news which has custom taxonomy newstags applied to it

Modify JSON Response

WordPress Rest API provides us a filter rest_prepare_{POST_NAME} to modify JSON Response i.e. to add or remove fields from the JSON response. JSON response by default include many fields which may not be necessary for you. Also it may be missing some of your custom fields.

Add a custom field


Create a WordPress staging site through shell script

wordpress staging
Photo credit – 132889348@N0722868800432

Creating a wordpress staging environment requires 4 things. Here we are assuming that the staging environment is on the same server.

Requirements for creating a wordpress staging environement

  1. Clone Database – Each Time
  2. Copy the code – Only the wp-content folder
  3. Edit wp-config to point to the Staging Database (single site only) plus the Staging Domain (multisite) – Once Only
  4. Update the wp-options table with the Staging Domain (single site), Update the wp_blogs, wp_site, wp_options, wp_1_options, etc tables with the Staging Domain (multisite) – Each Time

So how to to achive creating a wordpress staging environement with a single script? Here are the steps.

Step 1: Create and define variables

Create a file named inside a directory named staging (preferably outside your public_html folder)

Define all the variables related to your production and staging database connection as shown below

Step 2: MySQL Dump of the Production database

Add below code to file to get MySQL Dump of the current production database

Step 3: Export the Database to the Staging database

Again add below code to Here we are connecting to staging database and importing the sql file created in Step 2

Step 4: Batch File

Now create a new file within the staging directory named as batch.txt. Inside this batch file we will write all the queries we want to run to rename the production instances within the staging database to refer to the staging environment. The batch file will hugely depend on the type of site setup you have i.e. single site or multisite

If you have a single site then its very easy. Add below query to the file. Remember to replace PROD_DOMAIN and STAG_DOMAIN with the respective names. e.g.

For mulsite it is bit complicated

Now just repeat the last time changing the number in wp_1_options to the number of the subsites

Step 5: Run the Batch file queries

To run the batch file queries add below code to file

Step 6: Copy WordPress files

This can be done by a simple cp (copy command).

Step 7: Edit wp-config on the Staging

Now the last thing is to edit the wp-config file to point to the staging database. Thats all.

Finally just running the script through SSH will set up the staging server.

Step 8: Weekly Cron Job

To refresh/update the staging server every week add cp command to file and this time just copy the wp-content folder. You could also copy differences i.e. last changes only using rsync command.

Then set up a cron job to run to run every week


How to update shipping cost in cart dynamically (ajax) based on a custom field in WooCommerce

WooCommerce by default offers only a few basic options to decide the way shipping cost is calculated. In lot of cases these options may not be sufficient and you may require to create additional checkout fields based on which shipping cost calculations are to be done

Here are a few scenarios

  1. Distance based shipping costs. In some countries e.g. district/territory field is required to decide shipping cost.
  2. For some peculiar products you may want the buyer to agree to some terms before the purchase can be made and extra cost added accordingly.
  3. Extra handling cost based on the type of packing selected

Here are the steps to achieve such requirements

Step 1: Create the necessary extra checkout fields e.g. district .

Step 2: Create JQuery file to send the parameter as a checout parameter so that the necessary calculations can be made based on the custom checkout field update

Step 3: Peform calculation based on the custom checkout field and add the value to the session variable

Step 4: Retreive the value from the session variable and assing it to the shipping cost or add it to the cost



preg_grep – find keys in an array that match a pattern

Sometimes there is a need to find a key/s of an array that matches a particular pattern. array_search searches the array for a given value and returns the corresponding key but it matches the entire word.

Here’s a scenario. You have a list of tags and you want to provide a user to seach a particular tag which closely matches to their search.

So here are some of the tags in an array

If the user enters WordPress we want to show WordPress Plugins as well as WordPress Tweaks. So this is how it can be done using preg_grep

where $key is the user input i.e. WordPress in this case

In our case $filtered_tags will be an array and will return

0=>Wordpress Plugins

1=>Wordpress Tweaks


WordPress plugin – Create an explore topics page for your site/blog

Explore topics

Tags can be used quite effectively to show various topics you have covered on your site/blog.

Here is a plugin which lets you create an alphabetical listing of tags with search as you type filter as shown below

This plugin automatically lays all your tags in alphabetical order on a page and adds an ajax filter input box which allows to search as you type for a particular topic/tag.

Alphabetical listing of tags

Download the plugin from WordPress Plugin Repository


  1. Search for topics as you type,
  2. Supports Multisite,
  3. Show your users the vast range of topics covered on your site,
  4. Help in visitor retention and reduce Bounce Rate,
  5. Simple and easy to configure


WordPress Plugin – Allows to selectively dequeue scripts/styles on each post

The plugin allows to dequeue or remove a script/style on a per post basis. It helps to improve performance of the site and you can make sure that atleast your important pages are optimised.

Download the plugin from WordPress Plugins Repository

The plugin is very simple. All you need to do is to edit a post which you wish to optimise and on the WPI Enqueue Manager meta box add the handles of the scripts or styles in bar (|) separated format to dequeue it from that post.

Detailed instructions on how to use this plugin

  1. Install and activate the plugin
  2. Upon activation, the plugin will show all the handles related to each enqueued styles/scripts on the source code of every page. Please see below screenshot
    script and style handles
  3. Just edit the post and add the scripts/styles in relevant boxes in bar (|) separated format to remove it from that post. Please see below screenshot

Enqueue Manager