Discover best practices and typical errors in WordPress front-end development. Learn about efficient styling, proper use of classes, component independence, and more for optimal site performance.
Two decades after it was first released, WordPress still stands as a preferred choice for website development. Its versatility caters to a myriad of business needs, from blogs to e-commerce websites.
However, to fully leverage WordPress’s potential, understanding best practices in front-end development is crucial. In this post, we aim to shed light on the key areas that developers should focus on for optimal WordPress front-end development, including CSS, JavaScript, and Gutenberg editor best practices.
We also explore common mistakes that front-enders often make and provide insights on how to avoid them. Whether you’re a seasoned developer or just starting out, you are sure to find something valuable for yourself below.
Let’s get started!
Always implement the navigation menu using the default WordPress menu structure to minimize back-end customization. The WordPress default menu structure for markup before back-end implementation should look like this:
<nav class="my-menu-class">
<ul>
<li>
<a href="page1.html">Page 1</a>
</li>
<li>
<a href="page2.html">Page 2</a>
<ul>
<li>
<a href="subpage1.html">Subpage 1</a>
</li>
<li>
<a href="subpage2.html">Subpage 2</a>
</li>
</ul>
</li>
<li>
<a href="page3.html">Page 3</a>
</li>
</ul>
</nav>Using this structure and adding CSS and JavaScript to the mix, we can create virtually any custom menu design.
Also, make sure to avoid assigning classes to the <nav> tag apart from the main class: <nav class=”my-menu-class”>.
When creating icons, it’s good practice to use an SVG sprite instead of a font icon or a block of SVG code. This keeps the code readable and maintainable at the front end while also helping back-end developers efficiently implement it. Additionally, SVG is fully customizable with CSS and JavaScript.
Example
Creating an SVG sprite (sprite.svg):
<svg width="0" height="0" class="d-none" xmlns="http://www.w3.org/2000/svg">
<defs>
<symbol id="arrow-right" version="1.1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512">
<path fill="currentColor"
d="M310.627 438.627l160-160c12.497-12.496 12.497-32.758 0-45.255l-160-160c-12.497-12.496-32.758-12.496-45.255 0s-12.497 32.758 0 45.255l105.373 105.373h-306.745c-17.673 0-32 14.327-32 32s14.327 32 32 32h306.745l-105.373 105.373c-6.248 6.248-9.372 14.438-9.372 22.627s3.124 16.379 9.372 22.627c12.497 12.497 32.758 12.497 45.255 0z">
</path>
</symbol>
<symbol id="arrow-left" version="1.1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512">
<path fill="currentColor"
d="M201.373 438.627l-160-160c-12.497-12.496-12.497-32.758 0-45.255l160-160c12.497-12.496 32.758-12.496 45.255 0s12.497 32.758 0 45.255l-105.373 105.373h306.745c17.673 0 32 14.327 32 32s-14.327 32-32 32h-306.745l105.373 105.373c6.248 6.248 9.372 14.438 9.372 22.627s-3.124 16.379-9.372 22.627c-12.497 12.497-32.758 12.497-45.255 0z">
</path>
</symbol>
</defs>
</svg>Every <symbol> has an id related to the icon type, such as arrow-right.
An SVG embedded into HTML code:
<svg class="icon-svg">
<use xlink:href="images/sprite.svg#arrow-right"></use>
</svg>In the markup, we can target an icon this way: sprite.svg#symbol-id
Thus, an SVG icon will be fully scalable and maintainable:
Here is what you gain by this:
Besides, background images aren’t fully compatible with some image editing WP plugins.
Examples
Image Blocks:
<figure class="wp-block-image">
<img src="images/img1.jpg" alt="image description" />
</figure>
Quote Block:
<blockquote class="wp-block-quote">
<p>This is a quote.</p>
<cite>- Author</cite>
</blockquote>For a pullquote the structure is identical, but the class is wp-block-pullquote.
Columns Block:
<div class="wp-block-columns">
<div class="wp-block-column">
<!-- content column 1 -->
</div>
<div class="wp-block-column">
<!-- content column 2 -->
</div>
</div>This structure is useful when we create generic column blocks with simple text columns or text-image columns of different varieties, such as text-left-image-right, text-right-image-left, etc.
We can control column properties, and specifically the order of blocks, via CSS.
There’s no need to create custom ACF fields. Instead, we can create custom fields simply from Gutenberg Blocks without any additional editing at the front end, since they’ve already been made according to the Gutenberg Blocks standard.
<div class="info-section">
<div class="container">
<!-- content here -->
</div>
</div>
<div class="product-section">
<div class="container">
<!-- content here -->
</div>
</div>The “info-section” and “product-section” can now be created as two independent ACF Blocks. Additionally, they can be easily implemented in the Gutenberg Editor Preview.
<div class="container">
<div class="info-section">
<!-- content here -->
</div>
<div class="product-section">
<!-- content here -->
</div>
</div>The “info-section” and “product-section” are dependent on the “container” and can not be created as independent ACF Blocks. Actually, this is possible, but we need to fix the container issue here.
This means that you need to identify global elements in the design and style them globally. For similar elements that are not global, you need to override them as private elements.
Generally, all the elements in the design do not match such global elements. Therefore, we can exclude them entirely while styling by using the CSS negation pseudo-class :not().
Example
ul:not([class]) {
// global properties
}Where [class] is a private ul.
Example
.font-roboto {
font-family: 'Roboto', Arial, sans-serif !important;
}When there is a fixed header or smooth scroll to a certain section, correct styling is of paramount importance to prevent the admin bar from overlapping the page content. Use the –wp-admin–admin-bar–height CSS variable to fix that issue.
Example
Bad Practice:
const btn = document.querySelector(".btn");
btn.addEventListener("click", (e)=> someFn);
Good Practice:
const btn = document.querySelector(".btn");
if (btn) {
btn.addEventListener("click", (e)=> someFn);
}Why perform this validation? The thing is that the “btn” we’re targeting here may be located on the Homepage, working correctly there. However, if we go to the About page, an element with that feature may be missing. The page won’t find that element and consequently throw an error.
The validation helps us avoid errors in the console. If we don’t perform it, the page, under the worst-case scenario, could simply break apart.
Sometimes, back-end developers implement blocks hand-coded by front-end developers using the WordPress block editor (no-code editor) such as Gutenberg.
However, that work should be left to front-end developers since they know the actual design needs of those blocks.
Front-end development shouldn’t be limited to creating WordPress themes with HTML, CSS, and JavaScript. In many cases, front-end developers can customize blocks in the Gutenberg editor to avoid unwanted CSS modifications and the back-and-forth between the front-end and back-end teams.
By using Gutenberg to fix common UI issues, front-end developers save time for the teams at both ends.
With these best practices in mind, we are setting a solid foundation for efficient and error-free WordPress front-end development.
However, even with the best practices, it’s common to stumble upon certain pitfalls. Let’s discuss some of the common mistakes made during WordPress front-end development process, and how they can be avoided to ensure a smoother and more efficient development workflow.
Study the design first, identify global page elements, and style them according to the design style guide. The most common elements are h1-h6, p, a, ul, ol, form, and input. By correctly implementing them, we can create many pages or posts via the Gutenberg Editor itself.
When building a WordPress-based markup, you might need to target a specific page or pages with your CSS.
One common way to do that is by adding a class to the <body> tag. It allows you to prefix your CSS selectors with the class, thereby limiting the scope of those styles to just that page.
While this approach works, it can lead to an overabundance of classes in your <body> tag, which can make your HTML code messy and harder to read. This is particularly true if you’re adding a class for every page that’s not the homepage.
A better method to handle this in WordPress is to target all pages that aren’t the homepage using the CSS negation selector: body:not(.home). This way, after the WordPress implementation, we can get additional classes in the body and use them whenever needed.
When certain elements do not match a specific generic design, it’s recommended to reach out to the client via the project manager and avoid hardcoding.
Random hardcode fixes done during markup development are often left out during the implementation phase, because implementation is done with logic and the arbitrary hardcode fixes may not always fit in.
As WordPress sites are very flexible and scalable, we must create UI components as independent and scalable as well. Gutenberg Blocks are extensively used these days so we should strive to create UI blocks that can be modified in WordPress.
As the paragraph contents are mostly generated by the editor, adding classes to those paragraphs is bad practice. The solution is to wrap those types of paragraphs in an additional wrapper and assign a class to it.
Front-end development for WordPress requires a meticulous understanding of best practices and common mistakes.
Attention to global and private styling, efficient use of classes, component independence, and careful handling of tags are all crucial to a site’s performance and quality. Using code editors like Gutenberg can also streamline the collaboration process between front-end and back-end teams.
By avoiding unnecessary hardcoding and maintaining clean, logical implementation, developers can create robust, scalable, and error-free sites. Proper consideration of these factors significantly optimizes the development process and the final product.
Are you in search of seasoned WordPress developers boasting a broad and diverse skill set? Unleash the power of WordPress with GetDevDone. We offer an array of services that cater to your every need:
Need help with something else? Reach out to us. Your satisfaction is our priority, and we’re always here to lend a hand.
Discover how we transformed Winchester White's website with WordPress plugins integration, overcoming technical challenges and streamlining property listings to enhance user experience and website performance.
Want to know how custom WordPress website development can boost your business's growth? Follow this comprehensive guide, where we explore various aspects from costs to challenges.
Your WordPress website's speed is an important UX characteristic that can seriously impact your search rankings. Read this post to learn how you can make your site faster to boost your organic traffic.