CSS JavaScript WordPress

WordPress Front-End Development: Best Practices and Common Mistakes

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.

thumbnail

TABLE OF CONTENTS

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! 

WordPress Front-End Development Best Practices

HTML Best Practices

#1: Use the default WordPress menu structure.

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”>.

#2: Use SVG sprites for icons instead of inline SVG and font icons.

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:

  • Icons are third-party independent.
  • You can change the CSS properties of an icon via the SVG selector.
  • You can operate SVG animations via CSS / JavaScript.
  • You can manipulate icons in the back end by using just the icon id.
  • Icons are now a semantic and accessibility standard.
  • This method can be used by back-end developers to create customizable icon libraries.

#3: Use the inline <img> tag and control it via CSS instead of using it as an inline background image.

Here is what you gain by this: 

  • Better usability
  • Better accessibility
  • Better performance (Lazy Loading)
  • Better search engine optimization

Besides, background images aren’t fully compatible with some image editing WP plugins.

#4: For generic content, components, or elements, use default HTML tags without any class or id for h1-h6, p, a, ul, ol, form, input, and other tags.

#5: For projects with Gutenberg Blocks, use related blocks markup structure and style them accordingly to avoid repetitive CSS fixes.

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.

#6: Whenever possible, create block-based markup for pages (e.g., full-width blocks), instead of putting them inside a container.

Good Structure

<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.

Poor Structure

<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.

CSS Best Practices

#1: Style h1-h6, p, a, ul, ol, form, and input elements that are parts of general page building blocks globally without any additional CSS selectors.

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.

#2: Create classes for the site’s fonts so that you can use them in the WordPress editor while customizing the blocks.

Example

.font-roboto {

    font-family: 'Roboto', Arial, sans-serif !important;

}

#3: Style components separately without dependencies on other variables. This way, you can pass them around any pages or sections.

#4: Modify some styles for the admin view of the site pages. 

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.

JavaScript Best Practices

#1: Always check if the element is available in the DOM before executing the actual implementation.

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.

Gutenberg Editor Best Practices

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.

Common WordPress Front-End Development Mistakes

#1: Incorrect styling of global page elements.

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.

#2: Adding extra classes to the <body> tag.

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.

#3: Hardcoding styles to match the design.

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.

#4: Making components dependent on parent blocks.

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.

#5: Adding an extra class to the paragraph tag.

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.

To Conclude

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.

Premier WordPress Development Solutions by GetDevDone

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:

  • WooCommerce Development
  • Maintenance and Support
  • Core Web Vitals Optimization
  • Theme Customization
  • Custom Theme Development
  • Builder-Focused Theme Development (Elementor, Divi, WPBakery, and more)
  • Assistance with website migration

Need help with something else? Reach out to us. Your satisfaction is our priority, and we’re always here to lend a hand.

Anup Tamang

Meet Anup K. Tamang, a seasoned Full-Stack Developer at GetDevDone. With a wealth of experience in web development under his belt, Anup has successfully honed his skills to master both front-end and back-end processes.

But Anup's passion extends beyond coding and developing innovative websites.

An enthusiastic blog writer, he loves to share his knowledge with others. His mission is to empower those who are eager to excel in web development by sharing his insights, experiences, and best practices.

For more professional insights from Anup, connect with him on LinkedIn.

Related Blog Posts