Multi-Site Section or Section duplication

[miriamborgers]

We’re working on a fairly complex CraftCMS installation for a content-heavy website. It has 5 distinct main navigation points, each represented by a section with everything from 1 to 16 different entry types, and sometimes 5 levels of nesting.

Multi-Site

Until today, it was a single-site setup. Now our client needs to have a new “version” of the site for 2022. Some of the content from the last year will change, entries might not be needed anymore, some might be added, but most of it will stay the same.

Multi-language

At the same time, they need to publish the whole thing in multiple languages (currently German, plus English in the future). Here, only a small fraction of the website can be translated, so that only 2-3 of the 5 sections might actually have content, and even that might be stripped down a lot (removing entries).

Partial Content changes

For the new 2022 site, new types of content (entry types, blocks and fields in the Neo content builder) will most probably need to be implemented.

Given that “only some“ but “defintely some“ of the content will change, I’ve identified two methods, which I would love to get feedback on:

Method 1: Use the same sections, make their entries multi-site, keep Neo content-builder in sync

Entries could be re-used, and using the “let each entry decide…“ propagation method, we could even „duplicate“ the entries to new sites selectively. I think we’ll have to do that manually though, which means doing it for 600 entries… 😬

On the other hand, changes to the Neo content builder, which holds 90% of the entry content, would be done for both sites and would have to be supported by both sites’ templates (we partially override the default templates by site). I’m not sure how problematic that could get. Also, new entry types would always be added to both sites, which might be a problem, but probably something we can mitigate via editorial instructions.

Method 2: Duplicate sections, only activate for selected sites, unsync content in Neo content-builder

This would mean that we get 2 sites for 2021 and 2022, and then 4 sites when we add English support. So: 20 sections overall, with 100+ entry types, most of them duplicates…

While this means we can change the structure of these sections and entry types per-site, the amount of duplication gives me a headache and also, I haven’t found a way (via plugins at least) to copy the section with content to their new counterparts as a starting point for the editorial team to work off… Can someone point me in a direction here?

Also, I haven’t found out how to set up this whole thing for muliple languages.

Sooo… is there anything I missed, maybe? Anyone with a similarly large site who had the same decision to make? I’m wavering between duplicating most of the sections and entry types to have total freedom without touching legacy content, but would need a way to copy over the content from the old site to the new one. I’m also unsure if the more elegant way (Method 1) would pose more challenges than helping me in the long run.

[brandonkelly]

If the new version of the site is going to be replacing the current version, and they are not meant to live alongside each other in the long run, then option 1 makes the most sense to me.

I think we’ll have to do that manually though, which means doing it for 600 entries… 😬

Is there anything in the entries that could be used to identify which entries need to be added to the English site? If so you could write a script to automate it:

use craft\elements\Entry;

$deSite = Craft::$app->sites->getSiteByHandle('deSiteHandle');
$enSite = Craft::$app->sites->getSiteByHandle('enSiteHandle');

$entries = Entry::find()
    // params...
    ->siteId($deSite->id)
    ->all();

foreach ($entries as $entry) {
    $isEnabled = $entry->getEnabledForSite();
    $entry->setEnabledForSite([
        $deSite->id => $isEnabled,
        $enSite->id => $isEnabled, // or `false` if you want them all initially disabled for EN
    ]);
    Craft::$app->elements->saveElement($entry);
}

[miriamborgers]

Thank you Brandon for the quick and detailed response!

The new site version will not replace the old one, though. The client bulk-publishes content annually. The content is „basically“ the same structurally year after year, but differs in size and might be modified in small parts. That’s why we’re looking to copy over the old website completely, as a starting point for the client to make the changes for the new year. This process will then be repeated each year.

We will need to add new functionality (mostly new types of Neo blocks, but possibly changed/new/deleted entry types) in the process, which will only be needed from that point onward. So if the 2022 site is launching, new blocks will be available for 2022, 2023…

After some discussion, we’re now leaning towards Method 2. The duplication of entry types gives us a headache, but the flexibility it gives us might help us prevent conflicts (for example, the need to delete an entry type in the 2022 site that the 2021 site needs to work properly).

Is it possible to copy complete sections with their content to a new section? That way, we could copy “section A” (activated for Site 2021) as “section A 2022” (activated for Site 2022), and still give editors all the entries from the original section that they can then modify to their needs.

[brandonkelly]

Is it possible to copy complete sections with their content to a new section?

Easiest way to do that would be with Feed Me.

[jannisborgers]

@brandonkelly 90% of the site’s content is in Neo blocks, which Feed Me doesn’t support.

We’ve decided that duplicating the whole installation and maintaining it as a separate repository/installation/license will be the way forward.

Apart from the clean isolation this approach gives us, we’re worried that performance might decrease over time with the duplication of content in the same database year over year. I guess this is a special case due to the way this website is operated and the way its content will change annually. The backwards-compatibility of features we would need to maintain was another reason.

Essentially: As long as the old content can be used as a starting point, no synchronisation between the old site and the new one is needed.