Bugfix/upgrade to v5 and migrations that change sections

[i-just]

Description

Issue 1:
If you have a Single section with a Commerce Products or Commerce Variants relation field in its field layout, and you upgrade from v4 to v5.7+, you get the following error:

*** applying m250315_131608_unlimited_authors
> alter column maxAuthors in table {{%sections}} to smallint UNSIGNED ... done (time: 0.136s)
Exception: SQLSTATE[42S22]: Column not found: 1054 Unknown column '<XYZ>' in 'on clause'

That’s because when the project config for a section changes, it triggers the Entries::_ensureSingleEntry() method, which attempts to save the element. In doing so, it triggers a query that gets the contents of the relation field to check whether it’s empty. However, by that time, the Commerce tables are still “old” (not upgraded to v5), causing the query to fail.

Fix:
Mute the events before setting the maxAuthors for the section’s project config to 1. (The database value is already 1, as that was the default set during the m221107_112121_add_max_authors_to_sections migration.)

Issue 2:
If you have a Solo edition with a Single section with a Commerce Products or Commerce Variants relation field in its field layout, and you upgrade from v4 to v5, you get the following error:

*** applying m240302_212719_solo_preview_targets
Exception: SQLSTATE[23000]: Integrity constraint violation: 1052 Column 'price' in field list is ambiguous

It’s the same cause as the previous issue - a single section is saved, triggering _ensureSingleEntry and a new Commerce Products query on the old Commerce tables.

Fix:
Instead of using Entries->saveSection(), mute project config events, update project config, and update the section(s) in the database.

Related issues

n/a reported via support

Thanks to @nfourtythree for debugging and proposing the solution.