For a maintained portlet, the useful result is an editor whose initial content, changed value, and saved record agree. A toolbar appearing on the page establishes only one part of that result.
Inventory the old tag's responsibilities
Find the JSP containing liferay-ui:input-editor and note the installed Liferay release. Record the tag's name, initial-content expression, editor selection, callbacks, and the code that submits its value. Work in a development copy of the portlet.
Two deprecated attributes deserve explicit attention:
| Legacy attribute | Documented replacement | What to inspect |
|---|---|---|
editorImpl |
editorName |
Which editor implementation the installation provides |
initMethod |
contents |
Where the initial value comes from |
The old initMethod names initialization behavior; contents supplies initial content. Do not copy the old function's name into contents and expect the function to run. Inspect what it returned and preserve the appropriate data expression instead.
Migrate against the replacement tag's own contract
Liferay's support article recommends the replacement editor tag for the deprecated input-editor. Consult the tag library supplied with your installed release for its declaration and supported attributes. A reference for the legacy tag does not establish that every old attribute has the same type or behavior on the new tag. Liferay migration guidance
Keep these three pieces distinct during the edit:
JSP editor tag
-> rendered editor instance
-> value submitted by the portlet form
-> field stored by the application's save action
Changing the tag can affect instance lookup or submission code. Inspect the actual rendered instance and request names, including the portlet namespace your application uses. Avoid substituting a hard-coded page ID from a different portlet or copying a JavaScript call whose editor API belongs to another implementation.
Follow one content change through save and reopen
Use a small fictional equipment notice in a development record:
<p>Return the projector to the media desk on Thursday.</p>
Open the portlet and confirm that Thursday appears once in the editor. Change it to Friday. Submit using the portlet's real save action, inspect the value received by that action, then reopen the record. The reopened editor and the rendered notice should both show Friday.
If the editor shows Friday but the action receives Thursday or an empty string, examine the value-transfer code and request parameter name. If the action receives Friday but reopening shows Thursday, examine persistence and retrieval. Adding toolbar buttons will not resolve either observation.
Keep source editing separate from content permission
The legacy reference describes showSource as enabling HTML source editing. It does not promise arbitrary markup retention or safe rendering for every submitted value. Keep the application's existing validation and output rules while migrating the UI.
If the chosen implementation is CKEditor 5 and specific markup disappears during its model conversion, the CKEditor source-editing guide addresses that separate behavior. First identify the implementation actually running in Liferay; the replacement tag's name alone does not prove an editor version.
Finish with one saved notice reopened under the intended portlet and language. Keep the migration record with the JSP and save-action changes so another developer can trace the editor value all the way to storage.