We have moved to GitHub Issues
You are viewing the read-only archive of Umbraco's issue tracker. To create new issues, please head over to GitHub Issues.
Make sure to read the blog posts announcing the move for more information.
Created by Miku Kelley 21 Oct 2014, 16:53:58 Updated by Chris Morley 06 Dec 2017, 11:14:37
Is duplicated by: U4-6800
Relates to: U4-6800
Relates to: U4-10734
Relates to: U4-4569
Relates to: U4-5352
Subtask of: U4-9609
Buy document has list view enabled (Child Items tab is created by Umbraco, Content tab has a sort order/id of 1, widgets tab is 2, and so on. Content and Widgets are not Inherited tabs/properties but set on this doctype) [screenshot 1] Notice that the MNTP for Widgets appears below the Child Items instead of on the tab it is assigned to [screenshot 2]
Changing to the widgets tab we don't have the widgets MNTP here (where it should be), just the Child Items table again (not sure it should be) [screenshot 3]
Going back to the Child Items tab we now have no widgets MNTP and no amount of going between the tabs will bring it back or make it appear (oh noes) [screenshot 4]
This isn't limited to MNTP, before the MNTP was there it did the same thing with the texstring and richtext editor properties on the Content tab, nor is it just this doctype...
Edit: Looks like U4-5352 U4-4569 are from this same issue
6 Attachments
Unfortunately I can't reproduce this issue on a clean 7.1.8 install: Create a doctype with 3 tabs, the document type has an MNTP, RTE and color picker on different tabs, this all shows on the tabs I assigned for them.
Please re-open this issue if you can reproduce this on a clean 7.1.8 install and give some more detail on what's on there so we can reproduce and investigate.
I can reproduce this on a clean 7.1.8 Could it be something to do with the number of tabs, inherited & on the docType in question; as a comparison of the html on content shows that on nodes where this problem is happening and on nodes where it isn't the Child Items tab is being generated as:
On one where this isn't happening it also has the following tabs markup within
But on the instance causing the error above (which I have recreated by recreating, not copying or exporting and importing, the site docTypes and content in a clean 7.1.8) has the following tabs markup within
Notice the second tab25 (which is the widgets content)
It is also the same on the docType with the richtext editor that is behaving like this: within
TabsAndPropertiesResolver.cs states listViewTab.Id = 25; If 25 is set in stone for the "Child Items" and there are enough doctypes with tabs to get to the ID 25 I'm guessing this is why creating just 1 doctype with 3 tabs as a test is not recreating it but when I recreated the whole site's doctypes I immediately get the problem again?
As such I will mark this as open again.
Just to add, although not pretty, adding for(tab in data.tabs) { if( data.tabs[tab].alias == "umbContainerView" && data.tabs[tab].id == 25 ) { data.tabs[tab].id = 110432; } } to the umbraco.controllers.js within contentResource.getScaffold and contentResource.getById blocks has fixed it for now; as the site needs this feature going forwards I had to employ a workaround and don't see myself hitting 110432. A proper work around would probably calculate a true id here or in TabsAndPropertiesResolver.cs by looking at what tab ids already exist, and making sure the child list is always bigger.
I absolutely believe that you can reproduce it, I just need to be told how so we can look at it. Would be good if we could get the database of your clean 7.1.8 install that's displaying this problem.
The easiest way to reproduce it is to create a doctype and give it 25 tabs, place some properties on each tab, enable list view, and watch what happens when you create it under content. Although this isn't something I would call real world, it does show the problem. In my case the first tab I created actually got the id of 12 so I only needed to create 13 tabs to create the problem, which isn't that hard a number to reach if you run multiple sites in a single instance or have many very different document types. I guess my two live sites that I've used my workaround on were just very unlucky in that the 25th tab is an important one that gets inherited by other doctypes.
I have attached the .bak of a really quick demonstration of the issue for you.
Unsure how viable this is as a solution but working from source; changing line 125 of TabsAndPropertiesResolver.cs (Umbraco.Web.Models.Mapping) from: listViewTab.Id = 25; to: listViewTab.Id = display.Tabs.Count() + 25;
Then building and replacing umbraco.dll has fixed the issue on that sample site.
Closing issue due to inactivity - see blog post for details https://umbraco.com/blog/issue-tracker-cleanup/
We're running into this issue as well; when activating list view for a content type that also has a cmsPropertyGroup with id=25, both tabs share the editor of whichever tab is leftmost and the other editor is inaccessible.
I am experiencing this issue too now, on a clean installation of 7.6.3. I think this problem may be exacerbated through the use of a number of "compositon" documents/tabs, meaning the number of tabs in the system can quickly reach 25.
I opened this in 2014, it was insta-closed (dismissed) and even after reopening it, and giving everything required to reproduce or see where to fix it, nothing was done. I wish you guys luck but in the end we had to fork and apply our own fix to each version we used.
src/Umbraco.Web/Models/Mapping/TabsAndPropertiesResolver.cs Change: listViewTab.Id = 25; To: listViewTab.Id = display.Tabs.Count() + 25;
The extra step might be the reason our boss wants to move to Wordpress :(
@Miku Thanks Miku. I actually used your "umbraco.controllers.js" solution above to avoid rebuilding the DLL (my first ever core code change, really) and this helped, but obviously this is going to be an issue going forward, with updates. I know what you mean ;)
PR: https://github.com/umbraco/Umbraco-CMS/pull/2049
Since this is a tough one to reproduce, I've added a video. In the first part, tab number 8 got the ID of #tab25 which means the list view (hardcoded with ID 25) is showing up instead of the content of tab number 8.
After adjusting the code and rebuilding it, the list view tab just gets the highest tab ID + 1, which means it's not #tab28 and the number 8 tab is still at #tab25 which now works (has an mntp on it).
@nul800sebastiaan there is also this issue about the hardcoded tab id, when listview is enabled. http://issues.umbraco.org/issue/U4-6800
and this PR https://github.com/umbraco/Umbraco-CMS/pull/1552
Maybe also take a look at the PR here to rename the "Child items" tab: https://github.com/umbraco/Umbraco-CMS/pull/2034
@sebastiaan PR all looks good & merged in
@Bjarne.Fyrstenborg Thanks U4-6800 has the same solution as this one. Great suggestion, U4-10088 is now also fixed and part of the next release!
I dont think this is quite fixed. On our latest Umbraco Cloud (7.6.11) we have a tab which is inheritting a tab from a composition with ID 12. and when we are enabling ListView the generated tab is calling
listViewTab.Id = display.Tabs.Count() + 1;
And setting its TabId to 12 also (in my instance).
We need to ensure that the tabId doesn't clash with any existing tabs on the doctype. I saw that there was a commit: https://github.com/umbraco/Umbraco-CMS/pull/1552/commits/56f4166be742037af72ecef65b91fd38dd7da45a which seemed to do this by adding 1 to the highest tab Id on the Document. This seems like the simplest way to achieve this.
Priority: Major
Type: Bug
State: Fixed
Assignee:
Difficulty: Normal
Category:
Backwards Compatible: True
Fix Submitted: Inline code
Affected versions: 7.1.6, 7.1.7, 7.1.8, 7.5.8, 7.6.1
Due in version: 7.6.5
Sprint: Sprint 63
Story Points:
Cycle: 3