Don’t use the ‘admin’ username

This is quite a common one and used to be the default when setting up your WordPress site. WordPress now gives you the option to set this during the installation process. It doesn’t matter so much what you pick, however with ‘admin’ being the most common, it’s the one that hackers look for when trying to gain access to your website. If you current have ‘admin’ as your username then here are the steps to follow to change this.

1. Set up another user as an ‘Administrator’.
2. Delete the ‘admin’ user.
3. Important – attribute all the posts to the new user you created in step one.

Change the standard ‘wp_’ table prefix

Another configuration during installation is changing the ‘wp_’ table prefix. Again with this common prefix it increases the chances of SQL injection (inserting rogue data) by hackers. Not to worry though, there is a plugin that you can temporarily enable to change this, aptly named Change Table Prefix.

Strong Passwords

It’s important that anyone who has a high level of access (Administrator, Editor) to your website has a strong password. WordPress generates strong default passwords, but these are often changed by users. This is where the Minimum Password Strength plugin is useful to prevent your users from having weak passwords.

This advice also stretches to your FTP and database passwords. Test how strong your passwords are, and if they’re weak, change them immediately.

Lockdown your Login Form

Prevent users (or hackers) from having any more than 5 attempts at a time at logging into your site. If they enter the login details incorrectly more than 5 times then they will be locked out for a certain period of time. Limit Login Attempts will do the trick for this.

Keep WordPress up to date

Last, but certainly not least. As I said at the start – if you’re worrying about which security plugin to use and your version of WordPress is not up to date then it’s a pointless exercise. Updating your WordPress website is quick and easy so there really aren’t any excuses. If you are running an older version of WordPress (older than 3.3) then you might run into compatibility issues (with Themes & Plugins) so you might need to employe a developer to guide you through the process – it’ll be worth it though as you’ll also get all of WordPress’ new features.

If you have lots of WordPress sites to maintain, then it may be worth signing up to a service such as WP Remote, where you can oversee and update all of your sites and their plugins.

It’s also worth keeping your site ‘clean’ by:

• Removing unused themes
• Removing unused plugins
• Removing unused users (especially those with ‘administrator’ privileges)
• Backup your site so if you are hacked you can restore your site back to a pre-hacked state.

All of the above is simple advice to follow and will play a large part in keeping your site secure. It’s certainly worth being pro-active in this respect as if you get hacked the cleaning up process isn’t so nice, plus has potential time and cost implications.

• The agency you’re working with
• The client who commissioned the project
• An end user (someone who is actually going to use the website)
• An interested ‘stakeholder’
• You

The bullet points above can cover a vast amount of people both technical and non-technical who present their feedback in a number of different ways. Feedback, however, is only useful if it’s presented in a meaningful fashion. So if you’re giving feedback, here are a few things to consider.

Structure your feedback. Instead of writing a few paragraphs of text trying to describe what the problem is, follow a structure – maybe something like this:

• What you did? (Action)
• What were you expecting to happen? (Expected)
• What actually happened? (Result)
• Reference any documentation referring to why the expected and result might be different.

Use the correct channels. If the correct process is to report a bug in the bug tracking system then do just that. If you need clarification on items then using emails or tools such as Skype might be useful, but your bugs must go in one central system. Here are some reasons why:

• Helps to keep them structured
• Ensures they are fully visible to all developers (one might know how to fix that particular issue)
• Helps identify duplicate issues
• Additional documentation & feedback can be stored
• The status of the bug (in progress, completed) can be tracked

Provide evidence. Providing screenshots of the error will give the developer a better chance of understanding your problem and thus fixing it. Any further information you can provide is also useful although usually one item is sufficient unless the developer requests more.

Environment. If this is a WordPress problem then noting the version of WordPress is very useful. If you are reporting an issue with the presentation of a website then stating the operating system and the browser you are using is also essential. If you’re not sure of these details then just visit the Support Details website and it will list it there for you.

Replication. Can you replicate this issue? If you have only seen this bug once then it may have been an edge case (something that happens rarely, for a small number of users). If you can replicate this frequently in a number of scenarios then these extra examples add extra weight to your bug report.

Feature, change or bug (or user error)? Just because you have found something you think is a bug, it might not be. It’s important to categorise your findings as the categorisation determines the context and the actions taken.

• Bug – Something isn’t working as expected. For example: the requirements states that when a user signs up to the site they should receive an email containing a username and password. The password is not included in the email.
• Change – Something that contradicts the requirements. The requirements state that user is redirected to the homepage when they login. The user should actually be redirected to their account page when they are logged in.
• Feature - An enhancement to the system that is otherwise missing from the requirements. If the feature is substantial then it may require further analysis in order to implement as the inclusion of this feature might have a knock on effect on the rest of the website. A feature should be treated like a new requirement.
• User error – The user has not completed the process correctly. Although this isn’t a bug, it might be worth finding out why the user has made an error. It might be a problem with the instructions given for a process, or it might be an underlying problem that leads to further bug reports.

It depends on your agreement with the developers in question but in general bugs should be fixed without incurring any additional cost. Changes & Features however may incur extra costs and additional time needed to complete the tasks. This is another reason why it’s important to get your requirements correct in the first place.

Identifying the priority. It may be that your developer(s) do not work full time on the project, therefore reporting bugs sensibly prevents you being ‘the boy that cried wolf’. Although different organisations have different support agreements, in general there are four levels of priority:

1. Urgent – Must be fixed as soon as possible. Examples of this are that your website might be down or an incorrect stylesheet may have skewed your entire website.
2. You must be working towards a fix/change towards this item with an ETA of when it will be delivered.
3. Investigate these issues and provide a fix/change when time allows – there may however be a temporary workaround available for this issue.
4. These are reported bugs/changes that are desirable to fix as they might be very small or only happening in edge cases. It might also be because it’s a big task for a small benefit.

So it’s quite clear that urgent means urgent in the sense that your website can’t be viewed. It doesn’t mean urgent in the sense something is the wrong colour. There are cases however when clients can escalate an issue to be urgent outside of these guidelines if a bug/change is causing a ‘business risk’.

You might also be questioning what place the 4th ranked issues have. Exploring smaller errors may actually uncover fundamental problems with the system that are causing other bugs. Also you might be able to fix these smaller issues at the same time as fixing more important issues with hardly any additional time. These bugs might also be good stomping ground for new developers to familiarise themselves with the system.

So there’s more than

“My website’s not working”

to identifying a bug, change or feature request. Hopefully these tips will help you, help your developers to help you.

Steve is an awesome developer

Above is a bad example of a testimonial.

Testimonials are common across all product and service websites, but most of them can appear worthless for a number of reasons. If you’re going to add testimonials to your site here’s a few tips to follow…

1. Quantity – Make sure you have more than 1 or 2 testimonials. Keeping them fresh will mean the user stays interested in what customers have to say about you.
2. Specific - Testimonials that say “Company A are a great company” means nothing. If you can get your customers to specifically state what is great about you (i.e. your product/service) then a user is more likely to explore that item further, adding more weight to the testimonial.
3. Source - Include the source in your testimonial. Include their name, their company and a link to their website. Doing all three adds further prestige to the testimonial, especially if the source is a respected one.
4. Current – If your testimonials are recent then adding dates to show the user that your product/service is good today, not a year ago. Have you ever seen a restaurant with ‘Restaurant of the Year’ in the window and then when you read the small print it says 2007. Something that was good 5 years ago isn’t necessarily going to be good anymore.
5. Presentation – Your testimonials are no good if users cannot see them. Put them in prominent, relavant areas and make it obvious they are a testimonial (usually indicated by speech bubbles). I often find them hidden away on a testimonials page however the aim should be to integrate them into content within your site.

“Steve is an awesome WordPress developer who produced quality work, to the agreed timescale on stomptheweb.co.uk” (2012) – Jane Smith, Marketing Manager.

Above is a much better example taking into consideration some of the points I raised above.

Although a testimonial is a pretty basic part of your site, I hope the five points above have given you food for thought on how to improve them as it might be the difference between a customer choosing your business over another.

Another requirement should be that the site is lightweight and quick to load as the user may be using a 3G connection (or worse) to browse your website. Loading large images, therefore, is out of the picture (pun intended) so a usual technique is to not display them on mobile devices, something like this:

The HTML

<div id="example"></div>

The CSS

#example {
 background-image:url('images/example.png');
}
@media all and (max-width: 600px) {
 #example {display:none;}
}

Unfortunately most mobile devices (such as the iPhone) would still load the image but then choose just not to display it. If the image is large then the user could be waiting over 10 seconds for the page to load, which is obviously not good enough.

Instead, by giving the div that displays the image a parent div – that parent div can be hidden and therefore child divs are not even requested – like in the following example:

The HTML

<div id="example">
<div></div>
</div>

The CSS

#example div {
 background-image:url('images/example.png');
}

@media all and (max-width: 600px) {
 #example {
 display:none;
 }
}

This one simple technique could have a big impact on your sites speed on mobile devices so if you are looking for better performance then applying the above should do just that!

I stayed in a house near Haymarket in Edinburgh with the Human Made team and other like minded WordPress guys.. The aim of the week was to do client work, spend time doing personal projects, learn from each other and generally talk WordPress. Oh and attend WordCamp too.

It didn’t start great…

Within the first few hours of arriving Fifa was setup on the giant projector. I wish I had one of these at home.

There was work to be done and it was very odd to be around people who have their computers (mainly Macs) open almost 24/7. Most people would call it nerdy…but I like to call it geeky. Here’s the chart if you’re confused.

On the Wednesday night we did get around to some pre-WordCamp presentations from Tom Wilmot (on his BackUpWordPress plugin) , Joe Hoyle (on optimising for speed) & Matthew Haines-Young (for a potential WordPress solution to serving retina images). I personally think they should have stood up at WordCamp as the topics were all useful and well demonstrated. Comment of the night goes to Joe, which, to paraphrase..

That section there took 0.098 seconds to load – but this part took 0.178 seconds to load, which is unacceptable.

High standards or pedantic – I’ll let you decide

WordCamp Talks

So on the Saturday, WordCamp began. Here were my highlights over the two days although you can view the entire list of presentations here:

Customizing WordPress Admin for Clients by Noel Tock

It’s easy with WordPress to follow the norm – in fact it’s probably recommended. Despite some people’s views there are standards in the WordPress community for theme and plugin development that attempt to keep it consistent, beautiful and secure. This way of thinking however, may promote a lack of creativity – especially in the admin area of WordPress.

The main three points Noel touched on are:

• Minimising the admin area to reduce unnecessary navigational elements – therefore increase usabilty
• Alternative methods of displaying the edit post screen for non-standard custom post types
• Customising in the front-end – a function WordPress introduced in 3.4.

Full presentation available here

How I made WonderThemes by Kimb Jones

This talk by Kimb wasn’t a technical talk but touched rather on his experience of building a theme club for WordPress themes (WonderThemes). He gave everybody the run down on the hours and time it took to get up and running and some decision he made along the way, bad or good.

Although WonderThemes hasn’t gone exactly how he has planned it so far there’s no doubt that it’s a project to look out for, however it may continue, so good luck Kimb.

From a personal point of view I have been watching theme shops pop up all over the place in the last 4 years and I’ve been meaning to do it myself. Unfortunately I’ve always found an excuse, so it’s nice to see the story of someone who did have the balls to give it a go.

WordPress and Web Accessibility: Why It’s Important by Graham Armfield

The last talk of the weekend focused on the accessibility of WordPress. Graham informed the audience what accessibility meant; i.e. to make it available to everyone and promote inclusion.

So, for example a small set of users may have poor motor skills and cannot use a mouse to navigation through the site. The keyboard then becomes a better option for them using the TAB key to navigate through the site. So try doing this in the WordPress administration area and you could be forgiven for thinking that accessibility hasn’t even crossed the mind of anyone who has developed or tested it.

All that’s easy to say sitting here, however the talk also provoked a reaction from the audience to take this action to the core group and assist them in making WordPress more usable.

A useful, and possibly pivotal talk.

Full presentation available here

More?

I’ll certainly be going to more WordCamps. The one in San Francisco looks pretty tasty to me and it seems like they have a cool community in the Netherlands. If you truly are interested in the future of WordPress then these are the places to be – albeit if you’re interested in a good night’s sleep then I’d probably stay away!

Focus

It’s hard when you have other commitments (such as a full time job & a life) to allocate time to improving your skills but freelancing full time gives me the opportunity to do so and I’ve found that this can take a number of different forms; whether it be reading tutorials, learning by doing or via the experiencing a vast range of clients and their different ways of working – there’s no doubt that my skill set has drastically improved over the last 9 months.

WordCamp

The other element to having more time is the ability to be more involved with the community of which WordPress has a fantastic one. Whether this involves contributing in the support forums or discussing best practices on other blogs the online WordPress community can only be described as vibrant… and then there’s WordCamp.

WordCamps are annual WordPress related conferences that take place annually. There are WordCamps that happen all around the world but the UK version is taking place this year in Edinburgh on 14-15th of July.

WordPress Retreat UK

To add to this I’ll be staying with the brilliant Human Made and others in a flat in Edinburgh the week prior to the event to talk WordPress, do WordPress and generally chill out with some cool and like minded people – a.k.a. WordPress Retreat. I’ve often seen people tweet about attending WordCamp so it’s great to actually get to go for one for the first time.

I hope to be doing some more WordPress related blogging and tweeting when attending the event and I’m also putting my name down to be one of the WordPress geniuses (like the ones in the Apple store). If you haven’t bought your ticket yet you should do as tickets are still available at a mere £45. Hope to see you there!

There is only so much that WordPress can contain in core however – if every requirement was convered and everybody got their own way then it would be a sprawling CMS that nobody would know what to do with.

So, enter stage left – plugins. There are two excellent plugins that regularly I use to add subtle but what I consider essential functionality to both the UI and the UX of websites I create.

1. Menu Rules

The first one is an excellent plugin by Phill Brown. As Phill puts it:

In WordPress there’s no way to apply context to the menu system. Menu Rules solves this problem and gives you a framework to write your own menu extensions.

In other words he has built a plugin that allows to place conditional rules around the current page menu items. So ,if you have a top level menu item called Products and you wish to keep this item highlighted on a single product (even if the product isn’t in the menu) then you can set the conditional in which to do that.

WordPress provides classes such as current page item and. current page ancestor for CSS styling but this provides a conclusive method of ensuring consistsncy across the site and improving the user’s experience.

2. WP Custom Menu Filter Plugin

The second plugin allows you to add further conditionals to menu items as to whether the user is logged in or not. For example, if you are logged in you do not want to see the login button again, nor do you want or need to see a registration link.

Similarly if there are pages exclusive to users that are logged in then you these should not be shown if the user is not logged in. Again this is an excellent plugin for keeping the user interface clean as well as preventing users from visiting pages that they are mot meant to see.

I’m not a huge advocate of using lots of plugins on sites I build so I tend only to use ones that i think add real value as well as speed up my delivery times without compromising the quality. I hope you find these plugins useful too.

Unfortunately I can’t catch everyone with every skill I possess, so I have to fight my battles and stick to what I know best. That, I feel, is the best strategy for a freelancer.

The one disappointment that comes with the territory is that I can’t feature all the work I have done on there, as I have worked for lots of agencies with who I sign a Non Disclosure Agreement (NDA), meaning I work ‘for them, as them’.

This means that a lot of the work I do goes unseen and whilst I do update my portfolio with projects that I can put on here, my real portfolio runs further afield.

With that said, if you are looking for examples of my work then my portfolio is a great place to start, however if you want to know more about my skills then please get in contact with me and I can tell you more about me and what I can offer to you or your business.

1. The first step is to list everything that you want. Do you want a search facility? Twitter integration? Contact form? If there are multiple decision makers then get everybody’s opinions. Once you have that list together you’re ready for step two.
2. Step two is to prioritise your requirements from number 1 all the way down to the last and most insignificant one.
3. Next, you need to decide which of the requirements are essential in order for the project to succeed. For example, if you want an online shop then having a checkout and payment is a must, however automatically reducing stock levels is something that might be useful, but not essential. Put a ring around these essential requirements and make them stand out so whoever is working on your site knows what they have to do first and foremost.
4. The last stage is to apply MoSCoW rules to your requirements. Next to each requirement put an M, S, C or W:

• The items that you have previously highlighted are MUSTs and the system wouldn’t work without. (M)
• Next you’ll have items that SHOULD be in the project – they are not essential but they are heavily desired. (S)
• The next bracket are the COULDs.  These could be items that have been suggested could be good for the project – in the context for a shop, maybe a currency convertor might be useful, but if it doesn’t make it in then the rest of the site is going to function just fine. (C)
• The last set of features are the ones that WOULD be included in the future, such as in phase 2 of a project. These features could be dependent on budget or the success of the first part of the project. It’s important to highlight these as it encourages you to think about the direction of your project and how it can be added to and improved in the medium-long term. (W)

Once you have your prioritised list then they are ready to be priced up. If the price is too high, consider moving items down the list from SHOULD to COULD, or COULD to WOULD.

Having this list also creates discussion. For example – something you think is a MUST, might not be as essential as you thought – therefore you could move it down the list, save time and therefore save money.

When the list is complete you can then use it to check against when the project is delivered. It’s written down in black and white and if a requirement doesn’t exist then you have the right to go back and ask for it. Alternatively, if something wasn’t captured in the first place then you should expect to pay an additional cost for it – however by carrying out the process above there’s less chance of you missing requirements.

One last comment to make is that this list is intended to outline WHAT needs to be done and not necessarily HOW – that is a different discussion altogether. However if you know the WHAT then the experts should be able to figure out the HOW for you.

Insecurities resulting from poor server configurations or software built by developers could result in a website being hacked or data being stolen. There are lengths you can go to ensure that your site is safe however sometimes it’s best to hand it over to the experts.

The North East Centre for the UK Government’s Warning, Advice and Reporting Point (nuWARP), based at Northumbria University, are a recognised national centre of excellence in the UK in digital security. They offer: