Like my Twitter Avatar plugin, even my WP Github Gist plugin was broken recently due to changes in the underlying API that my plugin was using. This time it was because of the changes in the Gist Embed API.
Category Archives: WordPress
Because of the recent changes in Twitter API, my Twitter Avatar Reloaded WordPress plugin stopped working. I rewrote the way my plugin communicates with Twitter and updated the code to use the new API and now my plugin works again.
New Twitter Backend
Instead of rewriting the entire Twitter backend again, I am not using the excellent wp-twitter-api, provided by @timwhitlock which allows you to easily communicate with Twitter API from your WordPress plugin.
If you are a WordPress plugin developer and want to communicate to the Twitter API from your WordPress plugin, then I would highly recommend you to use wp-twitter-api, instead of creating your own.
Setting up Twitter App
The new version of the Twitter API needs you to make authenticated calls even to get some basic information about a twitter screen name. So after you installed the plugin you need to follow these steps so that the plugin could interact with the Twitter API.
- Register a Twitter application at https://dev.twitter.com/apps
- Note the Consumer key and Consumer secret under OAuth settings
- Log into WordPress admin and go to Settings > Twitter API
- Enter the consumer key and secret and click ‘Save settings’
- Click the ‘Connect to Twitter’ button and follow the prompts.
This is a mandatory update. You can download the latest version of the Plugin from the Plugin’s homepage or install it using the Plugin installer.
Please keep the feedback coming and if you want me to add any new features or find a bug, please leave a comment or post about it in twitter.
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
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
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
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 number of 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
If I had started my plugin from scratch, I would have done that instead of creating separate tables.
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.
I just released version 1.7 of my Email Log WordPress plugin, which adds full compatibility with WordPress Multisite.
About Email Log WordPress plugin
Email Log is a WordPress plugin that allows you to log every email sent through WordPress and provides a UI where you can view them. The logged emails can be searched based on date, email address or subject.
WordPress Multisite compatibility
Earlier versions of Email Log plugin had some compatibility with WordPress Mu (older version of multisite), but I didn’t test it for long time. Also when WordPress Mu got merged into WordPress core, certain things have changed and my plugin was not fully compatible after that.
I came to know about it recently and then started to work on it to make it fully compatible with WordPress Multisite, since I have moved this blog to WordPress Multisite as well. I also learned a lot about WordPress Multisite during the process and will write a separate blog article about it soon. Update: As promised, here is the new blog article explaining how to properly create tables in WordPress Multisite plugins.
This release took me about 2.5 hours of development time. You can find more details about the dev time tracking which I have recently started doing in a separate blog post.
You can download the latest version of the Plugin from the Plugin’s home page.
Try out the Plugin and if you have any comments or if you want to report any bugs, please leave a comment below.
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.
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.
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.
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();
I recently released a couple of updates to my Easy Retweet WordPress Plugin.
For those who don’t know, Easy Retweet WordPress Plugin allows you to Twitter tweet or bit.ly buttons to your WordPress posts.
You can choose to add these buttons using any one of the following ways
- Automatic way – Just configure the button in the settings screen
- Using shortcodes
- Using template functions
Google Analytics tracking
One of the new feature that I have added to the Plugin is the ability to add Google Analytics tracking to links that are tweeted using the Tweet buttons.
You can add Google Analytics tracking by including the following in the url that gets tweeted.
In addition to the new features, I have also added translations for the following languages
The current version of the Plugin is
3.0.1 and it includes both new features and bug fixes. So it is a mandatory update. You can install it from your WordPress admin or download it from the Plugin homepage.
Recently, I had to create a new page automatically in WordPress, when a Plugin was created.
I thought there will be a simple core function like
wp_insert_post which I can use. It turned out that create a new page from code is not that easy in WordPress. I ended up creating a new function myself wrapping the call to
I thought of posting it here so that I know where to look when I need it again
So here is the function.
It takes 5 parameters, out of which only one is mandatory.
$title– The title of the post (mandatory)
$content– The content of the post
$parent– The post id of the parent page. If this is the top level page, then pass 0
$page_template– The page template to use for this page
$menu_order– The menu order field.
While you are at it, you might also want to find out whether the page with that title already exists, before creating a new one.
Until recently I was using the official WordPress repository’s svn to do the development. All my non-WordPress pet projects are hosted in my github account.
I was thinking of moving all my WordPress Plugins to github for quite sometime now, but didn’t do it thinking that it might involve huge effort to keep both the repos in sync.
After reading about how a couple of people moved (and didn’t face much problem afterwards), I decided to try it out for a couple of my Plugins. The following is what I did and in the end, figured out that it was worth the effort.
Github – more than just code
To be fair to official WordPress Plugin repository, there is nothing anything wrong with the way it works or with svn.
It is just that github as a platform is more suited if you are interested in collaboration and receiving contributions from users. It reduces the barrier to entry for people to contribute to projects and also it provides enough tools for project owners to easily merge (or reject) contributions from users.
I was more interested in this aspect of github rather than the ‘git’ part.
Using github for hosting WordPress Plugins
When I decided to move from svn to github, I wanted to do the following things.
- I wanted to maintain the entire check-in history from svn. Some of my Plugins are more than 4 years old and have gone through lot of revisions and I didn’t wanted to loose them.
- I also wanted to do the development in github (read doing atomic check-ins) and then upload to WordPress repository only when I tag the changes for release after testing them.
- I also didn’t wanted to manually check-in in both the places to do the sync.
For the first I found that
git-svn can fetch all the check-in history.
For the second and third point, keeping pragmatism in mind, I ended up creating shell scripts so that I don’t have to do anything manual.
You can get the scripts that I wrote from my github account. The project consists of two scripts.
- clone-from-svn-to-git.sh – Use this script to clone your WordPress Plugins from SVN into git/github
- deploy-plugin.sh – Use this script to push your WordPress Plugin updates to SVN from gi/github
Right now the documentation is pretty sparse. I will fix it when I get some free time
Things to improve
The scripts pretty much do the job. Going forward, I want to improve the following to make it more useful.
readme.txtfile used by WordPress repository is not fully in markdown. Because of which the readme file displayed in github is slightly broken.
Ability to auto update the
.potfile before releasing the new version
WordPress repository allows you to add a banner using the
assests/directory. Need to add support for that.
Update: All the above features are added. Check out the latest code in github.
Is it worth the effort?
So far I have moved the following Plugins to github. Will be moving the other ones as well when even I get some free time.
- Bulk Delete
- Bulk Move
- WP IRC
- WP Github Commits
- WP Plugin Reviews
- WP Year end stats
- Posts By Tag
- Email Log
- Twitter Avatar Reloaded
So now the real question. Is it worth the effort? It is worth every second that I spent on it.
You should check the pull requests I have received so far. I have received more contributions to my Plugins in the last couple of weeks than the last 5 years
If you are a WordPress Plugin developer, then try out my script and let me know if you have any feedback.