Starter: put Content Drive on top of the Content tab, drop Content Search and Site Browser

Description

Content Drive is the replacement for both Content Search and Site Browser, but on a fresh install it is buried at the bottom of the Content tab while Content Search sits on top, and Site Browser is still present under the Site tab. New users land on the legacy portlets first.

Change the starter navigation so Content Drive takes the top slot under Content, and the two portlets it replaces are dropped from the default menus.

The rest of each tab keeps its current relative order.

Where the data lives

Starter layouts are exported as JSON inside the starter zip:

• com.dotmarketing.business.Layout_*.json — the tabs. Content is 71b8a1ca-37b6-4b6e-a43b-c7482f28db6c, Site Editor is 931f0b26-92c1-420b-8fbf-e48089040921.
• com.dotmarketing.business.PortletsLayouts_*.json — {id, portletId, layoutId, portletOrder}, one row per portlet in a tab. This is the file that changes.

In the empty starter snapshot at starter/empty_20260211.zip, Content holds content at order 1 and content-drive at order 2; Site Editor holds site-browser at order 1. The full (demo) starter has more portlets per tab, but the same shape.

Portlet ids, for the avoidance of doubt (dotCMS/src/main/webapp/WEB-INF/portlet.xml): content is Contents Manager, site-browser is CMS Browser.

How the change ships

Starters are not built from this repo. .github/workflows/cicd_manual_publish-starter.yml downloads each type from an external URL and publishes it as a Maven artifact; parent/pom.xml:96 pins <starter.deploy.version> (currently empty_20260331) and dotCMS/pom.xml:1702-1711 consumes it. So the sequence is:

1. Update the layouts in the source instance for each starter type: empty, min, and full (demo).
2. Republish each via the manual starter workflow.
3. Bump <starter.deploy.version> in parent/pom.xml (the workflow opens a branch and seds this at :187).

Scope

• New installs only. Existing installs keep their menus, because their layouts already live in the database. No upgrade task, no data migration.
• The portlets stay registered. Only the default layout rows are removed. content and site-browser remain in portlet.xml, so an admin can re-add either to any role via Roles & Tools, and direct URLs keep working.

Acceptance Criteria

Content tab

• On a fresh install from each starter, Content Drive is the first entry under the Content tab
• Content Search (content) does not appear under the Content tab
• The remaining entries under Content keep their existing relative order, with no gap or duplicate in portletOrder

Site tab

• Browser (site-browser) does not appear under the Site tab
• The remaining entries under Site keep their existing relative order

All three starters

• The change is applied to the empty, min and full (demo) starters, verified by installing each
• <starter.deploy.version> in parent/pom.xml is bumped to the republished version, and a build using it comes up with the new menus

Nothing else moves

• content and site-browser remain registered in portlet.xml and can still be added to a role manually via Roles & Tools
• Navigating directly to either portlet's URL still works for a user whose role grants it
• Upgrading an existing install does not change its menus
• No other tab (Site Editor aside), role, or layout is altered by the starter change

Verification

• Verified against a running instance for each starter type, not by reading the exported JSON alone

Priority

Medium

Additional Context

Key paths

Note: the newest zip committed under starter/ is empty_20260211, while the pom pins empty_20260331 — the in-repo zips are snapshots and are not what the build consumes. Don't edit them expecting the build to pick it up.

Open question for whoever picks this up: whether the Site tab should also gain Content Drive once Browser is gone, or whether Content Drive under the Content tab is enough. The request as filed only removes Browser.