fix(appconfig,userconfig): restore pre-migration fallback for ownCloud migration

[miaulalala]

Summary

ownCloud → Nextcloud migration broke in NC31+ because AppConfig and UserConfig unconditionally query columns (type, lazy, flags, indexed) that were added by Nextcloud and don't exist in ownCloud's database schema. These columns are only created by migration steps that can't run until the app config system is already functional — a chicken-and-egg problem that caused the entire upgrade to fail with an invalid field name error.

Root cause: A pre-existing try/catch fallback in AppConfig::loadConfig() was removed in a572a5c without a replacement. UserConfig never had an equivalent guard.

Fix: Restore the fallback pattern in both classes:

• On first loadConfig() call, if a DBException with REASON_INVALID_FIELD_NAME is thrown, set $migrationCompleted = false and retry selecting only the columns present in ownCloud's schema (appid, configkey, configvalue / userid)
• When $migrationCompleted = false, INSERT and UPDATE statements also omit the NC-only columns (type, lazy, flags, indexed) so writes don't fail either
• All other exceptions are re-thrown unchanged

This allows the migration infrastructure to boot successfully so the schema migration steps can run and add the missing columns.

Fixes: #57340

Test plan

• AppConfigMigrationFallbackTest — unit tests for AppConfig:
  • fallback triggered on REASON_INVALID_FIELD_NAME
  • non-matching exceptions are re-thrown
  • INSERT omits NC-only columns in fallback mode
• UserConfigMigrationFallbackTest — same three cases for UserConfig

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

AI-Assisted-By: Claude Sonnet 4.6 noreply@anthropic.com

[Robert-Riedl]

This works ! Please merge it soon, if possible :)

[miaulalala]

/backport to stable34

[miaulalala]

/backport to stable33

[miaulalala]

/backport to stable32

[MichaIng]

Awesome @miaulalala, I highly appreciate the efforts to restore a seamless ownCloud 10 => Nextcloud migration! ❤️

The respective documentation page needs to be updated, to reflect a supported upgrade path to latest Nextcloud, right? https://docs.nextcloud.com/server/latest/admin_manual/maintenance/migrating_owncloud.html

I can open a PR, if confirmed.

EDIT: Ah, I did not think about the conflicting PHP version requirements, which would at least require some explanation in the docs. The preferred migration path IMO would be still to latest Nextcloud directly. But one needs to upgrade PHP first.

[miaulalala]

Awesome @miaulalala, I highly appreciate the efforts to restore a seamless ownCloud 10 => Nextcloud migration! ❤️

The respective documentation page needs to be updated, to reflect a supported upgrade path to latest Nextcloud, right? docs.nextcloud.com/server/latest/admin_manual/maintenance/migrating_owncloud.html

I can open a PR, if confirmed.

EDIT: Ah, I did not think about the conflicting PHP version requirements, which would at least require some explanation in the docs. The preferred migration path IMO would be still to latest Nextcloud directly. But one needs to upgrade PHP first.

If you want to give the documentation a shot, that would be lovely! Ping me on the PR and if you're unsure about anything, I can help you or do the rest, whatever you prefer. I appreciate it 😃

[MichaIng]

I opened nextcloud/documentation#15048, and indeed there are some open questions. It is currently half way: migration to latest Nextcloud, but still keeping the table and conditional migration steps, in case latest Nextcloud removes support for migration from older ownCloud versions at some point. But IMO, in that case, upgrading from that ownCloud version should not be supported (and hence not documented) at all. No one will and can guarantee it works, and admins should always be able to upgrade to a supported ownCloud version first. I discussed this in the PR, anyone please let me know what you think, as the page could be simplified/compacted in case.