I’m using v11 and have an issue that I cannot get to the bottom of. I have an element set up in a BlockGrid to allow me to add blocks of content to a page. Locally and in my deployed dev environment I can create and edit this content no problem.
On PRD I do not have the “pencil” icon when I hover on the content in question. The only way I can edit the content is to specify a settings model (to the same element as my content is set to). This then displays a cog when I hover over the content. Clicking then opens the sidebar, with options at the top to switch from “settings” to “content”. This then allows me to edit and save the content as normal, though the pencil icon never appears.
I have used various AI resources and looked at the database, both in terms of looking at the JSON defining the element as well as the caching. This may all stem from changing the case of an alias for a property from “NavShow” to “navShow” and not syncing my environments correctly when carrying out the change.
I have run usync and applied the changes from dev to prd but still cannot get the edit functionality to appear. Other suggestions have revolved around app_plugin folders, but think this is a red herring as there are no plugins involved. I have connected my visual studio instance to the PRD database and still cannot make the editing functionality appear. I see nothing in the F12 developer console or network tabs indicating an error. My PRD instance of the website (and DEV) are running in AWS ECS and I’ve restarted these services via the AWS dashboard multiple times, as well as when the site deploys following updates to the master branch.
Any advice would be welcome, I’m struggling to see where else to look. AI suggests that because of my table names I am using a v8/v9 version of Umbraco that’s then been updated to v11 along the way but I am not 100% sure about this.
I also have it in the back of my mind that I need to upgrade from v11 and .NET 7 to something more modern but would like to understand / sort this first!
A couple of things you can check, start with the quick one
1. “Hide Content Editor” setting
In the backoffice, go to Settings → Data Types → your BlockGrid, then open the block config. Under Advanced there’s a “Hide Content Editor” checkbox.
If that’s ticked on PRD but not on DEV, that alone would hide the pencil icon, so worth checking first.
2. If that’s not it, likely a casing mismatch in the DB
More likely it’s the NavShow to navShow change. uSync updates the schema but doesn’t touch existing content in umbracoPropertyData.
BlockGrid stores values as JSON in textValue, using the property alias as the key. So if old content still has "NavShow" but your schema now expects "navShow", the backoffice won’t match it and the pencil icon just won’t show.
You can check with:
SELECT textValue
FROM umbracoPropertyData
WHERE textValue LIKE '%"NavShow":%'
If you see results, take a full backup first, then run:
UPDATE umbracoPropertyData
SET [textValue] = REPLACE([textValue], '"NavShow":', '"navShow":')
WHERE [textValue] LIKE '%"NavShow":%'
After that, give your ECS tasks a cold restart to clear any caching.
And yes we’d strongly recommend planning that upgrade when you get the chance. Umbraco v17 on .NET 10 is the current LTS,
Thanks for the quick reply. I can confirm that there are no differences between the editor settings on the different environments for the grid block. There are also no records returned with that query in the database as that was one of the steps already taken to try and get the databases into the same state last week.
There must be something different in either your database or the version of Umbraco between those environments. Are you able to pull down the latest copy of production and run it locally on your dev machine does that exhibit the same issue?
Are you able to at least get onto the latest V11 or v13 to see if that helps? I appreciate an upgrade to v17 may be harder but you should at least try and get on the latest v13 as v11 has been out of support for nearly 2.5 years.
Pointing the development environment in Visual Studio at the PRD database does indeed reproduce the error, pointing at an issue with the JSON data that stores the structure of the Umbraco elements in the database I assume?
Is there a differentiation between the definition where navShow / NavShow is set up vs its usage as the umbracoPropertyData has all the content in - do I need to look elsewhere to check the casing of navShow / NavShow?
Yes, there is a difference there are two separate places the alias lives:
The definition — cmsPropertyType is where the property alias is defined at the element type level. This is the schema, not the content.
The usage/content — umbracoPropertyData is where actual content values are stored, which you’ve already checked.
You need to check both. Run this on PRD and compare to DEV:
SELECT id, Alias, Name
FROM cmsPropertyType
WHERE Alias LIKE '%navShow%' OR Alias LIKE '%NavShow%'
If PRD still shows NavShow here while DEV has navShow, that’s your culprit. The BlockGrid editor matches content JSON keys against the property alias in cmsPropertyType a casing mismatch at the definition level would cause it to silently fail to recognise the content, and the pencil icon just won’t appear.
This is separate from umbracoPropertyData being clean the content values can be fine but the definition still has the wrong casing.
Thanks for clarifying the different tables in use. Querying both PRD and DEV returns a “navShow” alias and a “NavShow” name as expected, so no difference between the two environments there.
An update of the site to v17 and .NET 10 is now being discussed at which point this issue should get resolved as we look to rationalise the properties in use. Thanks @BishalTimalsina12 and @justin-nevitech for your inputs - much appreciated.
I wouldn’t assume an update to v17 resolves this issue in case that’s not true. You may want to try migrating the production database to v17 if that’s possible/not too difficult and try it, otherwise you may be trying to sell a solution to your client/business that is wrong. I would try and migrate the database to latest v11, then v13 and then v17 to see if the problem is actually resolved. You don’t need to migrate the front-end, just the database so you can login to the back office to prove this will fix it.
