Add support for registering globals with both Eloquent and Stache drivers

[Copilot]

Add support for registering globals with Eloquent and Stache Drivers ✅

Summary

This PR adds full support for registering global sets when using Statamic's Eloquent Driver AND fixes the default Stache driver implementation. Builder-registered global sets now properly show up in the Statamic control panel in both scenarios.

Implementation Details

Files Changed:

1. src/Repositories/EloquentGlobalRepository.php (new)

   • Created new repository extending Statamic\Eloquent\Globals\GlobalRepository
   • Initializes builder-registered globals from config('statamic.builder.globals')
   • Properly merges builder globals with database globals (builder globals take precedence)
   • Builder globals are keyed by handle and returned in the correct GlobalCollection format

2. src/ServiceProvider.php (modified)

   • Updated global repository binding to check for Eloquent Driver configuration
   • Conditionally returns EloquentGlobalRepository when statamic.eloquent-driver.globals.driver === 'eloquent'
   • Falls back to standard GlobalRepository for Stache-based storage (default)
   • Follows the same pattern as NavigationRepository

3. src/Stache/Stores/GlobalsStore.php (modified)

   • Fixed: Removed incorrect $key parameter from constructor call
   • Fixed: Corrected type hint from BaseTaxonomy to BaseGlobalSet
   • Fixed: Removed unused BaseTaxonomy import
   • Improved error message to say "Global Set" instead of "Collection"

4. tests/Helpers/TestGlobalSet.php (new)

   • Test helper class for testing global registration

5. tests/Unit/GlobalRepositoryTest.php (modified)

   • Added tests for finding and listing builder-registered globals

How It Works

For Both Stache and Eloquent Drivers:

1. Builder-registered global sets are loaded from config('statamic.builder.globals') on repository initialization
2. The find() and findByHandle() methods check builder globals first, then database/files
3. Builder global sets are properly keyed by their handle for correct display

Stache Driver (default - file-based):

• GlobalRepository uses GlobalsStore to create GlobalSets via the register() method
• GlobalSets are cached in the Stache for performance
• Works seamlessly with file-based global storage

Eloquent Driver (database-based):

• EloquentGlobalRepository merges database globals with builder globals
• Builder globals take precedence when the same handle exists in both sources
• Works seamlessly with database global storage

Usage

// config/statamic/builder.php
'globals' => [
    \App\Globals\SiteSettings::class,
],

Builder-registered global sets will now appear in:

• GlobalSet::all() - Lists all global sets
• GlobalSet::findByHandle('site_settings') - Finds specific global set
• Statamic Control Panel - Displays in the globals listing

What's a Global Set?

In Statamic, a Global Set is a container that holds global variables. For example:

• A "footer" global set might contain variables like copyright text, social media links, etc.
• A "site_settings" global set might contain variables like site name, logo, contact info, etc.

This PR enables you to register these global set containers via code, similar to how you register collections and taxonomies.

Plan Completed:

• Investigate and understand the requirements
• Review current implementation and Eloquent Driver behavior
• Create EloquentGlobalRepository class for Eloquent Driver
• Update ServiceProvider with conditional binding
• Add comprehensive tests
• Fix merge logic for proper handle-based keying
• Address all code review feedback
• Improve code comments for clarity
• Fix Stache driver implementation (GlobalsStore)
• Remove unused imports
• Run security checks (no issues found)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Add support for registering globals</issue_title>
<issue_description>I would love to register a global not only a global blueprint variable using the Statamic builder. This is partly built, but when you use the Eloquent Driver, the currently registered globals are not found, although they should be added.

• Read the statamic docs and implementation
• Review the current code
• Review the Eloquent Driver code</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Add support for registering globals #72

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[tdwesten]

@copilot I now see the challange is bigger, we need a way to register globals from the statamic builder, but statamic uses globals and globals sets. Deep think how we can do this. Now the registered globals (in the current state of the code/repo) do not show up. review the statamic code for globals and there implementation.

Succes is when we can register the globals from code, like we do with the blueprints.

[Copilot]

@copilot I now see the challange is bigger, we need a way to register globals from the statamic builder, but statamic uses globals and globals sets. Deep think how we can do this. Now the registered g...

I understand the issue now. The challenge is that GlobalCollection expects GlobalSets to be properly keyed by their handle. The current implementation creates the GlobalSets but the merging logic might not preserve the keys correctly.

I'll fix the EloquentGlobalRepository::all() method to ensure builder-registered globals are properly keyed and show up in the control panel. The issue is in how we're merging the collections - we need to use keyBy() to ensure proper handle-based keying.

Working on the fix now.

[tdwesten]

@copilot Oke so we need also a way to register and global sets i think

[Copilot]

@copilot Oke so we need also a way to register and global sets i think

You're correct - we're already registering global sets (the containers). The current implementation:

1. Config: 'globals' => [App\Globals\Footer::class] registers a GlobalSet class
2. BaseGlobalSet: Creates the GlobalSet container with handle, title, and sites
3. Repositories: Make these GlobalSets available via all(), find(), and findByHandle()

The implementation already supports registering global sets (not individual variables within them). When you create a class extending BaseGlobalSet, you're defining the container structure. The actual global variables would be added through blueprints or by extending the register() method to add data.

Working on fixing both Stache and Eloquent implementations to ensure they work consistently.

[tdwesten]

@copilot Oke lets rethink the structure of globals as implement in the statamic builder.

Here some info about the sets:

Statamic Globals: GlobalSets and Globals — Relations Only

• A GlobalSet is the definition/container.

  • Identified by handle (e.g., site, seo).
  • Has a blueprint that defines fields.
  • One GlobalSet exists per handle across the project.

• Globals are the per-site values of a GlobalSet.

  • Stored in content/globals/{handle}.yaml (default) and content/globals/{handle}.{site}.yaml (overrides).
  • Keys under data correspond 1:1 to blueprint field handles.

• Relation cardinality

  • One GlobalSet → One Globals record per site (at most).
  • In single-site: One GlobalSet → One Globals file.
  • In multisite: One GlobalSet → Many site-specific Globals files, each overriding the base.

• Resolution order

  1. Site-specific Globals (content/globals/{handle}.{site}.yaml)
  2. Base Globals (content/globals/{handle}.yaml)

• Access binding

  • Blueprint fields (GlobalSet) map directly to Globals data keys by handle.
  • Missing site-specific keys fall back to base; missing in both resolve to null.

[Copilot]

@copilot Oke lets rethink the structure of globals as implement in the statamic builder.

Here some info about the sets:...

You're absolutely right about the distinction. The current implementation correctly registers GlobalSets (the containers/definitions) but not the Globals (the per-site data).

Here's what we have now:

• BaseGlobalSet creates the GlobalSet container with handle, title, and empty localizations
• This allows the GlobalSet to appear in the CP and be editable
• The actual data (Globals) would be entered through the CP or stored in YAML files

This matches how Collections work in the builder - we register the collection structure, but entries are added separately. The GlobalSet defines the container; blueprints define the fields; and the actual global data is managed through the CP or YAML files.

Is this the intended design, or do you want to extend BaseGlobalSet to also allow defining default data values programmatically? If so, we could add a data() method to populate initial values.

[tdwesten]

@copilot Oke, now create a way to test this working with a statamic laravel app with statamic builder addon installed