Blocks still showing as Draft after upgrade (13 → 17) — tried the known fixes, still stuck

[apples6509 (Brian)]

Hi all,

We’re in the middle of an Umbraco 13 → 17 upgrade and have run into the culture-variance/Block Grid & Block List “Draft” issue that’s been reported elsewhere. Posting here in case anyone has found a fix beyond what’s already documented, since we’ve hit a wall.

Symptoms:

• Pages are published, but blocks inside Block Grid / Block List properties show a Draft label in the back office.

• On the front end, some of the affected block content is missing entirely, even though the parent page is published.

• In some cases, block settings (e.g. custom CSS) are lost entirely during the upgrade — not just left in draft.

• Oddly, blocks used mainly for page layout (rather than lists of child content) seem unaffected, and retain their settings fine. It’s the blocks driving “list of items” style content (e.g. subtopic/child listings) that consistently break, both in draft status and in missing front-end output.

• The only “fix” we’ve found is manually clicking into each block and republishing it, then republishing the page, in every culture — which isn’t feasible given the number of pages and blocks involved.

What we’ve already tried, without success:

1. The steps in this thread

2. Johan Reitsma’s blog post on fixing draft Block Grid/List items by normalizing element types to vary by culture

3. The workaround discussed in umbraco/Umbraco-CMS#21602

Neither approach resolved the draft status or the missing front-end content for us. We still end up with blocks stuck in draft and, on certain page types (ones that render lists of child content), the block content just doesn’t render on the front end at all.

Question for the community: Has anyone gotten past this without the manual “click every block and republish” workaround? Specifically interested in:

• Whether there’s an order-of-operations issue with the vary-by-culture switch + DB script combo (e.g. does it matter whether you flip properties before vs. after running the scripts, or whether content needs to be re-saved/re-published via the Content API vs. the back office UI?)

• Whether the “lost settings” (custom CSS, etc.) issue is a separate bug from the draft/culture issue, or connected

• Whether the missing front-end content on list-style pages might be a views/rendering issue on our end rather than a data issue (we’re using views to render lists of child items, and it’s specifically that content that’s not showing — not sure if that’s an Umbraco-side quirk or something we need to fix in our own templates)

We have far too many pages/blocks to consider manually republishing everything, so any pointers — official or unofficial — would be hugely appreciated.

Thanks in advance!

[TomChancer (Thomas Chance)]

Hey Brian,

Not sure on the exact setup you are on (Migrating from block list v13 to block list v17 for example or from an older property like nested content on v13 to block list in v17) or if you have access to Umbraco Deploy.

But what I experienced in the past that tended to cause these issues was that the JSON Data from within the block grids and lists was not getting a new bit of data attached to it called the “expose” object when it was transformed as part of the upgrade.

Its effectively what tells the block grid and list what parts are published and in what language (In a very simplified manner of explanation).

I wrote up some code that I posted on the issue board at the beginning of the year in deploy: Migrating Legacy Grids to Block Grids and Nested Contents to Block Lists misses the expose value. · Issue #325 · umbraco/Umbraco.Deploy.Issues · GitHub

Might be worth a look to see if your “Post” migrated block lists / grids contain that expose value and if not, attempt a migration to try and include them?

Fair warning, the code I wrote in the attached issue hooks into the Umbraco deploy artifact migration flow, so if not using deploy, you would have to rewrite it appropriately to however you prefer to do the content migration.

[justin-nevitech (Justin Neville)]

Hi @apples6509

Did you try changing the vary-by-culture on the elements before you migrated away from v13?

Umbraco 17 issues: Culture mismatch in Umbraco 17 after upgrade from Umbraco 13

Hey, I tried to run the SQL command @JohanReitsma wrote about to change the Element types on the v13 database before migration to v17. Most of the blocks are OK, but some of them lose the content. It’s strange, because some the blocks that lose content are placed side-by-side to others that don’t lose it so it’s really confusing why this happens. It’s even more strange because the data of the properties that are inherited from a composition remain in the block as if nothing happen. EDIT: I fo…

Justin

[apples6509 (Brian)]

@justin-nevitech thanks for the repsonse. i did indeed try this but unfortunately it did not solve the issue. In my particular case it seems Thomas’ issue is also affecting me, the “expose” array is empty.

@TomChancer this does indeed seem to be affecting me. setting the expose array where relevant element types are invariant solves resolves the draft blocks.