You can use the
php please multisite to automate converting from a single to a multisite installation.
When using multiple sites, you'll need to specify in the collection's YAML file which sites this collection can be used in.
# content/collections/blog.yamlsites:- en- fr
The folder structure will differ from the single site structure explained in the entries guide. Now, entries should be organized into the respective sites.
An entry will only be available in that site if the entry has explicitly been localized. For example, in the blog above,
my-first-day would appear in both English and French sites, where
bastille-day would only appear in the French site.
If you'd like the entry to be localized into all the sites automatically, you may enable entry propagation (similar to how it worked in Statamic v2).
In a Blueprint, you can define which fields are localizable.
While editing a localized entry, only the localizable fields will be editable. The non-localizable fields will be read-only.
To mark a field as localizable, head to your Blueprint and toggle on the globe icon on the field itself. That's all there is to it.
A localized entry should define where it originated, and will inherit any undefined values from its origin.
For example, you can create an entry in the English site, then choose to localize it into the French site, and vice versa.
# en/2015-01-18.my-first-day.mdid: 123title: My First Dayimage: forest.jpg
# fr/2015-01-18.my-first-day.mdorigin: 123id: 456title: Mon Premier Jour
Here you can see that since the French version does not have
image defined, it will inherit it from the English version.
Notice that the French version has a different ID from the English version. In Statamic v3, every entry has its own ID, which is different from the Statamic v2 behavior.
As explained above, when you localize an entry, an
origin is added to the localization. If you were to delete the original entry, the localization would then
be referencing an entry that no longer exists. This could cause some confusion to Statamic!
If you want to delete an origin, you need to make a decision on how to handle any of its localizations. When deleting entries through the Control Panel, you will be presented with two options:
Option 1: Delete
If you no longer need the localized version, then you can choose to just delete them.
An example of this may be when you have an entry and then you've simply translated it. It probably doesn't make sense to keep a translated version if the original no longer exists.
When dealing with files, simply make sure that you've also deleted the localization.
Option 2: Detach
Detaching essentially turns the localizations into their own standalone entries.
An example of this may be when you have a product being sold in multiple locations. You may have created the product
in one location, and localized the price in other locations. Then, you discontinue the product in the original location.
You probably still want the product to exist in the other location.
What will happen with this option is that any data that you haven't overridden on the localization will be copied to it.
origin will also be removed.
When dealing with files, make sure that you remove the origin, and copy any leftover data across manually.
By default, when you create an entry, it will only exist in the collection you've selected.
You may choose to automatically create localizations in the rest of the configured sites whenever you create the first entry.
# content/collections/blog.yamlpropagate: true