Phil Wylie

WordPress developer, Code Club volunteer & Staffs Web Meetup organiser

Launching a WordPress plugin

Plugin Lettering, written with Chalk on Blackboard
This is a post written for the iWeb blog after launching iWeb’s first public WordPress plugin. The snappily named Background Update Notification Email Address plugin is not only iWeb’s first public plugin, but also my first plugin published on the WordPress plugin repository. In the blog post I discuss the problem solved and the process taken to get the plugin published. Rather than take the Ronseal naming approach, I must try harder next time and come up with something a little shorter!

Last week, we launched iWeb’s first plugin to the official WordPress plugin repository. At iWeb, we manage hundreds of WordPress sites, providing backup, updates for WordPress core and plugins as well as other maintenance tasks. Background Update Notification Email Address is our plugin aimed at those who, like us, manage WordPress on their clients behalf…

Launching a WordPress plugin

Making friends with your customers

Chalk drawing - Social media concept
This is a post written for the iWeb blog. I’m told if you can get past the spammy first paragraph (which, believe it or not, I wrote voluntarily) there’s some good stuff in there… The post aims to give the reader a brief overview of corporate social media marketing with an example of both good and bad Twitter usage. A number of suggestions and ideas for generating content to foster discussion.

Magento is a powerful open source ecommerce platform which iWeb has spent many years mastering. Every project combines iWeb’s 18 years of experience. By taking the time to tune our Magento toolkit and workflow, we build effective, conversion optimised profitable stores. But once your store goes live, are you doing everything you can to promote your site in the vastness…

Making friends with your customers

Moving WordPress with a safe search and replace tool

This is a post I wrote for the iWeb blog looking at interconnect/it’s safe search and replace tool. A handy script used while moving WordPress from one location to another. The script performs a find and replace on the database without breaking the integrity of serialised data.

WordPress generates and stores absolute URLs in it’s database. This makes it difficult to move between staging and production or simply changing its location. Today we’ll be taking a look at one of the tools we use at iWeb. interconnect/it’s safe search and replace tool which updates hardcoded links in the database and in our opinion makes working with WordPress easier. Why does WordPress…

Moving WordPress with a safe search and replace tool

Exclude your plugin from update checks in WordPress 3.7

In order to keep your plugins up-to-date, WordPress sends information about all it’s plugins (including any inactive ones) to WordPress.org. There are concerns around the information sent as it includes details on each plugin’s developer including name and website address. While not much of a privacy issue for public plugins, there are implications for plugins custom written for specific clients.

The information is used to check if a plugin exists in the WordPress.org repository. If a plugin with the same name and a later version number exists, WordPress will dutifully offer to update/overwrite the installed plugin. A potentially disastrous situation for any custom plugins given a generic sounding name.

Maybe just something to consider for the paranoid. This also introduces the possibility of targeting users of externally hosted plugins such as those only available on GitHub by releasing an identically named WordPress.org plugin. It has been done before. As pointed out by Joost de Valk, each plugin is reviewed before being accepted into the plugin repository and any bad plugins would no doubt be identified and removed.

Mark Jaquith wrote up a solution back in 2009 which included a snippet plugin authors could incorporate into their code to remove their plugin from the list sent to WordPress.org. However, changes in WordPress 3.7 require the snippet to be updated. The format of the update check has been changed from XML to JSON and is now sent over an SSL connection.

The following snippet has been updated to reflect these changes and should be included in the main plugin file or updated to reference the path to the plugins main file relative to the plugins directory (e.g. plugin-dir/plugin-file.php).

I’ve touched on the privacy concerns around the information sent to WordPress.org which from WordPress 3.7 is now encrypted. Looked at the possibility of accidentally overwriting custom written plugins and gone over one of the solutions to prevent WordPress from updating your own custom plugins. If it’s all a bit too much, Dinesh Karki has an alternative solution with his plugin Block Plugin Update which has a nice interface for selecting which plugins to exclude from the update check.

Change WordPress auto update email address

This is a post written for the iWeb blog while playing with WordPress 3.7 automatic updates. The default WordPress behaviour following an attempted update is to send an email notification to the admin email address set under Settings → General. We wrote a small plugin ideal for those who manage WordPress on their client’s behalf. The plugin overrides the email address so the developer receives the notification. It’s then possible to setup an email filter to archive successful notifications and flag up any issues (if it wasn’t possible to automatically update or there was a critical failure).

We recently posted about automatic updates which were introduced in WordPress 3.7. On by default, automatic updates currently only apply to smaller point releases which generally contain bug fixes and security enhancements. WordPress 3.7.1 followed shortly afterwards and served as a good test of the system. We had no trouble with the update. However, an email notification is sent out following…

Change WordPress auto update email address

Newer Posts
Older Posts