Setting the propagation method for Singles

[low]

Circling back to this FR, it would be great to have the option to set the propagation method for a Single section.

In the use case where I'm needing this, consider a Header or Footer single, with a Matrix (or Table or even Neo) Field where the user can fill out several links for navigation.

For this installation, there's a site group for the main site that exists for multiple locales. Each locale has the same (translated) links in the header and footer. However, there are other sites in their own groups that share the layout and fields, but not the same content; these sites need different links in the header and footer. This is currently not possible, as the propagationMethod for the Single section is hard-coded to all.

Now, I've been cheeky and changed the propagationMethod property to siteGroup in the project config files, synced them up, and then it seems to "just work". However, saving any changes to those Single section would reset it to All...

So, could we either have the same drop-down options for Singles sections to set the propagationMethod, or alternatively, can we use the before-save hook to change the value and not have it be overwritten by the code linked above?

Thanks for considering!

[brandonkelly]

Why not just create multiple Single sections though – one for each site group, say, only enabled for the sites within those groups?

I realize there’s a bit of extra overhead with that approach given that you will need to recreate the field layout for each section, however that won’t be a problem in Craft 5, where entry types will be decoupled from sections (#8716).

[davidwebca]

I'm just stumbling into this working on an up-to-date Craft 5 as I am getting ready to release a website in multiple locales and my only single section, at this point, is the home page, but as a matter of fact, it's the main page where there are lots of different content per language. Since I'm working on Craft 5 and seeing this in the future, I was searching for a way to make this work to no avail. 🤔 Most probably because single + home is a combo that stumbles into this exception? Decoupled entry types don't change anything as far as I understand in my case, right?

[davidwebca]

Just to make sure I am well understood: my problem only lies in the fact that I'll have to re-copy the content in all of the home pages of the same language instead of it having it be replicated (per language or site group, etc.) automatically like the propagation methods allow in structures and channels.

[brandonkelly]

If you have sites where it will be helpful for content to be propagated across them, then those sites should share the same Single section. You can hide certain tabs/fields for specific sites using conditions, if needed.

[davidwebca]

Yes, these sites share the same Single section, but propagation methods don't "work" like structures or channels. Since it's forced to "all", the main language is copied in all the other sites right away and there's no way to copy the sites content anymore after that.

I'm using a single called "home". It has content I need in all locales and languages, with some exceptions and changes in all of them. The fields are all correctly set up to be able to translate independently across sites.

Main site : Canadian English
Secondary site 1 : Canadian French
Secondary site 2 : United States English
Secondary site 3 : United Kingdom English
Secondary site 4 : France French
Secondary site 5 : Guinea French
Secondary site 6 : Germany German

My workflow, for the single (home page) now, involves :

1. Saving content in English propagates the english content to all sites
2. I now fill in the translations and make the differences in contents available in Canadian French
3. Now, since there's no "delete for this site" in singles (or replication methods like the other section types), I can't pass the Canadian French automatically to the other 2 sites that speak french to save myself time. In the current state, I have to re-copy everything manually, unless I use low's tiny hack by changing the propagation manually in the project's YAML files. And it works just great btw, so I don't understand or know what would be the issue if singles would be treated like the other section types.

It is to note that I don't want to use the exact same content in all the locales, but most of it, yes. Titles, texts and some images are to be the same in all the locales that share the same language, but some changes have to be made / some more blocks added or removed depending on the locale. Having the propagation methods work normally, or at least being able to "delete for this site" and then being able to re-save to manually propagate by saving in the proper language and checking the websites needed in the right sidebar would be a good start in itself.

Singles are meant to be un-repeatable or pages that are designed to be unique / one-offs if I understand right, but it doesn't mean that it is required nor need to be the same in all locales on a multi-lingual site. Home pages yes, arguably, but not every singles (like a "Support" page where the content needs to be different or even absent in some locales because the type of support for the end customer is different depending on the world's region).

Anyway this is a long-winded explanation, but if you'd prefer setting up a Zoom / Google Meet call so I could run this use case by you and make myself clearer, don't hesitate to reach out!

[brandonkelly]

Sounds like #14056 will solve this for you. We’re working to get that wrapped up for Craft 5.5.

[davidwebca]

OMFG. We're like in the midst of releasing a website with 3 languages across 6 locales and I wish I had seen this earlier, I'd have pulled it even if its not released yet, just to speed up our process. 😂 Still excited about it though and you're right, it would definitely help the process! But singles should definitely be able to propagate imho.

[MoritzLost]

+1 for this feature request, I've also run into this a couple of times.

Another use-case to consider @brandonkelly, is multi-sites where the structure is shared, but basically no content is shared. We have a couple projects like this, one with 10 sites in total. All channels and structures have propagation turned off (only save entries in the site they were created in). But with singles, that's not possible. This leaves two options:

• Create each single separately for each site. In the project with 10 sites, if we have five singles (home, blog index, projects index, etc), we need to create 50 singles in total. Every new single needs to be created 10 times. This is very unwieldy and unintuitive.
• Set a translation method (translate for every site or site group) for every single field, and be very careful to always do this when adding new fields. Also, make sure not to use any plugin or custom fields that don't support translation methods. This becomes especially difficult if you want to share some content between some sites, but not all. We have one project where a bunch of fields are set to a custom translation key format ({{ section.type == 'single' ? site.handle }}) to allow sharing fields between sites in channels/structures, but not in singles. Great that this is possible at all, but still difficult to maintain.

Both of those options feel like workarounds for the lack of propagation methods for singles. In the case above, we could set the single section to only save entries in the site they were created in. Then a separate entry could be created for every site (either manually or automatically when the single is created), so we would end up with 10 separate entries instead of one entry that's propagated to 10 sites.

Full support for propagation methods would be cool as well. So we could set a single, for example, to only propagate within its site group. So in a site with three site groups and three sites in each group, we would end up with three separate entries, each of which is propagated to three sites.

We have at least three projects where we've run into this problem, so at least for us, it's not super uncommon.

[davidwebca]

Yeah that explains in way better terms our usage as well. Thanks for sharing this POV.

[brandonkelly]

In the case above, we could set the single section to only save entries in the site they were created in. Then a separate entry could be created for every site (either manually or automatically when the single is created), so we would end up with 10 separate entries instead of one entry that's propagated to 10 sites.

That’s not how propagation works though. When an entry is propagated across two or more sites, they are all the same entry, with content stored across multiple sites. So it seems like what you are asking for is not just more control over the propagation method for single section entries, but also the ability for Single sections to have 0 or 1 entries within them, depending on the site (and control over which sites those entries propagate to from there).

[davidwebca]

Yeah. I don't want to reply for Moritz so I'll let him respond for himself, but on my end, I know that the technicalities behind the system is : 1 entry, each site has fields saved in "elements_sites" alongside a siteId field. To the user/human eye, it looks like the entries are different so that might be why we're using this language interchangeably here.

In other words, what's missing in my case is the ability to have the propagation method changed from "all" to any of the other options that are available in the structures and channels - which seems to work already because changing the YML configs manually allow us to do so, so the only thing missing would be the dropdown to change the config in the section admin UI.

That combined with #14056 will offer 100% flexibility for us that need it, all you need to do is choose what you think is a proper default to avoid disrupting existing websites (in this case, probably leaving the option set as "all at first.")

[MoritzLost]

So it seems like what you are asking for is not just more control over the propagation method for single section entries, but also the ability for Single sections to have 0 or 1 entries within them, depending on the site (and control over which sites those entries propagate to from there).

@brandonkelly That would be one option, but not necessary IMO. There would still be one entry for every site. The only thing that would change is that Craft would create one separate entry for every site the section is active in, instead of one entry that's propagated to all sites.

Let's say I create a single that's active in three sites and set propagation to Only save entries in the site they were created in. Instead of creating one entry and propagating it, Craft would iterate through the three sites and create a separate entry for each. So there's still exactly one entry per single per site, only they are not connected.

This could even work with partial propagation, e.g. propagation within the site group. Let's say I have two site groups with two sites each. Craft could start with the primary site, create the single entry for that site, and let it propagate based on the propagation setting. Then iterate through all other sites, skipping over sites that a previous entry was already propagated to. When it reaches the second group (where the entry does not yet exist), it creates a new entry and again lets it propagate. So we end up with two entries for the two site groups, each propagated within the group.

This is very close to the current behavior, all that's added is the iteration through all sites to ensure the single exists in all sites. If that presents challenges I'm not aware of, having an option to toggle between the current behavior (one entry, propagated to all active sites) and the 'no propagation' behavior (where a separate entry is created for each site the single is active in) would already be a huge improvement!