Publish go-to-market documentation for the new Edit Content mode

Description

Placeholder issue. This is a reminder that the new Edit Content mode needs go-to-market documentation before launch. The topic list below is the starting scope; the writing itself has not begun.

The new Edit Content mode ships without public documentation. We need a documentation set on the dotcms.com documentation site covering activation and the features that differ from the legacy editor, with screenshots and short videos where they earn their place.

Definition of done: the pages are live on the external documentation site at public URLs and linked from the relevant docs navigation. Written-but-unpublished does not close this issue.

Ownership: Falcon drafts the content and captures the screenshots/videos; the docs team reviews and publishes. This issue stays open until publication is confirmed.

Structure: one landing/activation document plus a page per topic, so each topic can be tracked and published independently.

Topics to cover

#	Topic	What it needs to answer
1	How to activate the new Edit mode	How an admin turns it on, globally and per content type
2	Custom Fields: how to migrate	What the recommended mode is, what the deprecated mode still does, and how to move a field from one to the other
3	Key/Value field	The copy-paste bulk-entry functionality
4	Site / Folder field	What it does and how it differs from the legacy field
5	Side Panels	Info, History, and Comments panels
6	Slide-in	What it is and when it appears
7	New Image Editor	The editing capabilities and how to reach them

Technical anchors for the writers

Concrete names the docs should use, pulled from the code so the documentation matches what admins actually configure:

Activation (topic 1) — core-web/libs/dotcms-models/src/lib/shared-models.ts, FeaturedFlags:

Flag	Purpose
CONTENT_EDITOR2_ENABLED	Turns the new editor on
CONTENT_EDITOR2_CONTENT_TYPE	Limits it to specific content types
CONTENT_EDITOR2_RENDER_MODE_DEFAULT	Default custom-field render mode
FEATURE_FLAG_EDIT_CONTENT_SIDE_PANEL	Side panels (topic 5)

Per-content-type enablement is resolved in core-web/libs/data-access/src/lib/dot-contentlet-edit-url/dot-contentlet-edit-url.service.ts from the content type's metadata.

Custom field modes (topic 2) — the mode is set per field via the newRenderMode field variable (NEW_RENDER_MODE_VARIABLE_KEY), resolved in dot-edit-content-custom-field.component.ts:

newRenderMode value	Rendering	Status
iframe (default when unset)	Legacy VTL template in an iframe, via the FormBridge API	Deprecated
component	Modern web component rendered directly in the DOM	Recommended

Because the default is iframe, an unmigrated custom field keeps working — the docs should say so explicitly, and cover the DotCustomFieldApi replacement for the legacy Dojo/Dijit API when explaining migration.

Acceptance Criteria

Content

• A landing/activation document exists covering how to enable the new Edit Content mode, globally and per content type, naming the actual flags admins set.
• A page exists for each of the 7 topics above.
• The Custom Fields page states which mode is recommended, which is deprecated, that the deprecated mode remains the default for existing fields, and how to migrate a field to the recommended mode.
• Each page includes screenshots or a short video where it makes the feature clearer — discretionary per topic, not mandatory.
• Images and videos are captured from a current build, not from pre-release mockups.
• Feature and configuration names in the docs match what ships (flags, field-variable keys, panel names).

Publication

• All pages are live on the dotcms.com documentation site at public URLs.
• The pages are reachable from the docs navigation — not orphaned pages only reachable by direct link.
• The landing document links to all 7 topic pages, and each topic page links back.
• The public URLs are posted in a comment on this issue so publication is verifiable.

Handoff

• The drafted content has been handed to the docs team for review and publication.
• Technical review has confirmed the content is accurate against the shipping build.

Priority

Medium

Additional Context

Resolved during refinement:

Question	Decision
Where does it get published?	The dotcms.com documentation site
One doc or several?	A landing doc plus a page per topic
Who does the work?	Falcon drafts; the docs team publishes — issue closes on confirmed publication
Project Technology field	Go-To-Market (launch deliverable, not front-end code work)

Related issues in the same area — worth reading before documenting the affected fields, since the UI may still change:

• #37464 — field hint and required-error presentation
• #37465 — Date/Time field width, clearing, and picker footer

Not yet decided (fill in when the work starts): the release the documentation must land with, the docs-team owner, and whether a launch/blog post accompanies the reference pages.

Out of scope: documentation for the legacy Edit Contentlet screen; internal engineering docs (those live in docs/ in this repo); release notes.

Start with the topic list and the technical anchors in core-web/libs/dotcms-models/src/lib/shared-models.ts, dot-contentlet-edit-url.service.ts, and dot-edit-content-custom-field.component.ts. Draft the activation landing page and seven topic pages, then hand them to the docs team. Done means all pages are live on dotcms.com, linked in navigation and to each other, with public URLs posted in a comment.