User Switching in the Admin Bar – Updated to V1.0

A while ago I released a the Admin Bar User Swtiching plugin which was a dependancy of John Blackbourn‘s excellent User Switching plugin. After some community feedback I needed to make some changes. Therefore I am pleased to release version 1.0.

A number of users left feedback and support requests on the WordPress.org support forums. The main issue, which I actually already knew about and stated in the plugin readme.txt file was that the plugin was potentially quite resource hungry.

In order to build the “Switch to” links in the admin bar the plugin was querying all the sites users on every page load which was OK for sites with a low number of users but not great for sites with hundreds or even thousands of users. Therefore some changes needed to be made.

One support forum post outlined the following:

Had to manually remove Plugin as it consumed all available memory and killed the frontend & WP Admin. Consider adding an AJAX search instead of full hover list (site has 80,000+ users) 🙂

Therefore I had to go about solving this issue and started down the path suggested by the commenter. This was interesting for me and I had not really used the WordPress AJAX method before and therefore found it very interesting.

Anyway after about 3 – 4 hours of Dev time I finally have version 1.0 of the Admin Bar User Switching plugin which, instead of listing all users in the admin bar dropdown, displays a search box so users can type a username (including the use of a wildcard). On submitting this search a list of users is presented and when clicked you are switched to that user.

The benefit here is that no queries are being run on every page load, only when a user runs a search for a specific user.

I hope this brings significant performance benefits to the plugin and allows sites with many users to take advantage of the plugin.

Disable WordPress Auto Update on Production Server

Previously I have spoken about my WordPress development and deployment setup using a service such as Deployhq, but lately I ran into a minor problem with this setup. The issue was the live site was being updated without the repo in Git being touched. Here is what I needed to do to solve the problem.

This has all come about since the brilliant auto-update feature of WordPress was introduced (I think in version 3.7). This means that your site will auto update itself for minor point releases (e.g. from 4.1 to 4.1.1 but not from 4.1 to 4.2). However, if like me you have the site under version control then you do not want this to happen as you need to manage the repository.

The WordPress team already thought of this as a problem and came up with a good solution. WordPress detects whether your site is using version control by looking for .git, .svn and other version control files in your site. If it finds these then of course the auto update is not set to run.

If you have a setup whereby you are pulling a Git repository to your server then those .git files will also exist on the server. However I use a different setup using a deployment service to deploy the files from the repository (usually on Github or Bitbucket) to the server. This means that those version control files (.git etc.) never get pushed to the server. Therefore the instance of WordPress on the live server (and staging for that matter) gets auto updated for point releases.

I needed to stop this happening or the live and staging sites would be ‘out of sync’ with the local sites developers are working on. Luckily there is a constant you can use in your wp-config.php file to prevent core from updating, period. Add the following to your wp-config.php file and it will prevent WordPress from auto-updating core.

define( 'WP_AUTO_UPDATE_CORE', false );

Now I am in control of when the updates are run and when WordPress gets updated to the latest and greatest version. Something which is important when you site is under version control.

Talk: Content manage everything

WordPress is a content management system, it allows users to edit and add content without the need for them to understand or interact with PHP and HTML. However I found that many of the sites I was developing had elements that could not be managed through the WordPress admin screens.

This talk outlined some of the methods I have used on sites to make sure that almost everything is editable through the WordPress dashboard. The talk was ideal for developers and designers that are looking for different ways of adding  content to WordPress and making sure it is always editable by a client or user.

View the slides