Cms: Unified “Content” view

[brandonkelly]

The Control Panel’s current way of organizing your content isn’t always ideal, because it doesn’t expose the actual information architecture of the site.

Common example is having a Single section for the landing page of a Structure section. You have to click on “Singles” to find the landing page, but the Structure section’s name to find the rest of the section. It gets even worse if the landing page is something besides an entry section, like a category group.

To fix, Craft should have an optional “Content” view, which gives authors a unified look at all the site’s content (regardless of element type), arranged according to the site‘s information architecture. It would be up to the admin to decide which content should be present, and how it should be displayed in relation to other content.

This would require a new interface that things that want to participate in the page could implement.

Would resolve #831, #990, #1032, and #1490.

[narration-sd]

copying this in, as it gives a hint towards how a solution here might be arranged, also a current work-around.

eric.chantigny @theskyfloor That’s why I mostly never use singles, I use entry types in a Structure section (exception is Homepage). That way, I have control over the IA. Of course, that doesn’t apply to channel content, but the landing page would be in the structure, and the entry type would be something like News Landing, which uses a template based on that entry type to pull all the news.

theskyfloor @eric.chantigny for sure - i think they definitely need to address these needs better in the cp views
08:03]

carlcs @eric.chantigny I often do that as well, but the problem is that the client can add additional entries, change the entry type or the slug.

eric.chantigny Yeah, definitely a problem. It’s more of a bandaid solution

[timkelty]

FWIW, I regularly have client requests for more parity between element types, specifically with revisions/drafts.

Namely, clients tend to want (and expect) revisions and drafts for categories and commerce products, like they do for entries.

[steverowling]

Related to this is to have element indexes that are locale/site aware. So when the locale menu is changed, only sources that are enabled for the chosen locale are shown.

Currently, you can set up sections (singles, channels or structures) that are only enabled for one locale, but they appear in the source list for all locales.

So you can choose the source siteA pages, even if siteB is chosen in the locale menu. It would improve the UX for content editors if the index view changed intelligently to only show sources valid for the chosen locale.

[timkelty]

@steverowling made #2021 to track that request

[timkelty]

Namely, clients tend to want (and expect) revisions and drafts for categories and commerce products, like they do for entries.

Along the same lines, I've also had the need to extend the concept of "Entry Types" to other elements (namely categories), so I could have different field layouts.

[michel-o]

I guess that it would be also usefull for breadcrumb generating - right now, if i want to make breadcrumb from different sections i have to set it up manually in each template, system has no udea that page "about" is subpage of "home".

[Kashkin]

I would love the ability to associate a Channel with a Structure entry. I really miss this from my ExpressEngine days where we used the Structure plugin.

I think Statamic's implementation is even better, and would go a long way to solving the issues mentioned here.

[hiasl]

2 more thoughts:

• Please consider extending the unified content view to also be used as a source for permissions. That means that content editors might not get their permissions for sections, but only for certain parts for the content view including all content which is hooked in there.
• This implies that e.g. structures can be part of / hooked into the content view (or extend it / add additional hierarchy levels to it) and that users might get write access to only parts of it.