Breaking changes for Umbraco 17 support

[markadrake]

Hi there,

First, I want to express my appreciation for the work you've put into Contentment—it's been invaluable to our projects. I'm primarily a frontend engineer, so I apologize if I'm missing context or approaching this from a less-than-ideal angle. I wanted to share some findings that might be helpful for the v17 migration.

I'm working on planning an Umbraco 16 → 17 migration for a client and need to document potential issues ahead of the v17 LTS release (late-November/early-December). To test feasibility, I forked Contentment and created a branch to identify breaking changes:

Branch: https://github.com/markadrake/umbraco-contentment/tree/dev/v7.x

Key Findings:

I ran into several breaking changes where methods/extensions that were available in Umbraco v16 are no longer shipped in v17.
The minimal changes I needed to make to boot the Umbraco Backoffice are in this commit.

The good news is that by adding back the missing methods and extensions (ref: ObjectExtensions.cs), I was able to get Contentment to stop throwing errors on page load and work in all the scenarios I could readily test.

I'm sharing this in case it's helpful for your v17 compatibility work and for others in the community who might be planning similar migrations. If there's additional testing or information that would be useful, I'm happy to help where I can.

Thanks again for maintaining this project!

[markadrake]

If you're following along, I didn't check in the updates to Umbraco.Community.Contentment.csproj. You'll need to update the references to Umbraco accordingly.

[leekelleher]

Thanks @markadrake, I appreciate you making the effort to support v17 already. 💪

My aim was to wait until v17RC was out (30th Oct) to add support, but that's mostly because v17 itself is my main work focus/priority.

I haven't quite decided whether Contentment v6.0 (final) should target v16 or v17 yet, I mean it should be possible to support both, but again that's something else I look at once v17RC is out.

In the meantime, if you're happy to keep your fork updated with the changes to support v17 breaking-change, then they may come in super helpful to me. 🙏

[cti-mguedelha]

I guess the main question is if whatever 17 breaking changes fixes need to be done, if they are available/compilable against the 16 CMS version, then v6 could support both 16 + 17, otherwise a v7 will prob be needed for targeting 17?

[MiguelGuedelha]

Created #492 which solves the 2 breaking build errors that would occur if moving versions up to v17 (the PR itself does not include any Umbraco version bumps as expected)

[leekelleher]

@markadrake @MiguelGuedelha (@cti-mguedelha) thank you for your support for v17 compatibility. I started looking at both of your code last night. I'll find a way to bring it all together. 💪

Although I have hit another issue for v17 support, which is the migrations, they are currently failing... meaning that for anyone who upgrades from v13 to v17, none of the Contentment property-editors will work (as in the data-type configurations aren't migrated). If you've upgraded from v14/v15/v16, then this isn't an issue.

I'm still trying to pinpoint whether this is a bug with Contentment or with v17 core. 🤞

[leekelleher]

Quick update, I figured out my migrations issue with upgrading from v13 to v17, it was uSync, I had "ImportAtStartup" enabled, and that was running after the migrations, which meant that all my existing data-types got reverted to their v13 state. 🤦 I disabled the "ImportAtStartup" option, re-upgraded/migrated and all was good! 😅

[cti-mguedelha]

So when migrating from U13 to U17 the initial process for the local/remote dev instance would need to be:

• Make sure ImportAtStartup is disabled on the CMS config
• Let Umbraco do its thing
• Run a uSync export
• Re-enable at that point as it should contain all the migrated types, definitions, etc in place of the older ones, and propagate up the environments as normal?

[leekelleher]

Yes. I'd go as far to say that should be the steps for any Umbraco upgrade.

I'll also try to co-ordinate with Kevin/uSync to check that I'm not missing a certain configuration/setting that already works around this.

[cti-mguedelha]

Yeah most of our projects have it disabled in general, except usually in QA/UAT environments as we just let it auto run on those, so nice to know about this ahead of a possible upgrade 😄

[leekelleher]

@markadrake @MiguelGuedelha FYI, I've pulled together both of your changes into a new PR: #493.
I have given you commit credit on the corresponding code changes. 🥇