Craft 4 → 5 Migrated Event fields uneditable on multi-site

[andypullen]

We upgraded recently to Craft 5 and found that any fields with pre-existing content before the migration cannot be edited on events in calendars that are enabled only on secondary sites. When editing the fields, the notice at the bottom of the control panel shows that the event was updated, but its content never gets adjusted. I am able to edit content on an empty field, and then come back and edit just fine.

I'm not 100% I've got the exact issue pinned down, but I've tested the best I can. I hope the description helps enough to reproduce, if possible.

Steps to reproduce

1. Start on Craft CMS 4 (though I'm not sure if this is related to the migration)
2. Create multiple sites
3. Add a calendar that is only enabled on each site (we have 4 sites and one calendar enabled for each site, and each calendar contains the same fields).
4. Create some events on each calendar, populating fields with data
5. Upgrade to Craft CMS 5, and then run the php craft calendar/events/fix-titles migration step
6. Edit an event in one of the calendars on a site that is not the primary site, changing the contents of one of the populated fields — the field edits are not retained

Expected behavior
All fields should be editable in every scenario.

Craft & Plugin Info (please complete the following information):

• Craft Version: 5.4.9
• Calendar Version: 5.0.10
• Calendar Edition: Pro
• Fresh Install or Upgrade:

Additional context
Here are the scenarios I've found:

• Editing a pre-populated or empty field on an event on the primary site works as expected.
• Editing an empty field on an event on a non-primary site works as expected.
• Editing a pre-populated field on a non-primary site results in the changes not being retained.
• Adding content to an empty field on a non-primary site works as expected, and can be edited afterwards as expected.

[danbrellis]

I think I'm running into a similar issue, though not on multisite.

I have 3 calendars, all use the same field "background" in their field layout. When I change and save the value in an event belonging to two of those calendars the event saves fine, but in one of them it doesn't save. I also get a notice that the event saved, but the change is not there.

I noticed if I change the handle for the calendar with the issue, it does save and the changes stick.

I also noticed that in the db table element_sites in the content column for an event in that calendar there are 2 items for that field, one with the correct uid and one for a uid belonging to the other calendar's copy of that field.

Some config from the database:

The relevant items from the elements_sites table's content column for the entry. This entry belongs to Calendar A and such it should only have content for 65819b05-7e9f-4919-9a69-b5f53ac321b3 (associated with Calendar A), not the 7cc6cee... which belongs to Calendar B.

{
  "65819b05-7e9f-4919-9a69-b5f53ac321b3": "<p>An agenda (with webinar information) will be posted below when available</p>",
  "7cc6cee3-40f5-4d27-9ea7-8c13316a3db6": "<p>An agenda (with webinar information) will be posted below when available</p>"
}

# Relevant element from the Calendar A config
dateAdded: '2024-11-23T04:24:45+00:00'
elementCondition: null
fieldUid: 67d5853e-9524-4f93-9d85-5a384d089370 # Background
handle: null
includeInCards: false
instructions: ''
label: Purpose
providesThumbs: false
required: false
tip: null
type: craft\fieldlayoutelements\CustomField
uid: 65819b05-7e9f-4919-9a69-b5f53ac321b3
userCondition: null
warning: null
width: 100

# Relevant element from the Calendar B config
dateAdded: '2024-11-23T04:24:47+00:00'
elementCondition: null
fieldUid: 67d5853e-9524-4f93-9d85-5a384d089370 # Background
handle: null
includeInCards: false
instructions: ''
label: Purpose
providesThumbs: false
required: false
tip: null
type: craft\fieldlayoutelements\CustomField
uid: 7cc6cee3-40f5-4d27-9ea7-8c13316a3db6
userCondition: null
warning: null
width: 100

[kjmartens]

Sorry for the delay and the trouble you're experiencing, @andypullen and @danbrellis.

A developer will be checking into this shortly. 🙂