Entries don't save in Matrix, if Sites used and Entry not Siteable

[narration-sd]

Description

I may have a good one for you, possibly related to recent Matrix fixes

Steps to reproduce

1. Have a site with Sites -- in this case just two, set up modern no directories fashion (doesn't matter)
2. Have a Channel A with both sites enabled, and a Matrix with an Entries field; also a plain Entries field
3. Have another Channel B, with only the primary site enabled, and an entry; minimal content fine
4. Have a third Channel C, with both sites enabled, and an entry; minimal content fine
5. Edit a new entry on A.
6. Select a B and C entry for the Matrix on A.
7. Select a B and C entry for the plain Entries on A
8. Save. Expect all four Entries in A to be present
9. What you will get is both B and C in the plain Entries, but only C in the Matrix Entries.
10. Extra credit: if you enable the second Site on B, try again, then both B and C entries will save on the Matrix of A.

Some fun figuring out what was really happening here, seeing it show up on Vue. Hope it's not as much to work out the cause...

Additional info

PHP version 7.1.11
Database driver & version MySQL 5.7.20
Image driver & version GD 7.1.11
Craft edition & version Craft Pro 3.0.0.2 + dev-develop
Yii version 2.0.15.1
Twig version 2.4.8
Guzzle version 6.3.2
Imagine version 0.7-dev
Plugins
CraftQL 1.0.0
Element API 2.5.2
Live Vue 0.8.8
Recipe 1.0.7
Redactor 1.1.0
Super Table 2.0.4

[brandonkelly]

All fixed for the next release – thanks!

[narration-sd]

Most welcome, and had just tested this. Interesting results. Using dev-develop @c978f10595, which includes your fix commit here.

• seems to work fine now for ordinary Matrix field having Entries -- great
• but does not yet work on a Matrix having Entries but within a SuperTable: non-Site-enabled Entries still don't actually save when added. More precisely, Entries that have only the default site enabled are the ones that don't save.

I can think of ways this might occur/not, so imagine @engram-design / @verbb needs to get informed. Maybe mention of them here will do it; let's see.

You might be interested that this comes up in assuring a certain plugin's depth-for-future , or maybe just support survival -- at the moment working out last implications of its configuration language :)

[brandonkelly]

Yep good call. @engram-design this was an easy fix for Matrix, and I assume for Super Table too: ffc9264 (basically just need to pass the word that the owner element is propagating off to the nested Matrix blocks/Table rows).

[engram-design]

@brandonkelly Great, thanks for the heads-up!