Category Archives: WordPress

All about my love for WordPress. BTW, I am self-claimed WordPress Super star.

Unit Testing for WordPress

I am in Pune attending WordCamp Pune 2015. It’s been very exciting so far and finally I had chance to meet lot of people in person whom I am have been in contact online for more than half a decade.

My talk about Unit testing in WordPress

I have recently added Unit testing as part of my development workflow and it has helped me a lot as a developer and has even changed the way I think about code. It also has helped me a couple of times to catch bugs early that had the potential to spoil my weekend if it went to production :)

I gave a talk about how you can also use Unit testing to get peaceful weekends.

At the beginning of the talk I talked about the basic concepts in Unit testing and you can do it for plain PHP code. After that I moved on to show how the same concepts can be applied for WordPress code using frameworks like wp_mocks.

Continue reading »

Posted in Events/Conferences, WordPress | Tagged , , | Leave a comment

Creating single select WordPress taxonomies

As most of you would have already know, WordPress by default provides two built-in taxonomies – Categories and Tags. If you need to create a new association, then it is also very easy to create custom taxonomies in WordPress.

But one of the major limitations while creating custom taxonomies in WordPress is that you can’t make them as “single select”. By “single select” I mean the ability to restrict only one term to be selected for a post.

Following in one example where you might need this ability. Let’s say you are storing movie information in a custom post type and you need to store the PG rating for the movie in a custom taxonomy. Each movie will have only one rating and you should restrict that only one rating term is stored for a movie.

Recently I faced a similar scenario and this post talks about how I solved it.

Continue reading »

Posted in WordPress | Tagged , | 2 Comments

Don’t enable SAVEQUEIRES in production WordPress sites

One of the common ways to debug DB queries in WordPress is to enable SAVEQUERIES, which keeps track of all the DB queries that are executed in WordPress, together with other information like how long it took for the query to execute, what are the functions that called it etc and stores in the global array variable $wpdb->queries.

While this is a great way to debug DB queries, this could be a huge issue on production sites.

Continue reading »

Posted in WordPress | Tagged , | Leave a comment

Github Ribbon Plugin v1.2 release

I just released v1.2 of my Github Ribbon Plugin.

About Github Ribbon

Github Ribbons is a WordPress Plugin that allows you to add “Fork me on Github” ribbons to your WordPress posts or pages. You can enable the ribbon per post/page level or at global level.

Continue reading »

Posted in WordPress | Tagged , , | Leave a comment

Mapping plugin folder in VVV using shared folders

I discovered Varying Vagrant Vagrants (VVV) a couple of months ago and since then I have used it for my WordPress plugin development and testing. It is extremely easy to set up and let’s me test my plugins in various versions of WordPress very easily.

In my never-ending quest to optimize my development environment and work flow, I tried various configurations and finally settled on the following setup where I am mapping my plugins folder using VVV’s shared folders. This allows me to easily test my plugins in various versions of WordPress, without copying them around.

I thought of sharing my setup and my Customfile so that it would beĀ useful for others or to future-me :)

Continue reading »

Posted in WordPress | Tagged , | 2 Comments

Why I am dropping support for PHP 5.2 in my WordPress plugins

I have decided to drop support for PHP 5.2 in my WordPress plugins. I have thought about it for quite sometime and even hinted about it in the last couple of my posts.

I am writing this blog post to explain the reasons behind my decision. The following are the two main reasons why I decided to drop support.

Continue reading »

Posted in WordPress | Tagged , | 4 Comments

How To Properly Create Tables In WordPress Multisite Plugins

Recently, I added full WordPress Multisite compatibility to my Email Log WordPress plugin and during the process, I learned a lot about how to create and handle tables in WordPress Multisite plugins. I thought of documenting it here so that it would be useful for other plugin authors.

Creating tables in Single site installations

Before we get into WordPress Multisite, first let’s see how we can create a table in a single site WordPress installation. You have to hook into the register_activation_hook action, which will be called every time you activate your plugin and then check if your table exists or not. If it doesn’t exist, then you can create your table.

The following code shows how you can do it.

The above code will work even in WordPress Multisite installations, if your plugin will be activated individually for each blog. But if your plugin is networked activated, then the above code will create the table only for the primary blog.

Creating tables for all blogs in a WordPress Multisite installation

Now that we know how to create the table for a single blog, let’s see how we can create the table for all the blogs in a WordPress Multisite installation. Even in this case, we have to hook into the same register_activation_hook action, but should loop through all the blogs in the network.

The following code shows how you can do it.

Creating table when a new blog is created

The above code will create the table only for the blogs that were created before the plugin got network activated. We should also make sure that we create the table for every new that gets created. In order to do that we can hook into the wpmu_new_blog action.

The following code shows how you can do it.

Deleting the table when a blog is deleted

Now that we are creating the table for every new blog, it is our job to make sure that the table is deleted when the blog is deleted. In order to do that, we can hook into the wpmu_drop_tables filter.

The following code shows how you can do it.

Querying the correct table

When we are querying the table, we should always use $wpdb->prefix . $table_name. If we do that, then WordPress will automatically query the correct table based on the current blog. We don’t have to manually find out the blog id and add it to the table name.

Now your plugin should be completely compatible with WordPress Multisite :)

Alternate approach

If you look into the above code closely, you will notice that we are creating one table for each blog in the network. For most WordPress Multisite installations, this shouldn’t be a problem. But some WordPress Multisite installation may have thousands and even hundreds of thousands of blogs. In those cases, we might end up creating huge amount tables which might become a bottleneck. Also my plugin needed just one table. Some plugins might need more than one table, which might also increase the number of tables that gets created.

One alternate approach is to create just one table for all blogs and then separate out data for each blog using a blog_id column. While querying the table, we can filter out based the blog_id column.

If I had started my plugin from scratch, I would have done that instead of creating separate tables.

Update: As Damian pointed out below in the comments, if you are using this approach, then you used useĀ $wpdb->base_prefix to get the main prefix and not the individual sites prefix.

Removing the tables when the plugin is deleted

The other thing to keep in mind is that we should delete all the tables when the plugin is deactivated and deleted. I will write a separate article explaining how we should do that.

With WordPress Multisite becoming more popular these days, I hope this information was useful to you. Do let me know if you have any question or comments. Also you can checkout the entire code of my Email Log plugin in github.

Posted in WordPress | Tagged , , , | 10 Comments

Prevent users from adding new terms to custom taxonomy in WordPress

Recently I faced a scenario where I had to prevent certain users from adding new terms to some custom taxonomies that I created. After some research I found that there isn’t a straight forward way to do this using user capabilities or roles.

The only way is to use the pre_insert_term hook and black-list taxonomies based on user capabilities. I am sharing the code here so that it would be useful for people who want to something similar.

In the above code change the taxonomy name and capability to suit your usecase.

Posted in WordPress | Tagged , | 7 Comments

Merged my blogs using WordPress Multisite

Most of you know that I have another website in addition to this one where I talk about my experience with hardware programming. When I started the website in late 2012, I decided to host it using another single instance of WordPress.

Recently one of the users of my Bulk Delete WordPress plugin asked me if I can add the ability to delete posts in bulk from multiple sites at once in a WordPress multisite installation. I have played around with WordPress MU a bit before it got merged with WordPress, but haven’t played much with WordPress multisite after it got merged. I did a WordPress multisite installation in my dev server and was very impressed with it. I also realized that it will save me lot of time by just maintaining one WordPress installation instead of two.

After testing out plugin compatibility, I converted both the blogs into a single WordPress multisite installation. The migration process was very simple and now both the sites are powered by a single WordPress multisite installation.

If you manage more than one WordPress installation, then do consider doing it using WordPress multisite. It might simplify lot of things for you.

Posted in WordPress | Tagged , , | 2 Comments

Get the SQL query generated by WordPress

One of the good things about WordPress is that it provides a nice abstraction to DB and you can query pretty much anything from the DB, by using the appropriate functions instead of writing the query yourself.

All though it is good, there are times when you want to see what was the actual SQL query that got generated. I faced this senarious myself, when I was debugging an issue in my Bulk Delete WordPress plugin.

It turns out that it is quite easy to do it.

The WP_Query object has a method called request that returns the SQL query that was generated.

So if you want to get the query generated by the global $wpdb object then you can use the following code

<?php echo $GLOBALS['wp_query']->request; ?>

On the other hand, if you are using a custom WP_Query object then you can call the request method on your object.

$my_query = new WP_Query();
echo $my_Query->request;

Posted in WordPress | Tagged , , | 1 Comment