FR: Consider globals/global sets refactor

[timkelty]

Wanted to get my 2 cents in here, hoping that this might get considered with some of the other big-picture refactoring efforts (#1524)

I find globals to be quite cumbersome, particularly the levels of forced taxonomy/hierarchy it imposes, just to expose simple data.

For example, out of the gate you're forced to make a global set, which means you will likely end up with some sort of meaningless catch-all like "General". Beyond that, you also need to create a tab grouping, which is probably going to be another meaningless label like "Content" or something.

I wouldn't be as opposed to this forced hierarchy if it were merely presentational, and you could change it and your content evolved. However, globals are called explicitly by their global set handle, so and reorganization is going to require a code refactoring.

As Craft 3 has embraced multi-site, one possible direction could be to treat Sites as elements, with the ability to add fields/field layouts, instead of "globals" being a totally separate concept (discussed here: #2790)

Related globals/global set issues:

• Feature Request: Allow me to sort the display order of Global sets #2682
• Add the ability to reorder Global sets #916
• FR: Custom Fields for Sites #2790

[khalwat]

Having sites be elements with their own field layouts sounds pretty awesome. I'm not sure what impact that has under the hood, though. Because elements inherently can be localized based on... sites.

So it might be a bit of a weird infinite loop unless sites were then special-cased in some manner. Which then defeats the purpose of them being elements.

[brandonkelly]

What if you still want to store actual global content that should be consistent across all sites?

[timkelty]

What if you still want to store actual global content that should be consistent across all sites?

I imagine you'd not mark the field as "translatable", same as would for an entry field (or even global set fields, as they exist now).

[brandonkelly]

Sorry I assumed you meant that each site should get its own field layouts as well (as globals do), but maybe that’s not the case.

Making sites elements, with a Site field layout, has been suggested before, but one issue with that is that sites are an admin-only thing. So we’d need to add some new, separate place to manage their field content. At which point, I’m not sure how it’s any different than the Globals other than the name.

[timkelty]

Sorry I assumed you meant that each site should get its own field layouts as well (as globals do), but maybe that’s not the case.

So unless I'm totally missing something – as it stands right now, Global Sets and layout definitions are app-wide. The content for those fields is either site-specific or not based solely on the "Translation Method" setting of the field.

That's what I was getting at with this comment.

[brandonkelly]

Sorry you’re right. The key difference would be that instead of globals, you’d get one element per site. But then we’re back to the issue I pointed out – there’d be no way to define actual global content, where a single value persists across all sites. Field translatable settings wouldn’t do anything, because each site would by definition only have content for its own site.

[timkelty]

Yep. I think you're right that treating them as elements is really just globals with a different name.

Initially I was thinking of Entries/elements because it already has the whole "filtering out non-applicable sections in element-index" thing…

Ultimately I think it comes down to the rigidity and forced hierarchy of global sets where I have my beef. Part of that is UI (there could easily be an option to not show the nav if there were only one global set), but also that you're required to call the global with that handle, so while they feel arbitrary and organizational, the effect code.

[timkelty]

Just brainstorming here:

What if global sets had a similar "site settings" table (like sections) defining which sites they applied to, so they could be filtered out (similar to how sections are w/ entries in the element index)?

[timkelty]

Basically trying to get away from this type of thing, but I feel with the current architecture it's somewhat inevitable:

[brandonkelly]

That could be an option.

[timkelty]

That could be an option.

👍 Giving globals "site-settings" seems like a consistent way to tackle the app-wide vs site-wide problem

It doesn't solve my original gripe, which is being forced into arbitrary global sets that result in messy CP UI as well as affecting code.

More spitballing: what if there was a default "app-wide" global set that was treated a bit differently, kind of like the "homepage" single: ( didn't have to give it a name/handle, could reference it consistently from code, maybe a tweaked UI if it were the only global set). If users wanted more global sets (e.g. to target specific sites with option mentioned above), they could create them as they do now.

[michaelrog]

The only reason the "Homepage" Entry makes sense is because entries usually need to map to paths. Globals don't, so adding that sort of one-off logic to the Globals setup seems like it could be needlessly limiting. (What if I want more than one app-wide global?) To me it sounds like giving Globals per-site settings like Entries is the more consistent and flexible way to go.

I actually like the UI of naming Globals and their field tabs, because I typically have more than one. That said, it might be a nice UI simplification to hide the tab UI in layouts with only one tab... but that's a separate issue.

[timkelty]

@michaelrog I agree the current global sets/globals taxonomy can be nice when it is fleshed out with a bunch of globals, so #2915 is a good start.

I'm still not a fan of the fact that we are required to create globals in sets, often before we know what kinds of other data might be in globals and how to categorize them. Furthermore our code has to reference them by set, so it is not easily re-organized without refactoring.

I see this as a pretty common scenario in my experience:

1. While building/modeling, dev realizes they need a single piece of global data
2. They are forced to create a set, even though they might not know what other kinds of data there might end up being, so this usually ends up being something arbitrary like "General"
3. As the content model evolves the dev is forced to either:

• Keep adding things to "General"
• Make more sets (possibly getting to the point of 1 field/1 tab per-set, at which point things are hard to find, as who knows if things are in "General" or somewhere actually descriptive

4. At this point the dev could abandon the "General" set, but since globals are always referenced by their sets, this requires code refactoring.

[timkelty]

The only reason the "Homepage" Entry makes sense is because entries usually need to map to paths.

Yeah that was a bad example. Maybe a better example is how only one site can be the "Default site".

Globals don't, so adding that sort of one-off logic to the Globals setup seems like it could be needlessly limiting. (What if I want more than one app-wide global?)

I was proposing that there was the option to create a default global set, so you could put as many app-wide globals in there as you like.

[michaelrog]

I'm still not a fan of the fact that we are required to create globals in sets, often before we know what kinds of other data might be in globals and how to categorize them.

Definitely understand where you're coming from on that, but I think that's part of the process... We either do more planning up-front, or we refactor as we go further into the fog-of-war on a project.

The alternative — Globals not being organized into sets — creates implementation headaches. (Do all those field handles just get shoved up into the global Twig context on every pageload? How do we enforce handle uniqueness between global fields and Global elements? To what object in the content schema are field values actually attached, and how is that made intuitively apparent and consistent through the accessor syntax? etc.)

I was proposing that there was the option to create a default global set, so you could put as many app-wide globals in there as you like.

For that case, I'd just establish a personal convention: My sites will a global set called default. (It doesn't matter what the label is; that can change as the content evolves. In my code, the handle for my catch-all Global will be default. It will be untranslated, and available across all sites.)

{{ default.headHtml }} seems pretty reasonable...?

But now that I'm thinking about all this... Maybe I could see a UI case for hiding the sidebar listing if there's only one Global Set element in the system. That keeps the underlying architecture consistent but solves the annoyance of having a meaningless just-because title taking up space in a sidebar. The question is whether that annoyance is universal enough to change functionality around. (It's never been particularly a bother to me or my clients, but I could see how it would be to some.)

[timkelty]

The alternative — Globals not being organized into sets — creates implementation headaches. (Do all those field handles just get shoved up into the global Twig context on every pageload?

I would advocate for dropping global injection of those all together and just accessing via craft.app.globals...

Maybe I could see a UI case for hiding the sidebar listing if there's only one Global element in the system.

When you say "global element" - you mean global set, yes?

Definitely understand where you're coming from on that, but I think that's part of the process... We either do more planning up-front, or we refactor as we go further into the fog-of-war on a project.

I totally get that - I think it bothers me because it seems like the one place in Craft where this is necessary (e.g. field groups and field layouts can all be re-named moved around without breaking anything code-level). Especially when in globals - as you already have the "organization-only" level of the Tabs. Seems like overkill to require a set AND a tab for any piece of data.

[michaelrog]

When you say "global element" - you mean global set, yes?

Yes, a GlobalSet element.

I would advocate for dropping global injection of those all together and just accessing via craft.app.globals...

That's an interesting idea. As much as I do find it convenient that Global Sets are automatically accessible in the global Twig context... I'm not sure I'd be opposed accessing them explicitly. Less overhead on each load, and it's easy enough to alias each global set into a handy template var if you need to.

But that doesn't solve your original issue... because we still have a namespace where we need to enforce handle uniqueness... so the idea of trying to shove both 'global' field values and Global Set elements into that namespace still presents the same implementation challenges.

I think it bothers me because it seems like the one place in Craft where this is necessary (e.g. field groups and field layouts can all be re-named moved around without breaking anything code-level).

Sure, but then again, it's possible to change the labels on Global Sets without changing the handles. If you can come up with a convention you're happy with the for the handle of your "default" Global Set, you can give it whatever client-facing name you want and change the name as frequently as your concept evolves.

[pixelmachine]

This issue is pretty old but I don't think anything has changed in this regard though I have no idea what's planned in the long term. So, perhaps there is a planned solution in the works now @timkelty @brandonkelly ?

As discussed above I try to keep Global sets relatively... global, but I find there are always exceptions in multisite setups where you end up needing to make multiple sets like "Navigation Site A" and "Navigation Site B" which feels messy. Or sometimes the structure is just too different to make a set reusable or a whole set is just not relevant to a site.

I think it would be amazing if Global Sets could just be enabled/disabled on a per site basis, just like sections are. E.g.:

I think this would cover most of the issues discussed above.

[brandonkelly]

@pixelmachine We are actually going to be deprecating globals along with categories and tags in Craft 4.4, in favor of entries. See #9781 (comment) for details on how the transition will work.

[pixelmachine]

Oh I didn't realise Globals were going that way too.

I don't think I'd ever considered using entries for that purpose but makes a lot of sense.