ACF Options Page: Divi Global Settings Guide

You usually notice the need for an ACF Options Page after the site is already busy. The client wants one phone number in the header, one support email in the footer, a seasonal promo in a popup, and a trust badge inside a few Divi layouts. At first, those values get pasted into modules or hardcoded in templates. A few edits later, the site starts drifting out of sync.

That's the point where global settings stop being a nice idea and become part of a maintainable build. In Divi projects, that matters even more because content often lives across theme templates, builder layouts, Theme Builder parts, and popup areas. If shared values aren't centralized, every update becomes a scavenger hunt.

An ACF Options Page gives you that control panel. Instead of scattering settings across posts, pages, and modules, you place them in one admin location and pull them wherever the site needs them. Used well, it makes a Divi site easier to hand off, easier to scale, and much harder to break by accident.

Registering Your First ACF Options Page

A typical Divi project hits the same wall. The client updates a phone number, then asks why the header changed but the popup, footer, and sticky bar still show the old one. If those values live inside separate modules, every edit becomes manual and easy to miss.

Registering an ACF Options Page fixes that early. It gives the site one admin screen for shared settings, which is exactly what you want before those values start feeding Divi Builder layouts, Theme Builder templates, and Divi Areas Pro content.

Why register it in code

For production work, I prefer registering the page in code instead of relying only on admin setup. It keeps the configuration version-controlled, repeatable across environments, and harder to lose during a rebuild or migration. That matters on client sites where the options page is part of the site structure, not just a convenience.

The basic setup is small:

if ( function_exists('acf_add_options_page') ) {
    add_action('acf/init', function() {
        acf_add_options_page(array(
            'page_title' => 'Site Settings',
            'menu_title' => 'Site Settings',
            'menu_slug'  => 'site-settings',
            'capability' => 'edit_posts',
            'redirect'   => false
        ));
    });
}

Add that to your child theme's functions.php or, better yet, a small site plugin. I use a plugin when the settings should survive a theme change. In Divi builds, that is usually the safer choice.

A few arguments do the heavy lifting:

• page_title sets the admin screen title
• menu_title sets the left menu label
• menu_slug creates the unique page identifier
• capability controls who can edit sitewide values
• redirect decides whether this page stands alone or acts as a parent for subpages

For a first setup, redirect => false is the cleanest option. You get one editable screen instead of a top-level container with no fields on it.

Name the page for the client

This part affects handoff more than developers expect.

Use labels like Site Settings, Global Content, or Business Info. Avoid labels like Theme Options unless the fields are theme-specific. On a Divi site, editors often need to update business details, announcement text, popup copy, and footer links without knowing anything about templates or modules.

Attach a field group to the page

The options page only creates the destination. It does not create the fields.

After registering the page, create an ACF Field Group and assign its location rule to your new options page. That assignment is the step people skip when they see an empty admin screen and assume the code failed. If you want a second walkthrough from a different angle, this ACF options page implementation guide shows the same basic flow.

A practical starter group for Divi projects usually includes:

• Business details like phone, email, address, and hours
• Header settings like CTA text, CTA link, and utility info
• Footer settings like legal text, social links, and trust elements
• Campaign controls like promo headline, short copy, link, and on/off toggle

That last group is where the Divi-specific payoff starts to show. A simple toggle and message stored once can later drive a popup in Divi Areas Pro, a banner in the header, and conditional content in a saved layout without duplicating the text across each asset.

Plan field names before the site grows

Field naming gets messy fast if you stay too generic. phone works on day one and becomes confusing later. header_phone, support_phone, and popup_phone are much easier to maintain once the site has multiple contact points and multiple teams editing it.

The same rule applies to promotional fields. title and link are too vague. promo_popup_title and promo_popup_link hold up much better when you start wiring those values into Divi modules, popup triggers, or conditional display rules.

Clean naming is boring. It also saves hours later.

Displaying Option Values on Your Site

A common Divi build problem shows up right after the options page is finished. The fields are there, the client has entered the content, and nothing appears on the front end because the template is still looking at the current post instead of the global options store.

The fix is the second parameter in your field call:

<?php
$phone = get_field('header_phone', 'option');

if ($phone) {
    echo '<a href="tel:' . esc_attr($phone) . '">' . esc_html($phone) . '</a>';
}
?>

That 'option' argument tells ACF to load the value from the sitewide options page. Leave it out, and WordPress will try to pull the field from the current post, page, or custom post type. In practice, that is one of the first things I check when an options value looks "missing."

Use get_field() when output needs logic

get_field() gives you the value before anything is printed. That matters when you need to validate, format, escape, or skip empty fields.

A simple CTA example:

<?php
$cta_text = get_field('header_cta_text', 'option');
$cta_link = get_field('header_cta_link', 'option');

if ($cta_text && $cta_link) {
    echo '<a class="et_pb_button" href="' . esc_url($cta_link) . '">' . esc_html($cta_text) . '</a>';
}
?>

This pattern holds up better on client sites because global fields are rarely as clean as expected. Editors leave fields blank. URLs get pasted with tracking parameters. Phone numbers need a display version and a cleaned tel: version. get_field() gives you room to handle that before the markup hits the page.

Use the_field() for simple output

If you only need to print a value and no formatting is required, the_field() is fine:

<?php the_field('support_email', 'option'); ?>

I still default to get_field() for production work. It is easier to maintain once the site grows and those "simple" values start needing conditions or fallbacks.

Using option values inside Divi

You do not need to keep this limited to theme files. A Divi Code Module can print option values anywhere the builder accepts PHP, which makes it useful for quick global elements that are already part of a visual layout.

For example, a top bar announcement:

<?php
$announcement = get_field('top_bar_message', 'option');

if ($announcement) {
    echo '<div class="global-announcement">' . esc_html($announcement) . '</div>';
}
?>

That works well for:

• Header phone links
• Footer support text
• Sitewide legal notices
• Short campaign messages

There is a trade-off. Code Modules are fast for implementation, but they can scatter logic across the builder if you use them everywhere. For repeated elements like headers, footers, or persistent notices, I usually keep the retrieval logic in a template or reusable theme part. For editor-controlled module content, Divi's dynamic content features for ACF-driven layouts are often the cleaner choice.

That split matters even more on Divi sites using Divi Areas Pro. A global promo message stored once in ACF can feed a banner today, then later drive popup copy or conditional layout content without rewriting the source field. Keeping the option value clean at the output stage makes those later integrations much easier.

Integrating ACF Options with Divi Modules

The Code Module works, but most Divi builds become easier to maintain when you let the Builder handle the output. That's where Divi's Dynamic Content feature fits perfectly.

Instead of writing PHP for every field, you can connect an ACF options field directly to a module setting. The editor updates the value in one place, and the Divi module reflects it automatically. For client work, this usually creates the cleanest handoff because the layout stays inside Divi while the content stays inside the options page.

Where this works best

A lot of standard modules can benefit from option values:

Divi module	Good ACF option field use
Text Module	Sitewide notice, support text, header intro
Button Module	Global CTA label and URL
Image Module	Default brand image, footer logo, campaign graphic
Blurb Module	Reused icon text blocks
Call To Action Module	Promo copy managed outside the layout

This approach is especially useful when the same value appears in multiple layouts. A business phone number in the header, contact strip, and footer should come from one field, not three separate module settings.

Connecting the field inside the Builder

The flow is simple:

1. Open a Divi module.
2. Click the dynamic content icon for the field you want to populate.
3. Choose the matching ACF field.
4. Make sure you're pulling from the correct options context.
5. Save the module and test the result.

If you want a deeper look at Divi's field mapping and dynamic output workflow, this guide on Divi dynamic content is useful for understanding how module fields accept external values.

The biggest win here isn't technical. It's operational. Clients can update a headline, CTA URL, or image from a controlled settings screen without opening the visual builder.

What works and what doesn't

This method works best when the field and the module setting are a natural match. Text into text fields. URLs into button links. Images into image modules. Problems usually start when people try to force a complex structured field into a single plain-text module setting.

A few practical boundaries:

• Works well for straightforward one-to-one mappings
• Works less well when the output needs loops, custom markup, or conditional wrappers
• Works well for shared branding elements across Theme Builder templates
• Works less well if you need advanced fallback logic or field transformation

When the output is simple, use Divi's UI. When the output needs branching logic, formatting, or nested fields, use PHP. That split keeps the site manageable.

For agency projects, I often combine both. Editors get clean dynamic fields in normal modules, while more complex components stay in code or specialized layouts.

Powering Popups with Divi Areas Pro

Beyond content storage, an ACF Options Page starts pulling its weight. Global fields can do more than fill text modules. They can control whether a front-end experience appears at all.

That matters for popups, fly-ins, notice bars, and injected content. A sitewide campaign shouldn't require opening multiple layouts just to turn a message on or off. One field on the options page should be enough.

A useful pattern is a simple campaign setup:

• promo_enabled as a true/false field
• promo_title for the headline
• promo_text for the body copy
• promo_button_text and promo_button_url for the CTA
• promo_image if the design needs artwork

A practical popup workflow

Create the fields once on your options page. Then build the popup content in your Divi Area and connect the text, image, and button values to those global fields.

The result is cleaner than editing popup content directly for every campaign. Marketing or content teams update the campaign values in one admin screen, and the popup reflects those changes everywhere it appears.

ACF option fields are also useful for conditional rendering. The practical point isn't just storing the promo content. It's checking whether that content should render in the first place. A front-end component like a promotional popup needs logic that explicitly checks the value from the options context, not the current post, as described in this discussion of options-page-controlled front-end behavior.

Turning a field into a trigger

Here's the business-friendly version of the setup.

A client wants a sitewide holiday offer. You create a true/false field named holiday_promo_enabled. When it's on, the popup displays. When it's off, nothing renders. No swapping layouts. No unpublishing modules. No editing every page that references the area.

For builds using dynamic Divi Areas Pro content workflows, this pattern is especially effective because the same centralized field structure can feed both the popup content and the display logic.

A popup should behave like a campaign asset, not like a page fragment someone has to hunt down later.

Where this pattern helps most

This approach is strong in a few recurring scenarios:

• Seasonal campaigns where copy and timing change often
• Announcement bars that should appear globally for a short period
• Lead magnets with one sitewide offer and one control switch
• WooCommerce notices where product-independent messaging needs fast updates

The trade-off is that your field planning has to be tidy. If popup content, banner content, and general marketing fields all live on one cluttered options page, editors get lost. Group related settings together, and separate campaigns from evergreen site settings.

Advanced Techniques and Best Practices

Once the first options page is working, most projects need more structure. The basics handle phone numbers and CTA text well, but larger Divi sites usually need grouped settings, repeatable items, and clearer editorial boundaries.

One image says a lot about the kind of work this supports. It's not flashy work. It's systems work.

Use repeaters for managed lists

If a client needs a list of social links, partner logos, office locations, or announcement items, a repeater field on the options page is a clean fit.

Basic example for social links:

<?php if (have_rows('social_links', 'option')) : ?>
    <ul class="social-links">
        <?php while (have_rows('social_links', 'option')) : the_row(); ?>
            <?php
            $label = get_sub_field('label');
            $url   = get_sub_field('url');
            ?>
            <?php if ($label && $url) : ?>
                <li><a href="<?php echo esc_url($url); ?>"><?php echo esc_html($label); ?></a></li>
            <?php endif; ?>
        <?php endwhile; ?>
    </ul>
<?php endif; ?>

This is much better than creating a fixed set of fields if the list length might change.

Split settings into subpages

When one options page starts holding everything, the editing experience degrades fast. That's when acf_add_options_sub_page() becomes worth using.

A sensible structure might look like this:

• General Settings for brand-wide values
• Header Settings for top bar and navigation-related content
• Footer Settings for legal text, contact details, and social links
• Campaign Settings for temporary promos, banners, and popup controls

That separation helps in Divi projects because different layouts often pull from different categories of global content. Editors also make fewer mistakes when they don't have to scroll through unrelated fields.

Be careful with multiple options pages

One under-documented issue appears when you have more than one options page and need values from a specific one. Most tutorials stop at the global 'option' pattern, but real projects often need more targeted retrieval. That challenge is noted in this article about retrieving values from specific ACF options pages.

In practice, this means you should be deliberate about how pages are registered and how you associate fields. If your setup grows beyond one general settings page, test retrieval carefully before wiring fields into Divi modules or popup conditions.

Keep your options architecture boring. Clear slugs, clear field names, clear page groupings. The more “clever” the setup gets, the harder it is to maintain.

A few deployment habits that save time

For multilingual or multisite projects, the details depend on the stack, but the discipline stays the same.

• Define ownership early so editors know which settings are sitewide and which are local to a page.
• Avoid duplicate fields that store the same meaning in different places.
• Document the field purpose inside ACF instructions so the admin remains self-explanatory.
• Treat options pages like configuration and include them in your deployment workflow, whether that's local JSON, version-controlled PHP registration, or a documented rebuild process.

On larger Divi builds, a well-organized ACF options page setup often matters more than the front-end implementation. The clean admin model is what keeps the site manageable six months later.

Troubleshooting Common Issues

Most ACF options page problems aren't deep WordPress problems. They're usually one of a handful of small misses. When a value doesn't show in Divi, don't start by blaming the builder. Start with the setup.

The options page doesn't appear

If the admin page never shows up, check the basics first:

• ACF Pro availability because Options Pages are a PRO feature
• Function loading so acf_add_options_page() only runs if the function exists
• Hook timing if you're registering through acf/init
• PHP errors in functions.php or the site plugin where the code lives
• Admin caching if the menu should exist but doesn't appear immediately

A missing page is usually registration-related, not field-related.

The field returns empty output

This is the most common issue by far. The field exists, the editor filled it in, and the front end still shows nothing.

Check these in order:

1. Did you use 'option' in the field call?
2. Does the field name in code exactly match the ACF field name?
3. Is the field group assigned to the correct options page?
4. Are you testing a field type that needs formatting or special handling?
5. Is your conditional logic hiding the output because the value is empty or false?

A quick example of the right retrieval pattern:

<?php
$value = get_field('header_phone', 'option');
if ($value) {
    echo esc_html($value);
}
?>

If you leave out 'option', WordPress looks in the current post context instead. On a Divi layout, that often means you get an empty result and assume the field is broken.

Divi output looks inconsistent

When values show in one place but not another, inspect the integration point.

A few likely causes:

• Different field contexts between PHP templates and Divi dynamic content
• Stale saved layouts where the module connection needs to be refreshed
• Plugin conflicts affecting field availability or rendering
• Conditional display rules that are more restrictive than expected

If you're deep into a strange rendering issue, it helps to work through a proper Divi troubleshooting checklist before rewriting your ACF setup.

Don't debug three systems at once. Confirm the field saves correctly in ACF, confirm it retrieves correctly in PHP, then confirm Divi or your popup logic is reading the same value.

A disciplined test order saves a lot of time. Verify storage. Verify retrieval. Verify display. Most issues become obvious once you separate those steps.

---

If you're building Divi sites that need cleaner global content management, conditional messaging, and popup workflows that don't depend on editing layouts every time, Divimode is a practical place to continue. Its tutorials, documentation, and Divi-focused tools are built around the kind of structured, maintainable setup that ACF Options Pages support well.