When a page's Friendly URL is a numeric value matching an existing Layout ID (e.g. /12345), the import process now enforces stricter validation to prevent LayoutFriendlyURLException. Customers who relied on the previous import behavior should review their Friendly URL conventions for imported pages. Shipped in 7.4.13 DXP U146

Behavioral Change / UI Removal

Versions Affected: 2026.q1.1, 2026.q1.2, 2026.q1.3

A development-stage feature related to Page Management Rules was inadvertently exposed in the UI without its corresponding Feature Flag. This may have led users to configure settings that are not yet fully supported or functional.

Starting from version 2026.q1.4, this entry point has been correctly hidden behind a Release Feature Flag. Any configurations made or errors encountered in previous subversions will no longer be accessible or supported.

Customers experiencing issues with this experimental interface must upgrade to version 2026.q1.4 or later.

What changed: All findByXxx_PrevAndNext and filterFindByXxx_PrevAndNext methods have been completely removed from generated persistence classes (*Persistence, *PersistenceImpl, and *Util) for entities utilizing Service Builder 7.4+. Previously, these methods returned a 3-element array containing the previous, current, and next neighboring entities from an ordered result set.

Why: To significantly reduce codebase bloat. Within DXP, these methods generated over 600,000 lines of code but were only used in three internal places. Existing finder methods easily replicate this behavior.

Who is affected: Developers using Service Builder on 7.4 or Quarterly releases who currently rely on PrevAndNext finder methods in their custom logic.

How to migrate:

Choose one of two methods based on your dataset size:

• List Lookup (Recommended): Fetch the current entity using findByPrimaryKey, then retrieve the full matching list using standard findByXxx methods. Find the current entity's index to grab the previous (index - 1) and next (index + 1) items.

• DSL Queries (For large datasets): Use dslQuery with a limit of 1 to execute two targeted database queries — one fetching the immediate previous entry, and one fetching the immediate next entry.

File system artifacts are now deleted when a company partition is removed.

Previously, removing a Virtual Instance (company) with Database Partitioning enabled only dropped the database schema, leaving behind file system artifacts such as Document Library files (data/document_library/{companyId}), search indexes, and configuration files.

Action required: If Database Partitioning is enabled, ensure any needed data is backed up before deleting a partition, as file system artifacts will no longer be recoverable after deletion.

As part of a major search and re-indexing performance optimization, several public search and indexing APIs have been simplified.

• Custom indexer implementations extending BaseIndexer must rename their doReindex(String[] ids) override to doReindexCompany(long companyId).

• Modules using ModelIndexerWriterContributor will need minor updates as helper classes (BatchIndexingActionable, ModelIndexerWriterDocumentHelper) have been removed in favor of direct use of their underlying equivalents.

• The Queries OSGi service has been replaced by the static QueriesUtil, and a small number of other search API methods have had parameters removed or their types updated to reflect their actual usage

Please see full breaking changes list for details.

What changed: Leftover utility classes previously duplicated between portal-kernel and the Petra libraries (petra-string, petra-reflect, etc.) have been removed from portal-kernel.

Why: The duplicated classes were not adding value; removing them simplifies the codebase.

Who is affected: Developers importing these utilities directly from the old portal-kernel packages.

How to adopt: Update imports to the equivalent Petra package. This is a package name change only — no behavioral changes are required.

As Liferay Developer Studio evolves, we periodically evaluate our tooling to ensure a stable and reliable platform. These specific features relied on legacy libraries that we can no longer sustainably maintain. Retiring them streamlines our underlying architecture, ensuring we can consistently deliver timely updates and improvements moving forward.

Removed Features:

• Liferay Upgrade Planner: Feature to aid developers in migrating their code from older versions of Liferay to newer versions.

• Liferay IDE AlloyUI : Development tooling for the AlloyUI framework.

• Liferay IDE XML Search: The XPath-based search tab in the Search menu.

Several alternatives are available in order to ensure existing workflows aren't interrupted:

• Liferay Upgrade Planner

  • The Deprecations and Breaking Changes Reference page is our source of truth for breaking changes with each Liferay release.

  • The upgradeSourceCode command in Blade is actively maintained and offers robust code upgrade automation to handle migrations to newer Liferay versions.

• Liferay IDE AlloyUI

  • For AlloyUI development, the built-in features provided by the Web Tools Platform should provide similar functionality OOTB, though additional configurations may be needed to enable autocomplete and syntax highlighting for AlloyUI. Third-party plugins such as Eclipse Wild Web Developer are also available on the Eclipse Marketplace which offer robust JavaScript support.

  • The taglib metadata can be found here.

• Liferay IDE XML Search

  • If users need XPath-based searching functionality for XML files, Eclipse Marketplace has additional plugins available such as Eclipse XPath Evaluation Plugin.

Developers still requiring these features can remain on their current version of LDS until they have completed their code migration or AlloyUI related tasks.