[3.5.0-beta.3] Propagation bug on multisite entries

[clowerweb]

Description

Entries don't always propagate to other sites when a draft is saved, especially if you look at the entry on another site before all required fields are set.

Steps to reproduce

1. Set up a multisite with 2 or more sites
2. Add a couple of required fields, and leave one of them blank
3. After it auto-saves the draft, switch to one of your other sites on the same entry
4. You will see that the content didn't propagate to the other sites (and now there's no way to get it to, because the entry itself already propagated, but with all empty content)
5. Now make another entry, but fill in all the required fields first before switching sites, and you'll notice the content propagated to the other sites like it should

Note that you don't need to click "Save", this is mostly specific to auto-saved drafts.

Additional info

• Craft version: 3.5.0-beta.3
• PHP version: 7.3.11
• Database driver & version: MySQL 5.5.5
• Plugins & versions:

[brandonkelly]

What are the fields’ Translation Methods set to?

[clowerweb]

Some of them are different (one is translate for each language, another is translate for each site, but I suppose they both do the same thing in this case since there's a site per language), but all of them propagate correctly if all of the required fields are filled before looking at the entry on any other site/language.

[sjcallender]

One of the fields is a required Assets field. If you don't upload an asset, then go to edit the content of another language in the draft, all the fields are empty.

[jsunsawyer]

I just ran into an issue that's possibly related to this.

I had a section called Events. In that section, I had an entry field called People. People were populating each event.

Later, I updated both my Events and People sections' propagation methods to only save to the site they were created in.

This kept my People field populated in each Events entry, but people was null when dumping an event. New entries added people correctly. I ended up having to delete and recreate my People field to repopulate the existing entries correctly.

This was on Craft 3.4.25

[jsunsawyer]

Update on this. Same multi-site setup. Tried switching an entries field handle that was used in a section for post content. Data was still populated in the back-end, but front-end showed field as null until I changed the handle back.

I tested changing an entries field on another non multi-site project and things worked as expected. Changed template to used updated field handle and content carried over.

[brandonkelly]

Some of them are different (one is translate for each language, another is translate for each site, but I suppose they both do the same thing in this case since there's a site per language), but all of them propagate correctly if all of the required fields are filled before looking at the entry on any other site/language.

@clowerweb If a field’s translation method is set to per-site (etc.), then the values aren’t supposed to propagate, so maybe it’s working as expected? The one exception to that is when you first create an entry – if you see that &fresh=1 in the URL, that tells Craft that it should be copying all field values over to all other sites regardless of propagation method, because it’s a brand new entry and you haven’t directly edited the other sites’ content yet.

One of the fields is a required Assets field. If you don't upload an asset, then go to edit the content of another language in the draft, all the fields are empty.

@sjcallender I’m not able to reproduce that, but maybe I’m missing something. Can you give me exact steps to reproduce? Also if you’re on the 3.5 beta, change your craftcms/cms requirement in composer.json to 3.5.x-dev, and then run composer update, and see if you can still reproduce, as there have been a few bug fixes since Beta 3 came out.

@jsunsawyer Both of your issues seem unrelated to me (to both this thread and possibly each other), but from a glance things are working as expected. When you change a section’s propagation method, Craft will go through and duplicate all of its existing entries into the new site(s), so you don’t lose their localized content. It won’t update existing relations though, which will all still be pointing to the original entries (which now only exist on the primary site). So existing relations weren’t showing up on your front-end because by default the entry query used to display them would only be configured to show related entries from the current site, whatever that is. (You can change that behavior by passing .siteId('*').unique().) Don’t know enough about your front-end to know what’s going on with your second issue but I suspect it’s something similar, where content isn’t showing up due to not existing on the current site.

[sjcallender]

@brandonkelly Related/unrelated....

I changed the Matrix field's Propagation Method to "Save blocks to all sites the owner element is saved in." from "Save blocks to other sites in the same site group." since that's what our client needs. I tested it generally (not the above issue) in the current build and it worked as expected.

Then, I went to replicate to report here.

But when I changed composer.json to load 3.5.x-dev and ran "Finish Up" all, every single block in the matrix field for every single entry had multiplied inside each language entry. So, instead of one of each unique, I now have multiples of each.

Let me know if you want me to move this to a new issue.

Syncing with the staging db didn't replicate the above noted error, so I'm all set.

In this state, I tested the original issue above in a new entry and it worked as expected. The other sites' entries had the content of the default site's entry even if that default site's entry had errors, both in Draft and Created states.

[brandonkelly]

Cool. @sjcallender & @clowerweb are you working on the same site? Is this issue OK to close?