liferay-widget-config-erc

Enforces storing externalReferenceCode instead of numeric IDs in Liferay portlet preferences.

Updated Jul 24, 2026
One-click install
npx skills add https://github.com/gweone/agent-plugins --skill liferay-widget-config-erc-gweone
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: liferay-widget-config-erc
Source: https://github.com/gweone/agent-plugins/tree/main/plugin/sharpps-liferay/skills/liferay-widget-config-erc
Command: npx skills add https://github.com/gweone/agent-plugins --skill liferay-widget-config-erc-gweone

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Liferay portlet preferences that store raw numeric primary keys (groupId, structureId, folderId) break silently after Site Initializer imports, Staging publishes, or LAR imports, because auto-incremented IDs differ across instances. This Skill provides the rule and proven fix recipes for storing externalReferenceCode (ERC) instead. ## Core Features & Use Cases - Design rule for widget configuration: Any portlet preference referencing another Liferay entity (site, DDM structure, file entry type, folder, object definition) must persist the ERC, resolving to the numeric ID only at the point of use. - Proven fix recipes: Documents the completed definitionIddefinitionERC migration (with a DefinitionResolver OSGi service and request-scoped caching) and the rootFolderIdrootFolderERC migration (with a bidirectional FolderResolver dispatching across DLFolder, JournalFolder, and KBFolder, plus ERC-based breadcrumb URL tokens). - Code review checklist: Flags known violations such as the still-unfixed subTypeId preference and explains why displayStyleGroupId follows Liferay's own key/ERC pattern and should not be blindly rewritten. - Use Case: When reviewing a *PortletPreferences class or a page-definition.json that configures search portlets, apply this Skill to detect raw-ID storage and follow the resolver-service pattern to make the configuration survive re-imports. ## Quick Start Review this portlet preference that stores a folder ID and refactor it to store and resolve an externalReferenceCode instead.

Frequently Asked Questions about liferay-widget-config-erc

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
Why do Liferay portlet preferences break after LAR import or staging?

Liferay primary keys like groupId, structureId, and folderId are auto-incremented per database, so the same entity gets a different ID after import or staging publish. Preferences storing raw IDs then reference nonexistent or wrong entities, often failing silently.

How do I make Liferay widget configuration portable across instances?

Store the entity's externalReferenceCode in the preference instead of its numeric ID, then resolve the ERC to the current instance's ID at the point of use via the entity's local service ERC fetch method. Never persist a resolved numeric ID back into configuration.

How do I resolve an externalReferenceCode to a DDMStructure ID in Liferay?

Use DDMStructureLocalService.fetchStructureByExternalReferenceCode with the ERC, groupId, and className. The documented pattern wraps this in an OSGi resolver service that caches results as HttpServletRequest attributes keyed by groupId, className, and ERC.

Does Liferay's item selector return externalReferenceCode for folders?

No, Liferay's stock folder item-selector popups only return raw numeric IDs. The configuration action must resolve that picked ID to its ERC once at save time using a bidirectional resolver before persisting the preference.

Should displayStyleGroupId be migrated to ERC like other preferences?

Not blindly. Liferay's Application Display Template picker already stores an ID alongside a key or ERC field such as displayStyleGroupKey. Verify by reading the actual lookup code whether it falls back to the key before applying the same fix.