dot-ui-vtl-migration

Migrates dotCMS VTL custom field templates from Dojo/Dijit APIs to DotCustomFieldApi.

950|482|Updated Mar 15, 2012
One-click install
npx skills add https://github.com/dotCMS/core --skill dot-ui-vtl-migration
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dot-ui-vtl-migration
Source: https://github.com/dotCMS/core/tree/main/.claude/skills/dot-ui-vtl-migration
Command: npx skills add https://github.com/dotCMS/core --skill dot-ui-vtl-migration

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Legacy dotCMS custom field templates rely on deprecated Dojo/Dijit APIs and old DotCustomFieldApi short forms that break or behave inconsistently in the modern edit mode. This Skill converts those VTL templates to the modern DotCustomFieldApi with DaisyUI styling while preserving all business logic and server-side Velocity variables.

Core Features & Use Cases

  • API Migration: Replaces DotCustomFieldApi.get/set/onChangeField, dojo.ready, dojo.byId, and dijit.byId with the modern getField()-based API including show/hide, enable/disable, and validation state handling.
  • Three-File Output Pattern: Produces an unchanged _old.vtl fallback, a fully migrated _new.vtl, and a conditional router file that delegates based on $structures.isNewEditModeEnabled() so legacy and new editors coexist safely.
  • DaisyUI Styling: Converts dijit widgets and dojoType attributes into semantic HTML with DaisyUI component classes (btn, input, select, modal) and Tailwind utilities.
  • Use Case: A developer pastes a legacy VTL custom field containing dijit.form.TextBox widgets and dojo.ready() callbacks and receives three production-ready files that work in both the legacy Dojo editor and the new Angular-based edit mode.

Quick Start

Migrate this VTL custom field template to the modern DotCustomFieldApi and generate the old, new, and router files for it.

Frequently Asked Questions about dot-ui-vtl-migration

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

FAQPage Schema
How do I migrate a dotCMS VTL custom field from Dojo to DotCustomFieldApi?

Replace DotCustomFieldApi.get/set/onChangeField with getField().getValue()/setValue()/onChange(), wrap all field access in DotCustomFieldApi.ready(), and remove dojo and dijit references. The migration outputs three files: an unchanged _old.vtl, a migrated _new.vtl, and a router file.

What replaces dojoType and dijit widgets in dotCMS custom fields?

dojoType attributes are removed and replaced with semantic HTML plus DaisyUI component classes. For example, dijit.form.TextBox becomes an input with class input input-bordered, and dijit.Dialog becomes a native dialog element with DaisyUI modal classes.

Does the migrated VTL template still work in the legacy dotCMS editor?

Yes, through the three-file output pattern. The router file uses $structures.isNewEditModeEnabled() to parse either the _new.vtl for the modern editor or the unchanged _old.vtl for the legacy Dojo editor, so both modes coexist safely.

Why should I not use DaisyUI input-error classes in legacy iframe templates?

The legacy iframe page legacy-custom-field.jsp does not load DaisyUI or Tailwind, so input-error produces no visual feedback. Ship a self-contained is-invalid style block inside the template and gate error display on state.touched to avoid flashing red on first render.

Which Velocity variables must stay unchanged during VTL migration?

Server-side variables $inode, $identifier, $lang, $contentlet, $structure, and $field must remain exactly as-is because they resolve on the server at render time. Only JavaScript API calls and styling change; business logic and VTL conditionals are preserved.