This is a change request to limit macro and parts to spesific content types.
Old discuss:
Filter parts in content studio.
1 Like
Any comment to this request?
We have not seen any good reason to implement this yet. We cannot see how it would actually improve the system for editors beyond adding frustration - do you have examples of how/what you would like to filter and why?
We have a lot of content types in the app and most of the parts/macros are only needed in spesific content types.
That is the reason why we need a filter to improve the user experience for the editors.
We have also seen this need (and other related needs) in pretty much every site we make. Having an option to limit the part list or the content type list, either by programatically (or xml) filtering out certain parts/macros/content types when needed, or the ability to allow only users within certain groups/roles add a part to a page or create a content type - or preferably both - would be an immensely valuable addition to XP.
Sometimes, a content type is imported/synced from an external system, and should never be created manually (at least not by anyone other than an admin) - but it still makes sense to have the data structured like a content type.
Sometimes, a part should only be used in a template made to display a specific content type, and only serves to confuse editors when it’s a valid choice for them when editing pages.
Sometimes, a part contains very specific and/or powerful functionality, and should only be used in a few select cases. Again, having that functionality available to everyone only serves to confuse editors.
There are dozens of examples, and every site with a decent amount of complexity or a wide enough editor/content creator base we’ve been working on has had a need for this.
Every customer I’ve worked with the last 3 years has wanted this. I want this 
1 Like
I guess this topic is only related to filtering “components on a page” - so I will leave the content type handling for a different topic.
I still would like to see some practical examples of how you would do this? What should be filtered when? Also, filtering based on role is not doable imho. A “super user” might add a component, and then later what should happen if someone less “super” wants to move/change the page.
Historically, my experience is that limiting things like this will cause more frustration than the opposite.
Still, open for good input on how things should be filtered, and why - anectodes are accepted
We want to be able to config the macro/part so that it is either global or connected to spesific content types or multiple. If the part is connected, the editors will only get the choice to add the part from the drop down in the associated content type.
That makes sense, We typically have parts that will not make sense when used elsewhere.
We’ll look into how that could be configured and come back with a solution here!
1 Like
A solution we are discussing is to start by enabling a content type filter on parts. I.e. this way parts like “article show”, will only be visible when editing the page of an article (or page templates).
This is similar to how we already handle x-data, content selectors and similar.
Any comments to this?
That sounds like a start at least, and it would solve some of the usability issues we’ve seen.
Another thought, a separate feature, but related in terms of usability, is to add support for part and content type groups. By naming groups and grouping parts together, you could present the parts in a tree view or a simple dropdown with extra labels. The current alphabetical sorting leaves a lot to be desired.
I think these features, isolated or in combination, would be able to solve a lot of usability issues for our editors.
Filtering parts and layouts will be in the next release.
Macros is still in the backlog.
Regards,
Morten
1 Like