Helping customers to find things quickly reduces frustration and can lead to higher sales. The search functionality provided out-of-the-box by WordPress is at best considered basic. With customer expectations set by the likes of Google and Amazon, how can we improve the often overlooked on-site search experience?
The naming of things is notoriously difficult in the world of programming. BEM (Block, Element, Modifier) is a naming convention used by developers to name HTML and CSS classes.
The idea behind it is to create a naming convention that makes it easy to identify the different parts of a block and the elements within.
Using a standardised naming convention makes it easier for everyone on a team to understand how things are organised.
Handling CSS specificity across an entire codebase can be challenging. With BEM, every selector has the same specificity, so you never have to worry about specificity issues.
The naming convention and syntax is:
- Block – the name of the component. Something that communicates meaning while being short enough not to interfere with readability. For example
- Element – an element of the block. Separated from the block name with a double underscore. For example
- Modifier – allows for things to be styled differently. Separated from the name of the block or element by a double hyphen. For example
When I started learning BEM, the posts I stumbled upon were overly simplistic. They gave a good introduction to BEM—but they ended there. Because of this, I created overly complex class names that attempted to mirror the hierarchy of the block (i.e.
.case-studies__item__link__image). The trick is to keep things flat, there’s no need to match the hierarchy of the markup.
Using the BEM naming convention
BEM and Sass, a perfect partnership
A key concept in developing maintainable front end code is avoiding repetition by identifying patterns in our HTML and CSS and abstracting those into reusable components.
BEM works well with a CSS pre-processor like Sass, for several reasons:
- You can break your components up into individual files. These components can then be used across multiple projects with minimal additional effort.
- You can nest elements and modifiers within the parent block class by using the Sass parent selector (&). This makes for super clean and organised files.
BEM and utility classes, a powerful combination
When you’ve built up a library of reusable front end components, being able to make use of them within different contexts can be a challenge. You might need to change a background colour, adjust a components padding or margin.
Utility classes are single purpose classes used for simple tweaks to an element’s appearance. Having a collection of utility classes allows us to easily make these minor adjustments without having to create modifiers for each use case.
Utility classes can be applied to the block or any child element. In the example below, we’ll highlight the first case study with a different background colour and a larger heading.
I first learned about BEM from my colleagues at iWeb. The front end team were talking about atoms, molecules and organisms around the same time… I was skeptical of the whole thing at first—I was afraid the process would be too difficult, making things more complicated than they needed to be. But then I learned that there’s actually some method to it all.
Once you’ve wrapped your head around the syntax, BEM is a great way to organise your CSS and makes it easier for other developers to read and understand. I’ve been using it for years, and hopefully it will help you too. If you’re interested in learning more about BEM, I recommend checking out its website and reading this post by Harry Roberts.
I wanted to share a service I found recently, redirect.center, a personal project by Udlei Nati that allows you to easily redirect your domain name just by changing its DNS settings—simple to implement and requiring no maintenance.
The service can be used for several different applications:
- Redirect from the bare domain (aka apex, root or naked) to www.
- Redirect from an old domain to a new domain, with or without preserving paths.
- More complex migrations, which transform paths and query strings.
Server migration without updating DNS records
I host a handful of projects on a DigitalOcean Droplet. Migrating sites from one Droplet to another every other Ubuntu LTS release. Updating DNS records when switching between servers is a pain.
I’ve been playing with redirect.center to see whether it can help avoid some of this pain.
A canonical name (or CNAME) record is a type of DNS record that provides an alias for another domain.
We can create a single A record somewhere which points to our Droplet IP (for example
dns.example.org). All our other domains can then reference this with a CNAME record, so
www.example.com becomes an alias of
Future changes to the Droplet IP address can be made with a single DNS record change of
Unfortunately, CNAME cannot be used on the bare domain. This is where redirect.center comes in, it allows us to redirect users from the non-www domain to the www equivalent. The only limitation I’ve found to this approach is that it can’t redirect HTTPS requests—it doesn’t have your SSL certificate.
I need to experiment with DigitalOcean’s Reserved IPs, since this sounds like a perfect solution… I’ve never tried it before, but something to play with next.
I wanted to share the redirect.center service—if you need to quickly redirect domains, it might save you some time.
You’re placing a lot of trust in the provider. If the service was compromised, it could be used maliciously—namely by allowing a third party to modify and redirect traffic as they wish.
A paid service was being considered that would give more confidence for commercial use. It would also have allowed for redirecting from the HTTPS protocol. However, there is no sign that this will be taken forward.
For personal use, I think it’s an amazing service. It provides a simple way to set up redirection from one domain name to another—quick and free!
I had a pleasant time yesterday visiting Staffordshire University. Ian and I went along to represent iWeb. We were there along with representatives from a number of local companies in the web industry. The University had put on a session for second year web students. The aim was to help prepare them for making placement applications.
We went around the room spending five minutes with each student. Meeting, reviewing and offering our advice on portfolios and CVs.
The tables were then turned and it was my responsibility to deliver a short, five-minute talk on what life is like working in a web agency.
I wanted to put together a resource we could share with students. I put a post together over on the iWeb blog with advice and tips from my perspective as a graduate who has been through the placement process.
LinkedIn, Ashley Madison, Yahoo! and Mossack Fonseca… what do these companies all have in common? Large-scale data breaches have received much coverage in the media recently, prompting a renewed interest in online privacy and security. Today, we’re going to look at WordPress website security and how we can help prevent ourselves from falling victim to an online attack.