Honey Butter

Posted by Honey Butter on September 30, 2025

A Clean Approach to WordPress Builds

Categories

First off, nothing here is groundbreaking.

I’m not a WordPress expert, and I’ve never been the type to rely on Elementor or hack apart someone else’s prefab theme. From pretty early on, I knew I’d rather start fresh. For me, it’s never been about shortcuts—it’s about learning a little more each time, writing cleaner code, and organizing things in a way that makes sense. Every project is another opportunity to refine, simplify, and deliver a site that’s fast, reliable, and thoughtfully designed for the client.

The Must-Have Files

When starting a new theme, I like to keep things minimal. These are the essentials I set up right away:

  • style.css → Required for every theme. Holds the theme name, description, version, and metadata. Also doubles as the main stylesheet.
  • functions.php → The engine room. This is where the important setup and logic live.
  • index.php → The fallback file WordPress will use if nothing else matches.

Core Templates (No Blog Structure)

  • header.php → Site header, <head> markup, opening <body> tag.
  • footer.php → Site footer, closing markup, and scripts.
  • page.php → Basic template for static pages.
  • front-page.php → Optional, but handy for a dedicated homepage or landing page.
  • 404.php → A custom error page to keep things on-brand.

Nice-to-Haves

  • template-parts/ folder → Reusable chunks of code (headers, footers, heroes, etc.).
  • screenshot.png → The theme preview in the WordPress admin.

Putting functions.php to Work

I lean on the functions file heavily. It centralizes a lot of logic that would otherwise be scattered, which keeps the backend lean and predictable. Typical jobs include:

  • Registering menus so clients can manage navigation easily
  • Loading CSS and JS files in a clean, controlled way
  • Defining custom image sizes for a better media library
  • Tweaking Gutenberg galleries to include Fancybox triggers
  • Adding page-specific body classes for targeted styling
  • Registering reusable content blocks (like stats or disclaimers) that can be dropped into multiple templates

This snippet, placed in functions.php, appends the current page slug or template name to the <body> class—making page-specific styling a breeze.

function add_slug_body_class( $classes ) {
    global $post;
    if ( isset( $post ) ) {
        $classes[] = 'page-' . $post->post_name;
     }
    return $classes;
}
add_filter( 'body_class', 'add_slug_body_class' );

Custom Templates for Real-World Pages

In this business, most sites need the same types of pages. The names may change, but the purpose is familiar:

  • Rates pages with clear pricing layouts
  • FAQ pages with toggles for polished Q&A sections
  • Gallery pages built for photography and lightbox interactions
  • Duos or Wishlist pages when the project calls for them

I usually create custom templates combined with ACF fields so the editing experience stays ultra simple. No code, no HTML, no classes—just fields. The templates handle the markup and styling, while clients get a clean, intuitive interface.

For FAQs, I’ve been experimenting with ACF’s Flexible Content fields. Clients can add as many FAQs as they want, or drop in an image block between entries. On the front end, the template outputs consistent markup and the right structure for accordion functionality if needed. Here’s a quick example:

<?php if( have_rows('content_blocks') ): ?>
  <section class="faqs">
    <?php while( have_rows('content_blocks') ): the_row(); ?>

      <?php if( get_row_layout() == 'faq_block' ): ?>
        <div class="faq hb-grid hb-grid--12">
          <h3 class="faq__question hb-grid__col--1-8"><?php the_sub_field('question'); ?></h3>
          <div class="faq__answer hb-grid__col--4-13"><?php the_sub_field('answer'); ?></div>
        </div>

      <?php elseif( get_row_layout() == 'image_block' ): ?>
        <div class="faq-image">
          <?php 
            $img = get_sub_field('image');
            if( $img ) {
              echo wp_get_attachment_image( $img['ID'], 'large' );
            }
          ?>
        </div>

      <?php endif; ?>

    <?php endwhile; ?>
  </section>
<?php endif; ?>

Why Gutenberg, Not Page Builders

I’m a believer in Gutenberg. It’s powerful, flexible, and integrates seamlessly with WordPress. What I don’t use are visual “all-in-one” builders like Elementor. They’re bloated, slow, and leave behind messy code.

Instead, I hand-write my CSS. It’s faster, cleaner, and ensures the design integrity holds up across screens and browsers.

Smarter Logic, Cleaner Output

One shift I’ve made recently is using PHP conditionals to streamline layouts. Many clients want a stripped-down landing page with just a hero image, logo, disclaimer, and “Enter” button—no header, no footer, no extras.

In the past, I’d hide those elements with CSS. Now, I exclude them entirely at the PHP level:

<?php if (!is_front_page()) : ?>

<header class="header">
    <div class="branding">
        <?php if (is_front_page() || is_home()) : echo '<h1>'; endif; ?>
        <a href="<?php echo esc_url(home_url('/')); ?>" title="Visit my home page" rel="home">
            <?php include("path/to/includes/folder/with/svg/logo"); ?>
        </a>
        <?php if (is_front_page() || is_home()) : echo '</h1>'; endif; ?>
    </div>
</header>

<nav class="navigation">
  <?php wp_nav_menu(array('theme_location' => 'main-menu-1', 'container' => false)); ?>
</nav>

 <button class="mobile-menu-button">
    <span class="visually-hidden">Menu</span>
    <span class="bars">
          <span class="bar bar--1"></span>
          <span class="bar bar--2"></span>
          <span class="bar bar--3"></span>
    </span>
</button>

<?php endif; ?>

It’s faster, cleaner, and avoids loading elements that aren’t needed.

Custom Layout Utilities

To speed up development, I’ve built my own grid and flexbox css utilities. Think of them like a slim, personal version of Bootstrap or Tailwind—just the essentials I actually use. This way, I don’t have to rewrite layout CSS over and over.

The result: consistent, lightweight code that keeps projects efficient without dragging in a heavy external framework.

My Core Toolkit

Every build gets a carefully chosen set of tools:

  • Gravity Forms → flexible, reliable forms
  • Mailgun → ensures email delivery
  • Imagify → optimizes images into WebP
  • Slim SEO → lightweight optimization
  • All-in-One WP Migration → backups and migrations
  • GSAP → polished scroll and animation effects
  • Inline SVGs → for styling and animating logos directly
  • WP Rocket → caching and performance boost
  • Google Analytics → tracking and insights

For JavaScript, I stick to vanilla JS whenever I can. If something calls for tabs or accordions, I’ll bring in jQuery. And lately, I’ve been using ChatGPT as a coding partner—especially when I want to test ideas or refine more advanced scripts quickly.

Philosophy of Clean Code

If there’s one thread that ties it all together, it’s this: I value simplicity and intentionality.

That means:

  • Keeping the backend simple and intuitive for clients
  • Writing CSS and JS that are reusable and lightweight
  • Using only the tools that add real value (like ACF, GSAP, or Imagify)
  • Making sure every site feels custom-built, not cobbled together

At the end of the day, I want my builds to feel as good under the hood as they look on the front end. Clean code, streamlined workflow, and design crafted with purpose—that’s the combination I aim for.

And to be honest? I’ll probably rethink all of this in three months. 🙃