Adding fields in Advanced Custom Fields does not automatically make a new section appear on a WordPress site. In this case, the homepage used a Sage-style Blade template system where every section was rendered through its own hardcoded partial. The new promo fields existed in the WordPress admin, but the theme had no corresponding template file or homepage reference. Creating a new promo partial and including it in the homepage template made the section visible.
Issue background
A WordPress site needed a new promotional section on its homepage. The content fields had already been added to an ACF homepage field group and included:
- An image
- A headline
- A subheading
- Paragraph content
- A button
Editors could enter the content successfully in the WordPress dashboard, but nothing appeared on the public homepage.
The active theme used Blade templates rather than a page builder or a generic loop that rendered every ACF field automatically.
Diagnosis
The ACF field configuration was working correctly. The issue was in the presentation layer.
The homepage was assembled from individual Blade template partials. Each existing section had two pieces:
- A dedicated partial responsible for the section’s markup
- An explicit reference in the main homepage template
The new promo section had neither. WordPress stored the field values, but the theme never requested or rendered them.
This is a common misunderstanding with custom fields: ACF provides the data-entry interface and stores the values, but the theme or plugin must still retrieve and display those values.
Resolution steps
- Review the homepage field group. Confirm the exact ACF field names, return formats, conditional logic, and location rules.
- Inspect the existing homepage architecture. Identify how the Blade theme organizes section partials and how those partials are included in the main homepage template.
- Choose a matching section as a reference. Reuse the theme’s established markup, naming, spacing, and responsive conventions rather than creating an unrelated pattern.
- Create a new Blade partial. Add a dedicated template file for the promo section.
- Retrieve the ACF values. Load the image, headline, subheading, paragraph, button label, and button URL according to their configured return formats.
- Guard optional fields. Render each element only when the corresponding field contains a usable value.
- Escape the output appropriately. Escape URLs, attributes, and plain text while allowing only the intended HTML in rich-text content.
- Wire the partial into the homepage. Add the new section to the main homepage template at the required position.
- Add section-specific styling. Create scoped CSS for the layout, spacing, image treatment, typography, and button without changing unrelated homepage sections.
- Match the requested background treatment. Update the promotional content area to use the approved white background while preserving contrast and spacing.
- Test incomplete content states. Confirm that the section remains stable when an image, subheading, paragraph, or button is omitted.
- Test responsive behavior. Review desktop, tablet, and mobile layouts for text wrapping, image scaling, and button placement.
- Clear compiled assets and caches. Rebuild theme assets when required and purge WordPress, hosting, CDN, and browser caches.
- Verify the editor workflow. Change the ACF values and confirm that the frontend section updates without further code changes.
A simplified Blade structure might look like this:
@if ($promo)
<section class="homepage-promo">
@if ($promo['image'])
<img src="{{ esc_url($promo['image']['url']) }}"
alt="{{ esc_attr($promo['image']['alt']) }}">
@endif
@if ($promo['headline'])
<h2>{{ $promo['headline'] }}</h2>
@endif
@if ($promo['content'])
<div class="homepage-promo__content">
{!! wp_kses_post($promo['content']) !!}
</div>
@endif
</section>
@endif
The exact implementation depends on how the theme passes ACF data into Blade views. Some Sage-based themes use composers or controllers, while others call ACF functions directly inside the template.
Final outcome
A new Blade partial was created for the promotional section and added to the homepage template. The existing ACF fields then rendered correctly on the frontend.
The section styling was refined to match the approved design, including a white background for the promotional content area.
Editors could continue managing the image, headline, supporting text, and button from the WordPress dashboard without editing the theme files.
The key lesson is that custom fields and frontend templates solve different parts of the problem. ACF stores structured content, but a custom Blade theme must explicitly retrieve and render that content before visitors can see it.
For help building ACF sections, extending Sage or Blade WordPress themes, or troubleshooting custom fields that do not appear on the frontend, contact Freshy.