Statamic Global Sets: When global: Works and When It Doesn't

You've set up a global set in Statamic. Navigation settings, footer content, site-wide configuration—whatever it is, you've got your fields defined and populated in the Control Panel.

Now you're trying to access them in a template. You've seen examples using global: prefix, so you write:

{{ global:navigation:cta_enabled }}

Nothing renders. The conditional doesn't fire. The data isn't there.

Here's what's actually going on—and it's more nuanced than "global: doesn't work."

The Actual Rules

Statamic has a specific global set called "Globals" (handle: global) that ships by default. For this specific set, you can use either:

{{ site_name }}
{{ global:site_name }}

Both work because Statamic treats the default global set specially—its fields are available at the root scope AND scoped under global:.

But here's where people get tripped up. When you create additional global sets—like navigation, footer, or settings—they're accessed directly by their handle:

{{# Correct - access by handle #}}
{{ navigation:cta_enabled }}
{{ footer:company_name }}
{{ settings:maintenance_mode }}
{{# Wrong - global: only works for the default "global" set #}}
{{ global:navigation:cta_enabled }}

The global: prefix isn't a universal namespace for all global sets. It's specifically the scope for the default global set named "Globals."

Why This Trips People Up

If you've worked with other CMSs or you've seen Statamic examples showing {{ global:site_name }}, you might assume global: is a universal prefix for all global data. It's not.

The confusion comes from two things:

1. The default global set is literally named "Globals" with the handle global. So {{ global:field }} works for that specific set.

2. Documentation examples often use the default set, so you see global: in examples but don't realise it's just the handle of one specific global set.

When you create your own global sets with handles like navigation, footer, or settings, those become their own scopes. The handle is the prefix.

Real Examples

Here's how this looks in practice. Say you've got a navigation global set with CTA fields:

Global set file: content/globals/navigation.yaml

cta_enabled: true
cta_label: 'Book a Call'
cta_url: '/contact'

Blueprint: resources/blueprints/globals/navigation.yaml

fields:
  -
    handle: cta_enabled
    field:
      type: toggle
      display: 'CTA Enabled'
  -
    handle: cta_label
    field:
      type: text
      display: 'CTA Label'
  -
    handle: cta_url
    field:
      type: link
      display: 'CTA URL'

Template usage:

{{ if navigation:cta_enabled }}
    <a href="{{ navigation:cta_url }}" class="btn-primary">
        {{ navigation:cta_label }}
    </a>
{{ /if }}

Same pattern for a footer global:

<footer>
    <p>&copy; {{ now format="Y" }} {{ footer:company_name }}</p>
    <p>{{ footer:tagline }}</p>
</footer>

Debugging When It's Not Working

If your global set variable renders nothing:

1. Verify the global set exists

Check that you have both the content file and the blueprint:

• content/globals/{handle}.yaml
• resources/blueprints/globals/{handle}.yaml

2. Check your handle

The handle is whatever you named the global set, not what's in the title field. If you created a global set called "Site Settings" but the handle is site_settings, you access it with {{ site_settings:field_name }}.

3. Clear the Stache

php artisan statamic:stache:clear

Statamic's content cache can get stale, especially if you're editing YAML files directly.

4. Test in Tinker

GlobalSet::find('navigation')->in('default')->get('cta_enabled');

If this returns your value, the data is there and it's a template syntax issue. If it returns null, the global set isn't configured correctly.

A Note on Multi-Site

If you're running a multi-site setup, global sets can have different values per site. The in('default') in the Tinker example above specifies which site's data you're retrieving.

In templates, Statamic automatically uses the current site's global set values. You don't need to specify anything extra—it just works based on context.

The Pattern to Remember

The key insight: the handle of your global set is the prefix. There's no universal global: namespace that wraps everything.

This is one of those Statamic conventions that makes total sense once you understand the distinction between the default global set and custom ones. The documentation does explain this, but it's easy to miss the nuance when you're scanning quickly.

The mental model that helps: every global set is its own scope, named by its handle. The default "Globals" set happens to have the handle global, which is why {{ global:field }} works for it. Your custom sets work the same way—just with different handles.

Once that clicks, you'll never second-guess it again.