Skip to content

[6.x] Multisite - entry grouping - #15241

Open
jaygeorge wants to merge 33 commits into
6.xfrom
multisite-entry-grouping
Open

[6.x] Multisite - entry grouping#15241
jaygeorge wants to merge 33 commits into
6.xfrom
multisite-entry-grouping

Conversation

@jaygeorge

Copy link
Copy Markdown
Contributor

Description of the Problem

For multisite installs, sites display as a flat list everywhere (site configuration, entries, site pickers, etc.).

Larger sites could have multiple locations and related locales (e.g. Paris > French, Paris > English, and then Montreal > French, Montreal > English).

In a flat list there’s no way to express that hierarchy, so related sites are hard to understand and manage.

What this PR Does

  • Adds ability to arrange sites into groups with a new sectioned grid interface, with default prefixes, e.g. an English site in the group "Paris" will have its handle automatically be prefixed like paris_english
2026-08-21 at 17 54 59@2x
  • Comboboxes for localization now have groups

  • Adjusts the way Origin works for grouping

    • After a group has several localizations, the code picks the first group entry as the new origin reference.
    • If you move the group origin outside the group, then the origin also moves out.
  • Fixes Multi-Site groups ideas#17

How to Reproduce

  1. Enable multisite and open Configure Sites (/cp/sites).
  2. Use Add Site Groups / Edit Site Groups, create groups (e.g. Tokyo, New York), and move sites into them.
  3. Save, then check:
  • Global header site selector
  • An entry’s "Working In" combobox
  • Create Localization → Origin select
  • Collection/Taxonomy/Nav configure → Sites field
  • Globals configure → Sites table + Origin selects
    Create a localization into a group that already has a site — Origin should default to that group’s origin (and still follow it if that origin later moves out of the group).

Delete-group meta
Removing a group now copies each row’s grid meta into Other (same path as drag) and drops the old drop zone.

Slug-key collisions
Named groups store a stable group_handle in sites.yaml. Reload uses that id instead of re-slugging the title, so “New York” / “new york”, “Café” / “Cafe”, and a group titled “Other” stay separate from the pinned Other section. New groups also refuse the reserved other key.

Empty-sites errors
If every site is removed, the required error is attached to the group grids that were actually submitted, not always group_other_sites.
…ew Group.

Saving the title still keeps the group. Leaving edit mode (Discard/Cancel) does not try to delete it again, since that path already restores or remounts the form.
Reuse the shared Combobox for type-to-filter, and disable virtualization
when options have variable-height group headers.
Update the trigger immediately on select and keep an Other prefix so the
chevron layout does not jump while the localization loads.
…how many items there is to choose from when scrollbars disappear like on macOS
When a second localization in a group is created, the origin switches to the first localization in the group. If the group has none yet, keep the current active/root behaviour.
Otherwise a remaining in-group localization gets the Origin badge and becomes the default, which is misleading.
…oned grids, not every Grid in the CP.

For grids in the cp, people may want to add a few rows at once so auto focusing on the row might be annoying
Clear a stale Working In selection when a switch is aborted, restore site
group sections on Discard Changes, and tighten related grouping edge cases
with tests.
if (!from) return from;

return data_get(this.publishContainer?.values, key);
const prefix = this.config.prefix_from
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Multi-Site groups

2 participants