Cms: FR: Custom Fields for Sites

[richhayler]

Description

It would be great it you could add custom fields for sites in a multisite setup.

If you have the option to use the layout designer within the CP --> Settings --> Sites to configure custom fields that could be set per site and then render the data in a front-end template, e.g. site.description, site.primaryColour, site.twitter or currentSite.description, currentSite.primaryColour, currentSite.twitter etc.

Appreciate that "Globals" provides for this functionality but it makes more sense to me that site-specific fields might be better served being accessed from within the "sites" section? Also i'm not sure if you can access values of global fields (setup for each site) in a frontend template by looping through sites? craft.app.sites.getAllSites()?

[brandonkelly]

Everything in Settings is restricted to admins only, for good reason, as anything you change in there could have significant consequences to the Craft install. It would be a little unnerving to manage content values right alongside those system settings.

A Global Set with translatable fields seems like the right way to go for this.

[richhayler]

Makes sense. Thanks for considering this and explaining your rationale. I’ll post in Slack regarding how to access global sets for each site in a loop. I'm trying to create a site switcher with additional details about each site, e.g site logo, description, brand name etc.

[brandonkelly]

Actually, just realized it wasn’t really possible to query global sets in other sites. So I just added a craft.globalSets() method, similar to craft.entries(), for today’s 3.0.4 release. When that’s out you’ll be able to do this:

{% for site in currentSite.group.sites %}
    {% set global = craft.globalSets.handle('<globalSetHandle>').siteId(site.id).one() %}
    <p>{{ global.<customFieldHandle> }}</p>
{% endfor %}

[richhayler]

Awesome! Thanks @brandonkelly!

[timkelty]

A Global Set with translatable fields seems like the right way to go for this.

A drawback to this approach is that while any fields in a global set can be translatable, the fields and sets themselves are always going to show up, which can result in global fields/sets that don't necessarily apply to a particular site.

E.g. I have a "Brands" site group with several similar-structured sites, but then another site that is a total one-off. If I add a "Brand logo" global field/set, it still shows up in the one-off site, even though it doesn't apply.

My current solution is to _also_ have "Brands" section, with entries matching the sites in my "Brands" site-group. Not great, but I like it better than the globals solution. I may pair that up with a field plugin that allows site selection, so I can then associate my "Brand" entry with a "Brand" site.

Any input appreciated! @richhayler @brandonkelly