oo
Analytics Cloud
Commerce
DXP / Portal
Liferay Cloud
Reference
Reference

7.3 Breaking Changes

This document presents a chronological list of changes that break existing functionality, APIs, or contracts with third party Liferay developers or users. We try our best to minimize these disruptions, but sometimes they are unavoidable.

Here are some of the types of changes documented in this file:

  • Functionality that is removed or replaced
  • API incompatibilities: Changes to public Java or JavaScript APIs
  • Changes to context variables available to templates
  • Changes in CSS classes available to Liferay themes and portlets
  • Configuration changes: Changes in configuration files, like portal.properties, system.properties, etc.
  • Execution requirements: Java version, Java EE Version, browser versions, etc.
  • Deprecations or end of support: For example, warning that a certain feature or API will be dropped in an upcoming version.

Breaking Changes List

Liferay FontAwesome Is No Longer Included by Default

What changed?

Liferay FontAwesome, which included icon fonts for Font Awesome, Glyphicon, and custom Liferay icons, is no longer included by default.

Who is affected?

This affects pages or sites that have a Theme applied that does not include these icon fonts itself. Any content or code on such pages or sites that uses these icon fonts will no longer work.

How should I update my code?

Depending on how you’re using icon fonts, there’s a few approaches you can take.

For liferay-ui:icon usage

Replace <liferay-ui:icon iconCssClass="icon-user"> with <liferay-ui:icon icon="user" markupView="lexicon" />

For JavaScript-generated icons

Those manually generating FontAwesome icon html can use the Liferay.Util.getLexiconIconTpl('user') API. For example, the previous call would return the html code for a user svg icon.

For direct HTML within JSPs

Developers directly using icons in jsps can either use the liferay-ui:icon tag as explained above or the clay:icon one to generate svg-based icons instead.

For non-controlled code

If you don’t have access to the content that uses the icon fonts or you don’t want to update the code or content, you can include the fonts in your Themes.

During the 7.2 upgrade process, the theme upgrade assistant prompts developers to keep FontAwesome as part of the Theme. Themes that already include the icon fonts won’t be affected and will continue to work in 7.3.

Why was this change made?

This change was made to save bandwidth and increase performance of your sites by not serving unnecessary files.

Removed liferay.frontend.ProgressBar

What changed?

The legacy metal+soy liferay.frontend.ProgressBar component, used as a temporary bridge for legacy behavior, was removed.

Who is affected?

This affects any code that relies on liferay.frontend.ProgressBar; this is usually done via soy as {call liferay.frontend.ProgressBar /}.

How should I update my code?

There’s no direct replacement for the liferay.frontend.ProgressBar component. If you have a component that relies on it, you can co-locate a copy of the old implementation and use it locally within your module.

Why was this change made?

The liferay.frontend.ProgressBar component was deprecated in 7.2 and is no longer used.

AssetCategory’s Tree Path Replaces Left/Right Category IDs

What changed?

Left and right category IDs in an AssetCategory have been removed and replaced with a single tree path.

Who is affected?

This affects anyone who uses left and right category IDs in AssetCategory and associated APIs.

Left and right category IDs were primarily used for AssetCategory’s internal hierarchical tree.

Existing AssetCategory service APIs remain the same, except AssetCategoryLocalService::rebuildTree(long groupId, boolean force), which has been removed.

These methods have been removed from AssetCategoryUtil:

  • countAncestors
  • countDescendants
  • getAncestors
  • getDescendants

Methods related to left and right category IDs have been removed from AssetEntryQuery.

Finder methods ending in G_P_N_V have been replaced with methods ending in P_N_V.

How should I update my code?

For left and right category IDs

If you’re using left and right category IDs, consider these options:

  • Adapt your code to use the new tree path
  • Explore whether a service API can be used to accomplish the same goal

For example, instead of working with the category IDs via category.getLeftCategoryId() and category.getRightCategoryId(), you can get the tree path via category.getTreePath(). Then use the tree path.

As a reference, this snippet AssetCategoryLocalService sets the tree path when adding a category:

if (parentCategory == null) {
    category.setTreePath("/" + categoryId + "/");
}
else {
    category.setTreePath(
        parentCategory.getTreePath() + categoryId + "/");
}

See 7.3.0-ga1 - AssetCategoryLocalServiceImpl.java#L122-L128.

For AssetCategoryLocalService#rebuildTree(long, boolean)

Calls to AssetCategoryLocalService#rebuildTree(long, boolean) may be unnecessary. This method was mainly used to help maintain the internal hierarchical tree implmentation that has now been replaced.

Consider re-evaluating your existing code to confirm whether your call to the rebuildTree method is still needed.

For AssetCategoryUtil and AssetEntryQuery

If you use methods removed from AssetCategoryUtil and AssetEntryQuery, consider these suggestions:

  • Re-evaluate your existing code
  • Explore whether an existing service API can accomplish the same goal
For Finder Methods Involving G_P_N_V

If you use AssetCategory finder methods that end in G_P_N_V, use the methods ending in P_N_V instead.

Why was this change made?

This change was made to improve the hierarchical tree implementation for AssetCategory.

Removed liferay.frontend.Slider

What changed?

The legacy metal+soy liferay.frontend.Slider component, used as a temporary bridge for legacy behavior, was removed.

Who is affected?

This affects any code that relies on liferay.frontend.Slider; this is usually done via soy as {call liferay.frontend.Slider /}.

How should I update my code?

There’s no direct replacement for the liferay.frontend.Slider component. If you have a component that relies on it, you can co-locate a copy of the old implementation and use it locally within your module.

Why was this change made?

The liferay.frontend.Slider component was deprecated in 7.2 and is no longer used.

Removed com.liferay.asset.taglib.servlet.taglib.soy.AssetTagsSelectorTag

What changed?

The Java class com.liferay.asset.taglib.servlet.taglib.soy.AssetTagsSelectorTag was removed.

Who is affected?

This affects any code that directly instantiates or extends this class.

How should I update my code?

There’s no direct replacement for the removed class. If you have code that depends on it, you must copy over the old implementation to your own project and change the dependency to rely on your local version.

Why was this change made?

The asset:asset-tags-selector and its components have been migrated to React, making the old tag and its soy infrastructure unnecessary.

Removed Portal Property user.groups.copy.layouts.to.user.personal.site

What changed?

The portal property user.groups.copy.layouts.to.user.personal.site and the behavior associated with it were removed.

Who is affected?

This affects anyone who set the user.groups.copy.layouts.to.user.personal.site property to true to copy User Group pages to User Personal Sites.

How should I update my code?

There’s no direct replacement for this property. If you depend on the behavior, you can copy the old implementations of UserGroupLocalServiceImpl#copyUserGroupLayouts to your own project.

Why was this change made?

The behavior associated with this property has been deprecated since 6.2.

Removed Support for Auto Deploying EXT Plugins

What changed?

The support for deploying EXT plugins using Auto Deployer (via liferay-home/deploy folder) was removed. EXT plugins copied to the deploy folder are no longer recognized.

Who is affected?

This affects anyone deploying EXT plugins via the Auto Deployer.

How should I update my code?

There’s no direct replacement for the removed feature. If you have an EXT plugin, you must deploy it manually or use ant direct-deploy.

Why was this change made?

This feature has been deprecated since 7.1.

Replaced OSGi configuration Property autoUpgrade

What changed?

The OSGi property autoUpgrade defined in com.liferay.portal.upgrade.internal.configuration.ReleaseManagerConfiguration.config was replaced with the portal property upgrade.database.auto.run.

Unlike the old property, which only controlled the upgrade processes in modules, the new one also affects the Core upgrade processes. The default value is false, so upgrade processes won’t run on startup or module deployment. You can execute module upgrade processes anytime via the Gogo Shell console or via Database Upgrade Tool when the server is down.

This property is set to true in the portal-developer.properties

Who is affected?

This change affects any environment where you’re expecting to run upgrades automatically on server startup or on module deployment. Setting upgrade.database.auto.run to true is not recommended in production environments. If you must, however, upgrade on server startup, first back up your Liferay database and File Store (Document Library).

If you set upgrade.database.auto.run to false (default value) but database upgrade is required, Liferay prints information about the required upgrade and halts startup. Database upgrade is typically required by major/minor Liferay releases and may be required by early CE Portal GA releases and certain Service Packs (in exceptional cases)–Fix Packs never require database upgrade. On startup, Liferay prints information about any pending micro changes. You can always use the Gogo Shell console and release notes to check such changes and then decide whether to execute them.

How should I update my code?

This change doesn’t affect your code.

Why was this change made?

This change was made to unify the auto-upgrade feature between the Core and modules. The default value was also changed to avoid executing new upgrade processes on startup in production environments.

Removed SingleVMPoolUtil and MultiVMPoolUtil classes

What changed?

The SingleVMPoolUtil and MultiVMPoolUtil classes have been removed.

Who is affected?

This affects anyone using these removed classes.

How should I update my code?

Use PortalCacheHelperUtil instead of SingleVMPoolUtil or MultiVMPoolUtil. For example, see SQLQueryTableNamesUtil.

Why was this change made?

The SingleVMPoolUtil and MultiVMPoolUtil classes were originally deprecated in LPS-84138. The classes are no longer in use.

Removed Cache Bootstrap Feature

What changed?

The cache bootstrap feature has been removed. These properties can no longer be used to enable/configure cache bootstrap:

  • ehcache.bootstrap.cache.loader.enabled
  • ehcache.bootstrap.cache.loader.properties.default
  • ehcache.bootstrap.cache.loader.properties.${specific.cache.name}

Who is affected?

This affects anyone using the properties listed above.

How should I update my code?

There’s no direct replacement for the removed feature. If you have code that depends on it, you must implement it yourself.

Why was this change made?

This change was made to avoid security issues.

Removed liferay-frontend:cards-treeview Tag

What changed?

The liferay-frontend:cards-treeview tag was removed.

Who is affected?

This affects anyone using the tag from a jsp, or some of its components inside a SOY (Closure Templates) template.

How should I update my code?

There’s no direct replacement for the removed feature. If you have code that depends on it, you must implement it yourself.

Why was this change made?

This change was made because the tag was primarily used internally.

Removed liferay-frontend:contextual-sidebar Tag

What changed?

The liferay-frontend:contextual-sidebar tag was removed.

Who is affected?

This affects anyone using the tag from a jsp or some of its components inside a SOY (Closure Templates) template.

How should I update my code?

There’s no direct replacement for the removed feature. If you have code that depends on it, you must implement it yourself.

Why was this change made?

This change was made because the tag was primarily used internally.

Removed Add Action methods in Portal Vulcan API

What changed?

The addAction methods with signatures String, Class, GroupedModel, String, UriInfo and String, Class, Long, String, String, Long, UriInfo were removed.

Who is affected?

This affects anyone using the removed addAction methods or anyone that has dependencies like compileOnly group: "com.liferay", name: "com.liferay.portal.vulcan.api", version: "[1.0.0, 2.0.0)".

How should I update my code?

Use addAction methods with the signature String, Class, GroupedModel, String, Object, UriInfo or String, Class, Long, String, String, Object, Long, UriInfo.

Why was this change made?

These methods were removed as part of a cleanup refactor.

Changed Control Menu and Product Menu Positioning

What changed?

The placement and structure of the Control and Product Menus has changed to address several accessibility concerns and common visual glitches.

These changes have been applied to the Control and Product menus:

  • The Product Menu has been moved outside of the Control Menu
  • The Control Menu now uses position:sticky to control its behavior
  • Styles of the menus inside the Control Menu have been updated to account for the new sticky behavior

Who is affected?

This could affect developers that have a custom Control Panel Theme with a customized portlet.ftl template or those that have developed a custom menu that behaves as a sticky bar and is included using the *ControlMenuEntry API.

How should I update my code?

Control Panel Themes

Developers with custom Control Panel themes should move the call (if any) to the @liferay.control_menu macro above the portlet section in their portlet.ftl.

Before:

<section class="portlet" id="portlet_${htmlUtil.escapeAttribute(portletDisplay.getId())}">
	${portletDisplay.writeContent(writer)}
</section>

<#if portletDisplay.isStateMax()>
	<@liferay.control_menu />
</#if>

After:

<#if portletDisplay.isStateMax()>
	<@liferay.control_menu />
</#if>

<section class="portlet" id="portlet_${htmlUtil.escapeAttribute(portletDisplay.getId())}">
	${portletDisplay.writeContent(writer)}
</section>
Custom Sticky Bars

Developers with custom Sticky Bars included using the *ControlMenuEntry API can use the newly included extension points in the Control Menu to inject their components.

Move the code that injects the menu to a DynamicInclude component and register it for the proper position:

  • Before the Control Menu: Use com.liferay.product.navigation.taglib#/page.jsp#pre
  • After the Control Menu: Use com.liferay.product.navigation.taglib#/page.jsp#post

Why was this change made?

This change was made to improve accessibility and simplify the required logic for positioning and controlling top-positioned menus. It provides a more correct and expected markup that avoids common visual glitches.

jQuery Is No Longer Included by Default

What changed?

Previously, jQuery was being included on every page by default and made available through the global window.$ and the scoped AUI.$ variables. After this change, jQuery is no longer included by default and those variables are undefined.

Who is affected?

This affects any developer who used AUI.$ or window.$ in their custom scripts.

How should I update my code?

Use any of the strategies to add third party libraries to provide your own version of JQuery to use in your code.

Additionally, as a temporary measure, you can bring back the old behavior by setting the Enable jQuery property in System Settings → Third Party → jQuery to true.

Why was this change made?

This change was made to avoid bundling and serving additional library code on every page that was mostly unused and redundant.

Server-side Parallel Rendering Is No Longer Supported

What changed?

Properties with the prefix layout.parallel.render were removed, which means parallel rendering is only supported when AJAX rendering is enabled.

Who is affected?

This affects anyone using the removed properties.

How should I update my code?

Remove any properties prefixed with layout.parallel.render from your properties file.

Why was this change made?

This feature has been deprecated.

The ContentField value Property Name Was Changed to contentFieldValue

What changed?

In Headless Delivery API, the property name value inside the ContentField schema was changed to contentFieldValue.

Who is affected?

This affects REST clients depending in the ContentField value property name.

How should I update my code?

Change the property name to contentFieldValue in the REST client.

Why was this change made?

This change restores consistency with all value property names in the Headless APIs, called {schemaName}+Value.

Removed liferay-editor-image-uploader Plugin

What changed?

liferay-editor-image-uploader AUI plugin was removed. Its code was merged into addimages CKEditor plugin, used by Alloy Editor and CKEditor.

Who is affected

This affects custom solutions that use the plugin directly.

How should I update my code?

There’s no direct replacement for the liferay-editor-image-uploader plugin. If you have a component that relies on it, you can co-locate a copy of the old implementation and use it locally within your module.

Why was this change made?

This change enables image drag and drop handling in CKEditor and provides a common image uploader for both Alloy Editor and CKEditor.

TinyMCE Editor Is No Longer Bundled by Default

What changed?

As of 7.3, CKEditor is the default and only supported WYSIWYG editor.

Who is affected

This affects anyone who uses TinyMCE.

How should I update my code?

If you’ve configured Liferay Portal to use the TinyMCE, you can remove these configurations. If you still want to use TinyMCE, you must take these steps:

  • Keep your configurations.
  • Open https://repository.liferay.com/nexus/index.html in your browser.
  • Search for com.liferay.frontend.editor.tinymce.web.
  • Download a .jar file for the com.liferay.frontend.editor.tinymce.web module.
  • Deploy the .jar file you downloaded in your liferay-portal instalation.

Why was this change made?

This change was made to consolidate all our UX for writing Rich Text Content around a single Editor to provide a more cohesive and comprehensive experience.

Simple Editor Is No Longer Bundled by Default

What changed?

As of 7.3, CKEditor is the default and only supported WYSIWYG editor.

Who is affected

This affects anyone who uses the Liferay Frontend Editor Simple Web module.

How should I update my code?

If you’ve configured Liferay Portal to use the Simple Editor, you can remove these configurations. If you still want to use the Simple Editor, you must take these steps:

  • Keep your configurations.
  • Open https://repository.liferay.com/nexus/index.html in your browser.
  • Search for com.liferay.frontend.editor.simple.web.
  • Download a .jar file for the com.liferay.frontend.editor.simple.web module.
  • Deploy the .jar file you downloaded in your liferay-portal installation.

Why was this change made?

This change was made to consolidate all our UX for writing Rich Text Content around a single Editor to provide a more cohesive and comprehensive experience.

asset.vocabulary.default Now Holds a Language Key

What changed?

asset.vocabulary.default is now a language key and no longer has a fixed value of Topic.

Who is affected

This affects anyone who overwrites the property.

How should I update my code?

There is no need to change the code if the property is not overwritten. If the property was overwritten and the specified key is not found, the provided text will be taken as the name of the default vocabulary.

Why was this change made?

The change was made so users don’t have to change the name for the default vocabulary in all languages.

Liferay.Poller Is No Longer Initialized by Default

What changed?

The global AUI Liferay.Poller utility is now deprecated and is no longer initialized by default.

Who is affected?

This affects any code that relies on Liferay.Poller; this is usually done via a call to Liferay.Poller.init() in a JSP.

How should I update my code?

There’s no direct replacement for the Liferay.Poller utility. If you must initialize Liferay.Poller, update your JSP to use the code below:

<%@ page import="com.liferay.petra.encryptor.Encryptor" %>

<%-- For access to `company` and `themeDisplay`. --%>
<liferay-theme:defineObjects>

<aui:script use="liferay-poller">
	<c:if test="<%= themeDisplay.isSignedIn() %>">
		Liferay.Poller.init({
			encryptedUserId:
				'<%= Encryptor.encrypt(company.getKeyObj(), String.valueOf(themeDisplay.getUserId())) %>',
		});
	</c:if>
</aui:script>

Why was this change made?

The Liferay.Poller component was only used in the Chat application, which is archived. Skipping initialization by default streamlines page loads for the common case.

ContentTransformerListener Is Disabled By Default

What changed?

ContentTransformerListener is now disabled by default.

Who is affected?

This affects Liferay Portal installations using legacy web content features provided by the ContentTransformerListener, such as embedding web content inside another web content, a legacy edit in place infrastructure, token replacements (3190049, @articleId;elementName@), etc.

How should I update my code?

There’s no need to update your code. If you still want to use ContentTransformerListener, you can enable it in System Settings via the Enable ContentTransformerListener property under Content & Data → Web Content → Virtual Instance Scope → Web Content.

Why was this change made?

ContentTransformerListener was disabled to improve performance, due to its expensive string processing on article elements (calling HtmlUtil.stripComments and HtmlUtil.stripHtml on article fields).

Liferay.BrowserSelectors.run Is No Longer Called

What changed?

The Liferay.BrowserSelectors.run() function is no longer called on pages, which as a result removes some CSS classes from the opening <html> tag. Many of these are now added to the <body> element instead.

Who is affected?

This affects any code that relies on these CSS classes in the <html> element:

  • aol
  • camino
  • edgeHTML or edge
  • firefox
  • flock
  • gecko
  • icab
  • ie, ie6, ie7, ie9, or ie11
  • js
  • konqueror
  • mac
  • mozilla
  • netscape
  • opera
  • presto
  • safari
  • secure
  • touch
  • trident
  • webkit
  • win

How should I update my code?

There’s no direct replacement for the Liferay.BrowserSelectors.run() function, but you can adapt your CSS and JavaScript to target new classes on the <body> element instead. These classes are added to the <body> element to reflect the browser you’re currently using:

  • chrome
  • edge
  • firefox
  • ie
  • mobile
  • other

Alternatively, you can still invoke Liferay.BrowserSelectors.run() to apply the old classes to the <html> element with the code below:

<aui:script use="liferay-browser-selectors">
	Liferay.BrowserSelectors.run();
</aui:script>

Why was this change made?

The classes, some of which referred to outdated browsers, were being added to the top <html> element via legacy JavaScript that depended on Alloy UI. This change, which removes the outdated browser references, is now done on the server side, improving page loading times.

Remove Support for Blocking Cache

What changed?

Blocking cache support was removed. These properties can no longer be used to enable blocking cache:

  • ehcache.blocking.cache.allowed
  • permissions.object.blocking.cache
  • value.object.entity.blocking.cache

Who is affected?

This affects anyone using the properties listed above.

How should I update my code?

There’s no direct replacement for the removed feature. If you have code that depends on it, you must implement it yourself.

Why was this change made?

This change was made to improve performance because blocking caches should never be enabled.

Remove Support for Setting Cache Properties for Each Entity Model

What changed?

Support was removed for setting these cache properties for an entity:

  • value.object.entity.cache.enabled*
  • value.object.finder.cache.enabled*
  • value.object.column.bitmask.enabled*

For example, these properties are for entity com.liferay.portal.kernel.model.User:

  • value.object.entity.cache.enabled.com.liferay.portal.kernel.model.User
  • value.object.finder.cache.enabled.com.liferay.portal.kernel.model.User
  • value.object.column.bitmask.enabled.com.liferay.portal.kernel.model.User

Who is affected?

This affects anyone using the properties listed above for an entity.

How should I update my code?

There’s no direct replacement for the removed feature. You must remove these properties from your entities.

Why was this change made?

This change was made because these properties are not useful for an entity.

Renamed Portal Properties “module.framework.properties.felix.fileinstall.*” to “module.framework.properties.file.install.*”

What changed?

Portal properties beginning with “module.framework.properties.felix.fileinstall” have been renamed to begin with “module.framework.properties.file.install”.

Who is affected?

This affects anyone who has overridden module.framework.properties.felix.fileinstall.* portal property settings.

How should I update my code?

Rename properties starting with module.framework.properties.felix.fileinstall.* to start with module.framework.properties.file.install.*

Why was this change made?

This change was made to reflect the inlining of Apache Felix File Install. Liferay is now managing and maintaining this functionality.

Dynamic Data Mapping fields in Elasticsearch have changed to a nested document

What changed?

Dynamic Data Mapping fields in Elasticsearch that start with ddm__keyword__ and ddm__text__ have been moved to a new nested document ddmFieldArray.

The ddmFieldArray has several entries with following fields:

  • ddmFieldName: Contains the Dynamic Data Mapping structure field name. This name is generated using DDMIndexer.encodeName methods.
  • ddmFieldValue*: Contains the indexed data. The name of this field is generated using DDMIndexer.getValueFieldName and depends on the field’s data type and language.
  • ddmValueFieldName: Contains the index field name where the indexed data is stored.

This change is not applied if you are using the Solr search engine.

Who is affected?

This affects anyone with custom developments that execute queries in the Elasticsearch index using ddm__keyword__* and ddm__text__* fields.

How should I update my code?

You have to use the new nested document ddmFieldArray in your Elasticsearch queries.

There are some examples in Liferay code. For example, DDMIndexerImpl and AssetHelperImpl use the DDM_FIELD_ARRAY constant.

You can also restore the legacy behavior from System Settings and continue using ddm__keyword__* and ddm__text__* fields.

  1. Go to System Settings → Dynamic Data Mapping → Dynamic Data Mapping Indexer.
  2. Select Enable Legacy Dynamic Data Mapping Index Fields.
  3. Execute a full reindex.

Why was this change made?

This change was made to avoid the Limit of total fields has been exceeded Elasticsearch error that occurs if you have too many Dynamic Data Mapping structures.

Moving Lexicon icons path

What changed?

The path for the Lexicon icons has been changed from themeDisplay.getPathThemeImages() + "/lexicon/icons.svg to themeDisplay.getPathThemeImages() + "/clay/icons.svg

Who is affected

This affects custom solutions that use the Lexicon icons path directly. The Gradle task for building the icons on the lexicon path will be removed.

How should I update my code?

Update the path to reference clay instead of lexicon

Why was this change made?

This change was made to unify references to the icon sprite map.

What changed?

The countByClassNameId, findByClassNameId, and removeByClassNameId methods were removed from the following classes:

  • com.liferay.dynamic.data.mapping.service.persistence.DDMStructureLinkPersistence
  • com.liferay.dynamic.data.mapping.service.persistence.DDMStructureLinkUtil
  • com.liferay.dynamic.data.mapping.service.persistence.DDMStructurePersistence
  • com.liferay.dynamic.data.mapping.service.persistence.DDMStructureUtil
  • com.liferay.dynamic.data.mapping.service.persistence.DDMTemplateLinkPersistence
  • com.liferay.dynamic.data.mapping.service.persistence.DDMTemplateLinkUtil

Who is affected

This affects anyone who uses any of these methods.

How should I update my code?

You can use the other finder and counter methods.

Why was this change made?

These methods were removed as part of the solution for LPS-108525.

Removed com.liferay.dynamic.data.mapping.util.BaseDDMDisplay Method

What changed?

The isShowAddStructureButton method was removed.

Who is affected

This affects anyone who uses this method.

How should I update my code?

You can use isShowAddButton(Group scopeGroup) method instead of this method.

Why was this change made?

This method was removed as part of a clean up refactor.

Replaced portal properties: view.count.enabled and buffered.increment.enabled

What changed?

Enabling and disabling view counts globally and specifically for entities has been removed from portal properties and is now configured as system settings. View counts can be configured in the UI at System Settings → Infrastructure → View Count or using a configuration file named com.liferay.view.count.configuration.ViewCountConfiguration.config.

Here are the portal property changes:

The buffered.increment.enabled portal property has been removed. Enabling and disabling view counts globally is now done using the enabled property on the View Count page.

Disabling view count behavior for a specific entity is no longer done in portal properties, for example, by setting view.count.enabled[SomeEntity]=false in 7.3 or buffered.increment.enabled[SomeEntity]=false in 7.2, but is now done by adding the entity class name to the Disabled Class Name value list on the View Count page.

Who is affected?

This affects anyone who has the portal property setting view.count.enabled=false or buffered.increment.enabled=false.

This affects anyone who has disabled view counts for some entity (e.g., SomeEntity) using portal property settings view.count.enabled[SomeEntity]=false in early 7.3 versions or buffered.increment.enabled[SomeEntity]=false in 7.2 portal.

How should I update my code?

Remove view.count.enabled or buffered.increment.enabled portal properties and entity-specific properties such as view.count.enabled[SomeEntity]=false or buffered.increment.enabled[SomeEntity]=false.

Configure view count behavior in System Settings or using a configuration file:

In System Settings → Infrastructure → View Count, set enabled to false to disable view counts globally, or set enabled to true to enable view counts globally and disable view counts for specific entities by adding the entity class names to the Disabled Class Name value list.

To use a configuration file, configure view counts in System Settings, save the settings, and export them to a com.liferay.view.count.configuration.ViewCountConfiguration.config file. Then deploy the configuration by placing the file in your [Liferay Home]/osgi/configs folder.

Why was this change made?

This change was made to facilitate managing view count behavior.

Removed Portal Property “module.framework.properties.file.install.optionalImportRefreshScope”

What changed?

Portal property module.framework.properties.file.install.optionalImportRefreshScope has been removed. File Install will now only checks managed bundles when scanning for bundles with optional packages that need to be refreshed.

Who is affected?

This affects anyone who has the portal property settings module.framework.properties.file.install.optionalImportRefreshScope.

How should I update my code?

Remove property module.framework.properties.file.install.optionalImportRefreshScope. File Install cannot be configured to use other behavior.

Why was this change made?

There are very few cases where alternate behavior was desirable. File Install is the primary way bundles are installed into Liferay, so it is now the bundle management default. Removing the old feature and its branching logic improves code maintainability and readability.

Capability:
Development and Tooling
Deployment Approach:
Liferay PaaS
Liferay SaaS
Liferay Self-Hosted
Feature:
Reference