Using the WordPress Admin for Lead Generation

If you are like me then you spend a lot of your day navigating around the WordPress admin, looking at the admin screens to carry out different tasks. For the right type of client, they probably spend a lot of time in there too. Therefore I thought it was a good idea to try and use the WordPress admin as a little marketing opportunity. Here is how I went about it.

This all started out with me asking the question of how can I get across to current clients the other work and services that I could offer them. My website is not great, it is just a blog (something which I need to work on!) but usually you would list your service and products on your site. However it is probable that current clients don’t really visit your website that often, after all they already have a relationship with you and contact you in other ways.

Therefore I wanted to explore ways in which I could get this information across to clients. I started to think what is the one place that I have access to add content too, which all my clients see on a regular basis. I have clients that spend much of their days in the WordPress admin, managing their sites content to generate them leads and therefore I thought that I could use the admin in some way to engage clients with new content and services from me.

For a while now I have been using a plugin I wrote called WP Basis to make some changes to the WordPress admin screens in order to make the experience easier for clients to use. The plugin takes away some of the unwanted stuff such as menus and meta boxes that are not used and would just confuse the client. However one thing that it did do was to provide a different dashboard screen for clients, rather than the complicated default dashboard.

The default WordPress Dashboard Screen can be a little complicated at first glance.
The default WordPress Dashboard Screen can be a little complicated at first glance.

With this in mind I went about altering this dashboard screen the client sees to include some additional information. The following assumes that you already have a plugin that adds a custom dashboard page for your clients. If you need a little more help with this take a look at how I have done this with the WP Basis plugin on Github.

The approach I decided on was to use tabs. I wanted to make the dashboard feel as native a possible, fitting in with other WordPress admin styles etc. There is already a tabbed section on the WordPress About page. This is the page you are directed to when you have upgraded to the latest version and therefore it seemed logical to use the same approach.

The WordPress About page already contains a series of tabs.
The WordPress About page already contains a series of tabs.

I added the following function to output the content of the new dashboard page.

The above code adds the welcome tab and I have made this code extensible so that I can add tabs in the future using other plugins to show other things. The tabs work in that you declare a tab and a tab name using a filter and then you do the same declaring the callback function for the tabs content. You then create a function with the same name as your callback in order to show whatever content you like here.

Making it extensible means that I can use the base plugin on all sites (WP Basis) and then add other plugins which add tabs and tab contents to the client dashboard. Below is an example of a tab that was added to one site – this actually advertised services for another agency as it was a site built by me for them! Each linked through to their website with information about the service.

An example of a tab added to provide information about other services.
An example of a tab added to provide information about other services.

This is very much work in progress and I have lots of ideas for other content to appear on the dashboard of clients. Some ideas are below:

  • Use RSS to grab the latest blog posts and display them on the dashboard
  • Show latest offers and promotions. Again this could done using an RSS feed from another WordPress site which would automate this.
  • Videos of how to use the site
  • Contact form for support, which creates a ticket on your support system

What do you think? I would love to get some feedback on the ideas here.

My Development Toolbox

Over time we all tend to build up a number of apps, programs and other bits of software and tools that we like to help us along, doing various jobs. Without them we would feel lost and therefore here is a list of the tools in my toolbox that I use when building WordPress websites.

The list below is in no particular order of importance, just what came to my mind at the time!

1. Safari

I guess this is the software that I use most on my Macbook Pro. It is one of those pieces of software that you forget about really as it is always open. Previously I favoured Chrome (it is still great) but since the web developer tools were improved in Safari I have gone back to using it. I like the integration of bookmarks and browser history across iOS devices too.

2. Coda 2

This has been my text editor of choice for a few years now. Initially I liked the FTP capabilities it had but as I have now moved on in development terms to using version control and deployment tools I rarely use these. There seems to be other (better?) ones out there but I have no problems with Coda and therefore have stuck with it for now.

3. Terminal

Until recently I have been a bit of a command line novice. In fact I would still say I am a novice but I have started using it much more when working with Git. Also as a I now have a number of WordPress plugin on the plugin repository I have had to get used to committing my plugins etc. using SVN through the terminal.

4. DeployHQ

As I have mentioned above, over the last 18 months or so I have moved over to deployment tools rather than relying on FTP. When doing this I researched which deployment tool to use and came across DeployHQ. I like it because I can deploy to multiple server or even server groups and it has good integrations with things like Slack which allow me to get notified when deployments have been made.

As well as this I can have committed code automatically deployed to staging or live when a commit to the repository is made. This is something that I need to refine further but certainly something I am going to look into soon.

5. GIT – Github and Bitbucket

All the WordPress websites I build I do so under version control. My choice for this is GIT and I tend to use either Github or Bitbucket (more recently) in order to have a central repository of code.

I use the Github for Mac app in order to avoid the command line as much as possible and this works for both Github and Bitbucket repositories. How I ever developed sites without having them under version control I will never know!


For local development I use MAMP. Instead of investing the small sum in MAMP Pro I use the Virtual Hosts capability in MAMP in order to create local domains for developing sites on e.g.

Although there are other options out there at the moment, most notably Vagrant and Virtual Box, I like how MAMP works and at the moment it does the job for me and therefore I am loathe to change at this point.

7. Gas Mask

This is great little app for managing and editing your computer hosts file. This allows me to easily setup local domain names, integrating with virtual hosts.

It even allows you to have multiple hosts files and you can then switch between then when you are developing.

8. 1Password

If you are not using a password manager these days to keep all your passwords nice and strong (the longer the better here!) then I would highly recommend you do so. There are a few out there and I have been using 1Password for a while. It has mobile apps to so you always have your passwords on hand.


Only in the last 6 months have I started having a go with SASS. It was only when I found CodeKit (see below) that I started the experiment with SASS. It allows me to keep my CSS much more organised in a project.

10. CodeKit

Codekit is a great little app that makes compiling files such as SASS files into CSS and compressing Javascript files into minified version a doddle. Something that I found a little daunting to get those things automated has been solved brilliantly with CodeKit.

11. Toggl

As I often work with other teams on projects it is important that I track my time. Toggle has a useful desktop App that I can use to track my time and assign this to projects and clients. It also allows me to create reports on a per project or per client basis.

I also make extensive use of Slack, Skype and the usual Adobe Creative Suite etc. What do you use?

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 –

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.

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.

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.

Altering Registered Post Type Args

Today I was working on a project where I needed to change how a post type had been registered. The post type in question was setting public to false, so the post type was not a public post type. However I was utilising the post type somewhere else and needed to change this. Here is how I went about it.

Obviously when doing this I did not want to change any core or plugin code. The plugin creating the post type was the excellent whistles plugin from Justin Tadlock. This is a plugin that enables you to add snippets of content here and there including adding stuff in accordions and tabs etc.

I wanted to to use the post type as a featured content slider with the Soliloquy slider plugin. However the problem was that the post type did not exist in the drop down to select when creating a new slider. Having looked at the way in which the Whistles plugin registered its post type, it was clear that the reason it wasn’t showing as a post type to choose in the slider was because the post types ‘public’ arg was set to false. Therefore I set about finding a way to change this without chaining the plugin itself.

The first thing I did was to find in the plugin files where the post type was registered, hoping for a hook or filter which I could use in order to change the args when registering the post type. However in inspection it became clear nothing was present. This left me looking in core.

I found the file containing the function register_post_type() and noticed at the bottom of this function is a cal to do action named registered_post_type. Passed to this action is the post type name and the args for registering that post type. This meant that I could use this action in order to change any of the registered post type args.

Below is the code I used in order to change the public arg from false to true.

[wpmark_gist id=”86a965d71a6a7333ddd9″]

You can change any of the args that are registered. A dump of the ‘args’ from that function shows the following:

[wpmark_gist id=”292d91a50c6c9bafa009″]

Therefore any of these can be changed in a similar way.

Allow WordPress Editors Access to Widgets & Menus

This is something that I have been pondering for a while now and that is how to allow WordPress users that are the editor role to be able to manage widgets and menus. Sometimes although you don’t want these users to have admin rights on the site they may need to edit the sites widgets and menus. Having watched Andrew Nacin’s talk on titled “Current User Can Watch This Talk” he gave an excellent example of a really easy way to do this. Just pop the code below into your themes functions.php file or better still into a plugin.

A WordPress Development Setup – Part 2

This is second post in a three part blog post series on setting up a WordPress development environment. The first part can be read here. Having got your local machine setup ready with your hosts etc. the next part is to actually create your WordPress site on the local machine under version control. The steps below you need to complete for each WordPress site you build.

I have done development differently quite a lot in the past. There is the debate of whether to have the entire site in version control or just the themes and plugins. Having tried both I prefer to keep the whole site under version control and therefore this is the method that I shall be outlining here.

The first part of getting a WordPress site setup is to create your repository to keep your code in version control. I use Git alongside Github and therefore I shall show this method here. To create your repository login to your Github account and click the Create button in the upper right corner of the screen.


Give your repository a suitable name (no spaces here is best) along with a description.Note that the name will give will form part of the local url of your site, although it could be changed if necessary. I always add a read me file to which indicate basic information about the repository.

Making sure you have Github app installed on your machine (either Windows or Mac ) on the repository page you are taken to on creation, click the “Clone in Desktop” button. This will open Github on your machine and ask you where you want to place the repository. Depending on which local “domain” you want to place it in, add it to the correct folder we setup in part 1.

The next stage in the process is to edit your wp-config.php file. We want to keep this under version control, however the connection to our database will be different whether we are working locally or working on the server of the live site. For these reasons we need to make some changes to the wp-config.php file. I follow the steps outlined by Mark Jaquith, which allows you to use a local-config.php file.

Once we have this setup we need to make sure that our local-config.php file is not under version control. For this we can use Gitignore, which happily the Github app allows you to control. From the Github App screen for the repository we created previously click on the “Settings” tab from the menu in the left.


In the ignored file box add local-config.php as well as the wp-content/uploads folder. We don’t want to have all of our media library under version control as this could be huge eventually. Once you have added these click Save Changes and these files will not be under version control.

Now you can install WordPress in the normal way locally (using MAMP) and work away developing your site. I would commit regularly using the Github app.

The final part of this tutorial will focus on getting your site using a staging server and a live server.

A WordPress Development Setup – Part 1

Having worked with WordPress for the best part of 8 years now I have gone through a number of different setups in order to develop a WordPress site. However I think I have finally found one that works the best of the lot and therefore here is my WordPress development setup.

This article will come in three parts as the setup is a two step process. There is the setup for every site and then the steps that need to be taken for each site I develop. So here goes with part 1.


Local Development Using MAMP

You should start off developing a website on your local machine. It has a number of advantages such as speed of page load and the fact that you can play and mess around without anyone having access to your site other than you. There area a number of options in order to get your sites setup locally on your own machine however the option that I have been using for a while now is MAMP.

MAMP is Mac, Apache, MySQL and PHP all bundled together in one easy install, which is all the tools you need to run a WordPress site. Therefore download and install MAMP the usual way according to the setup instructions on the MAMP website.

Changing the Local Hosts File

Being a freelance WordPress developer I tend to work not only for myself but with a number of agencies and therefore I like to keep my work separate in different “sites” on my local machine. To do this I have used virtual hosts. This enables a more custom local domain to work on for different clients. So work I do for myself will be done locally at, whereas work I do for Pixel Junction is done at and finally work for Compass Design is done at

To set this up you need to get familiar with your computers local hosts file and virtual hosts. I covered this when talking through using MAMP with WordPress Multisite, so I am going to assume that you have created a host for any of the “domains” you want to host your sites on. In my local hosts file I have something like the following:

This allows me to use those ‘domains’. However we have yet to let Apache know where the files for those sites are. Therefore to do this we need to create these virtual hosts in Apache. This points the request for that host to the correct folder on your computer where you are hosting the files so they can be served to your browser.

Setting Up Virtual Hosts

Again allow MAMP’s Apache to use the Virtual Hosts file is covered in the article above, therefore I am going to assume that you have done that and you are editing the Virtual Hosts config file in apache. You would need to add to that file the following block, for each of the hosts:

<VirtualHost *:80>
    DocumentRoot "/Applications/MAMP/htdocs/local/"
    ServerAlias *

You would obviously change the document root to wherever you are storing your files for that site. You would also need to change the ServerName to the host your are using. In ServerAlias I add a starred entry so that I can use sub domains, for example in a multisite install, although any additional sub domains would need adding to your local hosts file too.

Using the example above, I can now create sub folders inside the /Applications/MAMP/htdocs/local/ folder and access them at URLs such as

That covers the first part of this tutorial on getting the environment setup and ready to start working with. The second part (coming soon) covers the steps to take for working with each site that you create, including getting the site under version control with Git and Github.

Read Part 2 of 3 about creating A WordPress Development Setup here.