# Allow collectionSelector fragment configuration fields to select all collection provider types when no itemType is specified

**URL:** <https://discuss.liferay.com/t/allow-collectionselector-fragment-configuration-fields-to-select-all-collection-provider-types-when-no-itemtype-is-specified/919>\
**Category:** Product Ideas\
**Tags:** fragments\
**Created:** [September 1, 2026, 9:59am UTC](https://discuss.liferay.com/t/allow-collectionselector-fragment-configuration-fields-to-select-all-collection-provider-types-when-no-itemtype-is-specified/919 "2026-09-01T09:59:28Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jan\_Binder](https://dub1.discourse-cdn.com/flex014/user_avatar/discuss.liferay.com/jan_binder/32/661_2.png) [@Jan\_Binder](https://discuss.liferay.com/u/Jan_Binder)\
**Post date:** [September 1, 2026, 9:59am UTC](https://discuss.liferay.com/t/allow-collectionselector-fragment-configuration-fields-to-select-all-collection-provider-types-when-no-itemtype-is-specified/919/1 "2026-09-01T09:59:28Z")

</div>

Hello,

I would like to request an improvement for the `collectionSelector` configuration field in fragments.

## Current behavior

When creating a Search Blueprint and enabling it to be usable as a collection, the resulting collection can be selected in a standard **Collection Display** widget.

However, if a custom fragment contains a configuration field of type `collectionSelector` without specifying an `itemType`, the same collection is not selectable.

Example fragment configuration:

json

`{`  
` "fieldSets": [`  
` {`  
` "label": "Collection",`  
` "fields": [`  
` {`  
` "name": "collection",`  
` "type": "collectionSelector"`  
` }`  
` ]`  
` }`  
` ]`  
`}`

In this case, only certain collection providers are shown. Blueprints that are registered for a specific type, for example `JournalArticle`, are not displayed.

As a workaround, the fragment configuration can be restricted to a specific item type:

json

`{`  
` "fieldSets": [`  
` {`  
` "label": "Collection",`  
` "fields": [`  
` {`  
` "name": "collection",`  
` "type": "collectionSelector",`  
` "typeOptions": {`  
` "itemType": "com.liferay.journal.model.JournalArticle"`  
` }`  
` }`  
` ]`  
` }`  
` ]`  
`}`

With this configuration, Journal Article blueprint collections become selectable.

## Expected behavior

If no `itemType` is specified in the `collectionSelector` configuration, the selector should behave like the selector used in the standard **Collection Display** widget.

That means all compatible collections should be selectable, including collections based on:

- All Searchable Types
- Journal Articles
- Documents / File Entries
- Object Entries
- Other supported asset or entity types

In other words, an omitted `itemType` should mean “do not restrict the selectable collection types”, instead of implicitly limiting the selector to only `AssetEntry`-type providers.

## Reasoning

The current behavior is confusing because it differs from the behavior of the Collection Display widget.

In the Collection Display widget, the same component can be used with collections from different provider types. A user can select blueprint collections based on “All Searchable Types”, Journal Articles, or other supported types.

For fragments, however, the current implementation requires the developer to define a fixed `itemType`. This makes fragments much less flexible.

If a fragment should support multiple blueprint collection types, developers currently have to duplicate the fragment for each possible item type, for example:

- one fragment for `JournalArticle`
- one fragment for `FileEntry`
- one fragment for `ObjectEntry`
- one fragment for `AssetEntry`
- etc.

This is difficult to maintain and not scalable, especially when the fragment itself is generic and can render different collection types.

## Use case

We create reusable fragments where editors can select a collection in the fragment configuration. These fragments should not be limited to one specific content type.

For example, the same fragment may be used on different pages with different collections:

- a collection of web content articles
- a collection of documents
- a collection of object entries
- a collection based on all searchable types

The fragment is designed to be generic, and the selected collection determines the content. Therefore, the fragment should not have to be duplicated only because the collection provider type is different.

## Requested improvement

Please consider changing or extending the `collectionSelector` behavior so that:

1. If `typeOptions.itemType` is specified, the selector only shows collections for that item type.
2. If `typeOptions.itemType` is not specified, the selector shows all available/compatible collection providers, similar to the Collection Display widget.
3. Blueprint collections for specific item types should also be selectable when no `itemType` restriction is configured.

This would make the `collectionSelector` more intuitive, more consistent with the Collection Display widget, and much easier to use for reusable generic fragments.

Best regards,  
Jan