Feature Requests

Preserve "Documents and Media" folder context when selecting images

2025-09-01T00:35:09Z

When selecting an image from a fragment editable image field,
e.g.: <img src="placeholder.jpg" alt="Placeholder" data-lfr-editable-id="img1" data-lfr-editable-type="image" >

we are taken to the root of "Documents and Media".

If we’ve created a folder hierarchy and, on a content page, we need to display all the images contained in the last folder of the hierarchy, then for each image, we have to browse through the entire folder structure again, which becomes tedious when dealing with a large number of images.

Would it be possible, when working on the same page and an image has already been selected from Documents and Media, to reopen the Documents and Media window and be positioned at the folder location of the previously selected image (either by default or by enabling an option)?

RE: CKEditor 5 Support for Editable Rich Text in Fragments

2025-07-31T14:07:36Z

Hi Jérémy,

I've opened the ticket here:

[LPD-62096] CKEditor 5 Support for Editable Rich Text in Fragments

RE: Group-Level conditional visibility for fragment configuration fields

2025-07-31T13:59:43Z

Hi Jérémy,

I've opened this feature request for you:

[LPD-62093] Group-Level conditional visibility for fragment configuration fields

RE: Restricting Access to Fragment Sets by User Role

2025-07-31T13:57:40Z

Hi Jérémy,

I've created the request for you:

[LPD-62092] Restricting Access to Fragment Sets by User Role

RE: Improving usage tracking for Global site fragments

2025-07-31T13:55:43Z

Hi Jérémy,

I've created the request for you:

[LPD-62091] Improving usage tracking for Global site fragments - Jira

RE: Improving publication naming: Proposal to add First and Last Name tokens

2025-07-31T13:53:41Z

Hi Jérémy,

I've created the request for you here:

[LPD-62090] Improving publication naming: Proposal to add First and Last Name tokens

Multi-select form popup now auto-closes after selection.

2025-07-29T10:47:25Z

There is also one ticket about: https://liferay-support.zendesk.com/agent/tickets/138543, Regarding the search concern, we're clarifying to the customer that Clay Picker is designed as a simple selector, not a searchable component. It relies on native functionality, allowing users to type and navigate to the desired option using the keyboard.

However, the feature mentioned below is a specific customer requirement

https://liferay-support.zendesk.com/agent/tickets/138282

In the form field with multiple selection enabled, the popup now closes automatically after selection. Unlike the older version, where it worked correctly, and the customer is using 7.4.13 Update 64, now the customer is upgrading.

Client Liferay older version: 7.4.13 Update 64
Latest Liferay version: 2025.Q1.5 LTS

Improving publication naming: Proposal to add First and Last Name tokens

2025-07-28T13:48:18Z

When a Publication is created, it is assigned a name:
Default Template or Default Sandbox Template (depending on the case)
https://learn.liferay.com/w/dxp/sites/publishing-tools/publications/using-publication-templates

It is also possible to create custom templates.

However, only three tokens are currently available:

${RANDOM_HASH}
${TODAY_DATE}
${CURRENT_USERNAME}

${CURRENT_USERNAME} corresponds to the user's Screen Name, which does not always allow other users to clearly identify the author of the publication.

Would it be possible to add the following variables:

${FIRST_NAME}
${LAST_NAME}

Kind regards

Improving usage tracking for Global site fragments

2025-07-24T16:11:35Z

We have created Custom Fragments organized into "Fragment Sets".
To make them usable across different sites, we placed them in the Global site.

For fragments defined on a specific site, it is possible to view their individual usages through the "View Usages" option (Design > Fragments > ...).
This is particularly useful when modifying a fragment’s code, as it allows us to see the impact across all instances of that fragment.

However, for fragments defined in the "Global" site, we can only see the site-level usage: "View Site Usages" (e.g., Fragment A is used X times on Site S)
(Global Site > Design > Fragments > ...).

When editing a specific site, the fragments (defined in the Global site) are visible (Design > Fragments > ...), but the fragment set has a lock icon and is not editable (which is expected, as they come from the Global site).
However, it is not possible to view their usage on the site.
This is inconvenient for maintenance, because when changes are needed, we are unable to determine where the fragment is used within the site.

Would it be possible to have the "View Usages" option for fragments defined in the "Global" site (just like it exists for fragments defined at the site level)?

Kind regards,

Preserve selection order in API for "Select from List" field

2025-07-24T16:11:04Z

In Web Content Structures, when using a "Select from List" field with multiple selection enabled, the UI allows users to visually reorder selected items. However, the current behavior does not preserve this order when retrieving the values via API.

This is particularly problematic when editors rely on the selection order to define the display or processing logic downstream. For example, in our case, the selection order (e.g., priority_per_price, date_rt, product_name, priority, price_desc, price_asc) was meaningful and used in production systems to drive sorting behavior.

We have confirmed that in Liferay 7.4 q1.0 2025, the order is not preserved and appears to be stored arbitrarily, which breaks the expected functionality after recent upgrades. The visual reordering in the UI is not reflected in the actual stored data or API response.

This behavior causes confusion and breaks backward compatibility in environments where selection order has functional implications.

We suggest either:
- Persisting the selection order as defined by the user in the API.
- Or, at least, allowing the configuration of this behavior per field or structure.

This feature would improve consistency and data reliability for use cases where selection order matters.

Restricting Access to Fragment Sets by User Role

2025-07-24T16:10:09Z

When designing a "Content Page", by default all "Fragment Sets" are available:
"Layout Elements," "Basic Components," "Content Display," "Account," etc.
There are twelve by default, not counting custom Fragment Sets.

We want to restrict access to certain "Fragment Sets" for some users. These users should design "Content Pages" only with specific Fragment Sets.

Would it be possible to associate "Fragment Sets" with roles?

For example, a group of users would have access only to our custom "Fragment Sets."

Kind regards

Group-Level conditional visibility for fragment configuration fields

2025-07-24T16:09:43Z

Since Liferay DXP version 2025.Q2, it is now possible to configure "Conditional Field Visibility" in a fragment's configuration JSON: LPD-46393
https://liferay.atlassian.net/browse/LPD-46393
This new feature is very useful, as it helps avoid cluttering the configuration screen when fields are interdependent.
https://learn.liferay.com/web/guest/w/dxp/development/developing-page-fragments/reference/fragment-configuration-types-reference#conditional-field-visibility-configuration

However, there are still several drawbacks:

If x fields depend on the value of a single field, you have to configure each of those x fields individually by adding "dependency": { [...] } every time.
If a field’s visibility depends on another, both fields must be present in the same "fields" array.

What we would like is to be able to manage the visibility of a group of fields at the "fields" level — meaning the dependency property would be at the same level as "label", and not only inside each individual field.

Exemple :

{
	"fieldSets": [
		{
			"fields": [
			  {
				"name": "checkbox1",
				"type": "checkbox",				 
				...
              },
		      {
				"name": "checkbox2",
				"type": "checkbox",				 
				...
              }			  
			]	
        },		
		{
			"fields": [
			  { [...] },
			  { [...] },
			  { [...] },
			  { [...] }
			],
            "label": "Group 1",
            "dependency": {
				"checkbox1": {
					"type": "equal",
					"value": "true"
				}
            }			
        },		
		{
			"fields": [
			  { [...] },
			  { [...] },
			  { [...] },
			  { [...] }
			],
            "label": "Group 2",
            "dependency": {
				"checkbox2": {
					"type": "equal",
					"value": "true"
				}
            }			
        }
      ]
}

Is that something that could be done?

Kind regards,

Allow Liferay Cloud CI (Jenkins) to be able to build with different JDKs

2025-07-10T20:18:43Z

There is a limitation with liferaycloud/jenkins:2.492.3-lts-jdk21-6.0.3 that keeps the CI from working with different JDKs (i.e. a branch or repository with Java 8 and another with Java 21 when upgrading from one version of Liferay to another).

This is related to the breaking changes introduced with https://help.liferay.com/hc/en-us/articles/33476891762317-1-14-2025-Service-Release-Updates.

The only alternative to this right now is to update LCP_CI_GRADLE_JDK every time a build needs to be done with one or another JDK, which makes CI not continuous.

Ability to move web content from one site to another

2025-07-08T19:02:21Z

Currently, this is possible for the "Documents and Media" section but not for the "Web Content".

Would be useful to be able to move the "Web Content" to other sites without having to delete and then reproduce.

CKEditor 5 Support for Editable Rich Text in Fragments

2025-06-20T14:02:34Z

Hello,

We are currently using editable Rich Text fields within Fragments, as shown below:

<div data-lfr-editable-id="text1" data-lfr-editable-type="rich-text"> Placeholder </div>

The Rich Text Editor in use is AlloyEditor, which offers limited functionality compared to CKEditor. Specifically, we require access to the HTML editor (sourcearea), which is not available in AlloyEditor.

In the latest release, DXP 2025 Q2.1, there's a section titled "CKEditor 5 in Web Content":

CKEditor 5 in Web Content – Liferay Release Notes

It states that CKEditor 5 is now available as a Beta Feature and that it will be included for Page Builder.

Could you please confirm when CKEditor 5 will be available for editable Rich Text fields inside Fragments?

Thank you,

Jérémy Conrad

Don't filter approved web contents by default or let configure it

2025-06-20T13:24:50Z

Product menu > Content > Web Content: For every role other than Content Reviewer or Site Administrator, the web content list is filtered by default to show only approved contents.

https://github.com/liferay/liferay-portal/blob/master/modules/apps/journal/journal-web/src/main/java/com/liferay/journal/web/internal/display/context/JournalDisplayContext.java#L574

Thus, the list doesn't display folders first and contents later when ordering by Modified date and, obviously, doesn't show the expired and draft contents.

Moreover, if you clear the filter, the configuration is not saved and you have to clear the filter again and again.

That's why this preference should't be applied by default, or at least it should be configurable.

Limitação na Detecção de Atividade Durante Navegação com Leitor de Tela

2025-06-23T17:35:30Z

Prezados, boa tarde!

Conforme informamos no ticket https://help.liferay.com/hc/en-us/requests/134752 estamos com uma situação que:

"O portal considera como inatividade a navegação realizada por meio de leitor de tela ou pelo foco do usuário (usando Tab ou setas). O leitor de tela aqui referido é o NVDA mas, até mesmo utilizando o mouse, se não houver nenhum processamento, mudança de tela ou algo do gênero, mesmo clicando em objetos da tela, a sessão acaba sendo encerrada por inatividade. Ademais, quando a sessão está para ser encerrada por inatividade, surge uma mensagem amarela na tela informando, mas isso só é perceptível para nós que enxergamos mas, para as pessoas com deficiência visual, não há qualquer tipo de notificação perceptível pelo leitor NVDA. Somente quando a sessão expira é que surge a mensagem em vermelho e, esta sim, é perceptível ao leitor NVDA."

No referido ticket, fomos informados que esta feature está em desenvolvimento e gostaríamos de saber em qual versão há previsão de lançamento da mesma.

Atenciosamente,
Nivea Sousa

RE: Optimize openIDConnect provider

2025-06-03T16:55:44Z

Feature Request Created: https://liferay.atlassian.net/browse/LPD-57065

RE: RE: Homogenize the functionality of the Not Visible to Guest Users icon

2025-06-03T16:51:08Z

Hi, I think this icon should be shown with every asset that can be "Not Visible to Guest Users". There surely are more elements affected, but taking into account the few we are using at the moment, the ones I mentioned were:

Content&Data > Web content: in any view, Folders.
Content&Data > Documents and media: in any view, Folders.
Content&Data > Forms: Forms with the "Require User Authentication" option. (I didn't mention this, because I know it's going to be deprecated; maybe everything else is going to be too).
Site builder > Pages: Pages.
Categorization > Categories: Vocabularies and Categories.

Let me know if you need more info or how can I attach screenshots if you need them.

Optimize openIDConnect provider

2025-06-03T16:50:53Z

Hi,

This is a feature request.

For my client, we need to use the idp of the company.

This idp is not very fait and we made an optimisation but it be great to have it in the liferay module and not in our custom module.

First when we connect, Liferay call the endpoint UserInfo but we have all ready the infos in the JWT Token (name, firstName and email)

It would be great to have a configuration option (a boolean) to do the call to the userInfo endpoint or not.

For us we win about 500ms if we do not this at every connection.

Second optimization, sometimes our idp is down. And all our clients are disconnected by the offlineOpenIdVonnectManager because it tries to extend the session but the session is not end (it will end in 5 minutes yes) but why close the session if the token is available 5 minutes more ?

Maybe this manager can try 1 minute later another call and close the session only if it is a forbiden or if the token is outdated but not if we have a network issue.

Of course this should be configurable in the liferay system (or instance) configuration like is it for the other options.

Eric.