It seems like you are using Laravel’s multisite trait to sync data between two sites, and you have set the $propagatableSync property to true and $propagatable array to ['name'] to only sync the name column between the sites.
However, you have noticed that the description column is also getting copied to the other site, which is not what you were expecting.
One possible explanation for this behavior is that the description column is being automatically filled with a default value when a new record is created, and this default value is being copied over to the other site along with the name column.
To confirm this, you can try creating a new record with an empty description column and see if only the name column gets synced between the sites.
Another possibility is that there is some other code or configuration in your application that is causing the description column to be synced even though it is not in the $propagatable array.
To troubleshoot this issue further, you can try debugging your code and checking if the description column is being modified or accessed anywhere else in your application, and if there are any other settings or configurations that may be affecting the syncing behavior.
I hope this helps you in resolving the issue you are facing with the multisite trait in your custom model.
I have some concerns regarding “everything will be propagated”:
In the meanrime I added a belongsTo (brand) relationship to my (bicycle) model. And the brand model has multisite and $propagatableSync = true too.
When I now create a bicycle, all attributes get propagated as you said. Including brand_id. So in the database this results in propagated bicycle records with brand_id from a different site_id (the site_id on which I created the original record).
Therefore I think it isn’t optimal, that everything gets propagated upon creation, as I now have relations between records in the database which don’t make sense (and which don’t show up in the backend because of different site_id).
What would be optimal here in my opinion, would be that if the foreign key of another multisite model gets propagated, the related record for the current site would be identified via site_root_id/site_id and the found record id would be saved in the propagated record for the site - and if no corresponding record is found the foreign key column gets left empty.
But also with a field like description, I’d prefer to have control whether it gets propagated upon creation or not. Because multisite i guess often is used for record localisation/translation - and its much clearer to see /select which translations are still missing when a field is empty instead of holding a copy of some other locale. Especially when dealing with locales like en-US vs en-GB or fr-CA vs fr-FR.
I mean, the original translate plugin also didn’t initially copy the default language to all translations.
what do you and others think?
(to be honest, I see that this propagation topic can get very complicated - ie when validation comes into play and also for other relation types then just belongsTo)
To clarify one thing here, relations don’t propagate like attributes, instead they are shared, and are therefore always in sync.
I know what you mean, this is indeed a possible pain point. The Translate plugin currently checks if the values are equal to know if they should be updated across all locales. We could possibly do the same thing with Multisite. This would be classing an attribute as “untouched” or “untranslated”.