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.

Extending The WordPress Options Framework Plugin

Extensible plugins are a topic that I enjoy to speak about and I love it when I come across a plugin that is extensible. The options framework, a plugin which I have recently defaulted to for providing a ‘Site Options’ page in WordPress projects has many extensible features allowing me to customise the plugin so it is tailored to my clients. Here is how I have recently utilised some of its extensibility features.

In case you are not familiar with the term extensible plugins let me briefly outline what is meant by this. WordPress core utilises these features too, in fact it is what allows the plugin architecture to exist.

An extensible plugin is one that can be modified and extended upon without altering the core plugin code itself.

This has many benefits, but perhaps the best is that when you update the plugin your modifications are not lost.

Below are the modifications using extensibility features that I have made use of with the Options Framework plugin.

The Options Menu Item

By default the Options Framework plugin provides you with an admin sub menu labelled ‘Theme Options’ underneath the parent menu item of Appearance. If you are building a WordPress theme to be sold or to go into the WordPress theme repository this name makes sense. However when you are building a site for clients, theme options makes little sense to them. Lets face it, most of my clients don’t know what a WordPress theme is, and why should they? Therefore I wanted to be able to change this name and its location within the admin menu.

The Options Framework plugin provides all the extensibility features needed in order to do this. The plugin uses a filter named optionsframework_menu. This filter can be used to alter all of the menu parameters such as the menu name, position, page title and more. You will find that the plugin adds its menu using the code here – https://github.com/devinsays/options-framework-theme/blob/34c286996d387a29cb7871cfc2c8fdc09f03e5ca/inc/includes/class-options-framework-admin.php#L83-L104

Before sending the menu information to WordPress, it is passed through a filter named optionsframework_menu which allows us developers to alter the menu settings to change the way in which the menu is outputted. I used the code below in order to change the menu label, its position (make it appear below Settings) and make it is a top level parent menu item rather than being a child of Appearance.

Customise the Options Name

By default the plugin uses your themes stylesheet as the prefix for all of the options stored in the options table. However you can change this should you wish to do so using another handy extensibility feature. This is where you can overwrite one of the functions in the plugin with your own. The code below would change the name of the options to wpmark_options.

All of your saved options would now be stored in the options table as an array in an option with the name wpmark_options.

To go hand in hand with this you can then create your own function to get those options to use in your theme. The following function does this:

Theme Independent Option Declarations

By default the plugin looks for a file in your theme named options.php. This file then contains all of the options for your site. However I wanted to keep the options separate from my theme in case I changed themes and still wanted access to the options.

Again the plugins extensible features allow you to do this too. You can use the of_options filter to do this, like so.

I hope this goes to show that extensible plugins are the best! Thanks to Devin Price for building a wonderful extensible WordPress plugin.

WP Broadbean v2.0 Coming Soon

My WP Broadbean plugin to integrate jobs posted via Broadbean Adcourier has been a success in the recent months with many different recruitment companies using the plugin to get jobs they post on Broadbean to appear on their WordPress websites. Now it is time to take the plugin to the next level and coming soon with be the second version of the plugin with updates and enhancements. Lets take a look at what is planned.

Having been working on the plugin for well over 18 months now, in my spare time between projects and with a number of clients using the plugin I have learnt a lot about what changes would enhance the plugin. Here are what is planned in the new release:

Improved Extensibility

This is something that I am passionate about in plugins. The ability for a developer to make modifications and functionality changes without altering the core plugin code itself. In the next release there will be major extensibility offerings, some of which are outlined below.

Better Declaration of Fields for Each Job

At the moment the plugin comes with a set of job fields that are added when each job is published on the site. These include job reference, salary, contact name and email address etc. Adding your own fields up until now has been a little tricky to do and therefore the new version will easily allow you to declare what fields you want (additional) to the defaults. As well as this you can remove the defaults should you wish to do so.

Below is a simple example of how you could add your own fields to a job:

This will add the meta box field on the post editor for the job. Perhaps the best part as well is that it will also handle all of the saving of the post meta when the job gets saved.

It is worth noting here that this field would have to be added to your feed sent by Broadbean. They can do this as support and would not be a problem. In this case we would just need to request that an additional text input field be sent with the XML node <internal_ref>.

Add Your Own Taxonomies

The plugin comes bundled with some default taxonomies that work well with the default feed that Broadbean uses. Adding your own is also really simple and works in a similar way to the fields as above. Below shows an example of how we would add a new taxonomy for country.

Again this handles all the saving of the terms in this taxonomy when they are sent over to your site. As with fields Broadbean would need to add this field to your feed. The broadbean_field arg in the code above states which XML node to look for in the feed.

Thanks must go to Dave Smith for his contribution to this part.

WP Broadbean Website

Along with the launch of version 2 of the plugin comes the new WP Broadbean website that is currently in development. The site will feature information and documentation as well as some paid services which users can opt into should they find them useful. More information on this soon.

Visit the current version (rough and ready!) of the WP Broadbean website here.

These are some of the major changes that have been introduced. It is worth noting that they are still in testing and I hope to have the new plugin version launched early in the new year.

Important Note

With all these changes there is an important note that I need to make. Users that are using the current plugin, version 1.0.2 or lower, the new versions changes are likely to break your version. This is far from ideal I know, but having gone back and forth on a number of occasions this I feel is still the best way forward.

If you are on versions at or below 1.0.2 then I would recommend you add the Block Specific Plugin Updates plugin from the WordPress plugin repository and set it to prevent updating the WP Broadbean plugin until you are ready to move ahead with the new version 2 plugin.

Adding a Class to Every nth Post

A project I was working on recently had a series of sections on a page. They ran in 3’s in that the 1st, 4th, 7th and so on and the 2nd, 5th, 8th (you get the idea!) were styled the same. Therefore I needed a way to add a class to each div which indicated which section it was. Here is how I did it.

I was able to create a loop (we use them a lot in WordPress!) and then use a counter to find out which section were we in, in order to add the correct class. The code I used is below:

As you can see this uses the PHP operator modulus, which would check out on the PHP site here.

You could of course adapt this to suit other patterns of post classes, quite easily.

WordPress Front End Profile Plugin

Have you ever worked on a site where you have lots of users on the site but they should never need to go into the WordPress admin area? Maybe you have different roles setup to show them different types of content. However you would like them to be able to edit the information on their profile page? Well now you can allow them to do this without going near the WordPress admin buy using my new WP Front End Profile plugin. Lets take a look at it.

Put simply this plugin provides you with a function for which you can add to your themes template files. When you do this the function outputs a profile editor on the front end. The function in question is:

wpfep_show_profile();

Once you add this you will be presented on the front end, in whichever template you added it to with the following profile editing screen.

Screen Shot 2014-12-06 at 11.15.28

As you can see, by default the profile editor has two tabs named Profile and Password. Each tab contains a set of fields which the user can edit. The profile tab has the majority of things that can be edited on the profile admin screen, such as first and last name, URL, email address and the bio or description. The password tab allows the user to change their password, entering it twice to confirm.

All that sounds great, but that it not really the best part of the plugin, this comes in the form of its extensibility. The plugin is built in a way that easily allows developers to add their own tabs and their own fields, either to tabs they have added or to existing tabs. What is also good, is that all of the saving is taken care of for you. Lets took at look how.

Adding Your Own Tabs

To do this you will need to use the wpfep_tabs filter. An example of how to add a new tab is given below:

As you can see you declare a number of tab args when adding the tab. Perhaps the most important of these in the Tab ID. This is used for adding fields to your tab. So lets take a look at how to add fields to your tabs.

Adding Fields to a Tab

All fields that you add are added to the user as user meta (you can use the wpfep_reserved_ids filter to save to the user table rather than user meta but that is for another day!). Fields are added to a tab using a dynamic filter. The filter is dynamic as it uses the tab ID from when the tab was added. The filter takes the following format:

wpfep_fields_$tab_id

Here the tab id is the ID of any added tab. The ID of the default tabs are profile and password. The ID of the tab we added above is wpmark_tab. Therefore to add fields to this tab we would use a filter named:

wpfep_fields_wpmark_tab

The code below is an example of how we do this:

Here we have added a select input setting the type to select and adding and options arg to give the different select options. Other types you could add include WYSIWYG, text, textarea, checkbox, password and email.

Actions and Filters Available

There are also a number of actions and filters that developers can use to modify things such as password length requirements and whether or not to use the plugins built in styles and javascript. Take a look at the Wiki on Github in order to find out more.

You can download the WP Front End Profile Plugin in the WordPress.org plugin repository or view the code and submit issues on Github.

WP Post Type Meta WordPress Plugin

Working with custom post types for the last 3 or 4 years has on the whole been great. However there was always one thing that I found lacking and that was the lack of an (editable) post type description. Therefore I set about to try and change this, adding some extras along the way. Let me introduce the WP Post Type Meta WordPress plugin.

I must start off this post by letting you know that this idea is not new. In fact my idea for this came from Steven Jones in his post 5 Improvements to WordPress’ User Experience. In this post Steven added a simple link to a plugin that adds a post type description to custom post types. Essentially this is what WP Post Type Meta does “out of the box”, however I wanted to take this further and allow further meta to be added to custom post types.

Screen Shot 2014-12-01 at 18.40.59

The need for this was seen when I was working on sites that made use of the term description field in a taxonomy term. This description is often displayed at the top of the archive for that term to indicate the nature of the posts found in the term archive. This was something that a lot of my clients wanted for custom post types. For example many want an FAQ section and I often deliver this through a custom post type with an accordion style jQuery addition on the front end. The post type archive acts as the FAQ page. However many clients wanted to have a paragraph of text appear at the top of this archive to explain the page. The problem them comes as to how to allow the client to edit the text. There are other ways to achieve a solution to this such as a page that is pulled in at the top and also a theme option style settings, however I was not really happy with either. Steven’s post type description plugin did the job.

This got me thinking that we could actually add other fields to the post type description page added in the admin. For example what if you had a post type about products and you wanted to add a standard sizing link to a PDF that would show on the archive page at the top in useful info. You can easily add a text input box and add your link into that or even a post type select input to choose a page for the sizing information.

This is what the WP Post Type Meta plugin does. It provides an additional sub admin menu for each custom post type in your site named {Post Type} Meta. By default on the page is a description box to add a post type description, however the plugin is extensible and easily allows you to add other fields including text, textarea, WYSISYG, select and checkbox inputs. The post type description field is added in this way.

All of the plugin meta data is stored in the WordPress option named wpptm_meta as an array. Each piece of meta added is prefixed with the post type name. For example to get the post type description field you would use the following:

You can add your own fields by using the wpptm_settings filter. The example below shows you how to add a select input:

Other fields can be added in a similar way. The field above would be retrieved on the front end like so:

I have tried to build the plugin in an extensible way to allow developers to build upon and extend its functionality. I look forward to using it in the future.

You can download the WP Post Type Meta plugin on WordPress.org or add it to your site through your WordPress dashboard.

WordPress Admin Bar User Switching

For a while now I have been using the excellent user switching plugin from John Blackbourn to easily switch between user accounts in WordPress. I have extended the plugin to produce Admin Bar User Switching.

User Switching provides an easy Switch to link in the users profile page when logged in as an administrator. This easily allows you to login as a user and see what they would be seeing. I found this particularly useful when building an Intranet for a school. As there was over 200 users of the system, all with different roles and capabilities it meant that I could easily test the different user levels without having to login and out all the time.

However it was when developing a Support Hub for Pixel Junction that I thought that there could be an easier way if switching between users than having to go to their profile screen each time. I then thought of using the admin bar as this is on the screen all the time, front and back end.

Admin Bar User Switching was born, which is an extension to the User Switching plugin which must be installed and activated before using Admin Bar User Switching. The plugin adds a “Switch To User” link in the admin bar which, when hovered displays a dropdown list of the sites user. Clicking a user switches to that user. The link then changes to “Switch Back” to allow you to go back to your own user. This is probably only useful for sites where there are less than 20 users or the list would just be too long. Maybe in the future I can categorise the users into their roles in the menu – or maybe A – Z on surname or something.

Screen Shot 2014-11-26 at 11.46.58

Feel free to download Admin Bar User Switching from the WordPress.org repository or you can follow the plugin on Github.

Altering WordPress Admin Menus

Over the last few months I have worked on a number of projects that have required some modifications to the WordPress admin screens. Sometimes it was just to make things easier for the client and others I needed to add different menus and admin pages for various reasons. One task I undertook required me to move WordPress admin menus around, and have them display under different top level menus. Here is how I managed to add, remove and edit the WordPress menus.

WordPress core provides us with a lot of tools and functions for editing both the WordPress admin and the WordPress admin menu items.

Adding Top Level Menu Items

The WordPress admin menu is two-tiered. By that, I mean there can be two levels of menu items. Top level menus such as Appearance can have sub level menus beneath them such as Widgets. You can add top level menus really easily by using the following code in your own plugin (or theme functions file but I would not recommend that).

You will see the function takes 6 arguments which are needed. Lets take a look at what these are:

  1. Page title – this is the text that is added to the pages <title> tags in the head of the page
  2. Menu title – this is the label given to the menu in the WordPress admin. This is what the user sees in the admin.
  3. Capability – this sets what capability a user needs in order to be able to see and have access to this menu
  4. Menu slug – this is a unique slug to which this menu items if referenced by
  5. Callback function – the callback function is the function used to output the pages content once the menu item is clicked
  6. Icon – this is the icon that displays next to the menu title. You can pass a dashicon string here or pass div which can then be styled with an admin stylesheet.
  7. Position – this sets where your menu items will appear in the list of menu items. Take a look here for what the position of each core menu is

Notice how the function we build, which includes the call to add_menu_page() is added to WordPress using the admin_menu action hook.

This code will now add your menu to WordPress. However when you click on your menu you will get an error. The reason for this is that WordPress is trying to find a function with the name we gave to the callback arg in the function, in order to display the pages content. However we have yet to create this.

The next step then is to create this callback function which would be something like this. Obviously you would add your pages content to this function depending on what you wanted to output.

Adding Sub Level Menu Items

We call also add a menu as a child of another menu. This is handy for adding plugin settings and the like as you would and probably should be adding this under the Settings or Tools menus. The code below would enable you to add a sub menu under tools.

Again this function takes 6 arguments so lets take a look at what these are:

  1. Parent Slug – this is the menu slug of the parent item you wish to add your submenu item to. Here we use tools.php to have it display on the tools menu. We could also use a slug that we previously declared in our function above, to have our sub menu item display under a top level menu we created.
  2. Page Title – this is the text that is added to the pages <title> tags in the head of the page
  3. Menu Title – this is the label given to the menu in the WordPress admin. This is what the user sees in the admin.
  4. Capability –  this sets what capability a user needs in order to be able to see and have access to this menu
  5. Menu Slug – this is a unique slug to which this menu items if referenced by
  6. Callback Function – he callback function is the function used to output the pages content once the menu item is clicked

The callback function works in the same way as for adding a top level menu.

Moving Existing WordPress Menu Items

As part of the work I was doing it required moving top level menus underneath other top level menus to make them a sub menu item. This can be done it two parts. The first part is to remove the original top level menu from the WordPress admin menu and the second is to add it in again as a sub menu item.

Lets start be removing the top level menu item for Posts.

The only argument passed to the remove_menu_page() function is the slug of the top level page you want to remove. Passing edit.php removes the posts item.

Now we have removed the posts menu item we want to add it back in as a sub menu of our top level menu we added above. If you remember the slug we gave to this menu item was wpmark_admin_menu which we need when adding posts back in.

We can use the following function in order to add the posts menu as a sub menu item.

You will notice that the menu slug we have passed above is edit.php which is the slug of the posts top level page. We could have passed a final arg which would be a callback function, but as the posts page already exists we don’t need to.

Correcting Menu Hierarchy

One thing I have come across when working with menu items is that you also need to alter the menu hierarchy. For example if we move posts into another menu it works fine, however when we now click on the posts sub menu item, it closes the top level item we were in because the posts parent file is not set, as originally it was a top level menu item. We can correct this using the parent_file filter.

This will now keep the top level page open when on the sub page of posts. There are one or two strange goings on with this filter that sometimes prevent this from working. I found in particular moving pages to a sub level menu this caused problems on. This trac ticket offered a fix.