A content team touches a lot of screens in a day. Publish a campaign. Fix a taxonomy. Find every page that mentions a product you just discontinued. That is three different screens before lunch.
Content platforms are long-lived. They pick up new screens as they gain capability, and each screen tends to reflect how interfaces were built at the time. Individually they are all reasonable. Together they can drift — a table that sorts one way here and another way there, a bulk action that exists on one screen and not the next.
That drift costs you in three quiet ways:
Re-orientation. Every time someone opens a screen they use once a month, they spend the first minute working out how it behaves.
Training. New team members get shown two or three screens and stay dependent on colleagues for the rest.
Key-person risk. One person learns a screen's quirks, and routine work waits for them to be free.
None of it shows up as a single delay you can point at, which is exactly why it rarely gets fixed.
It is also not just a new-user problem. Nielsen Norman Group ranks consistency fourth among its ten usability heuristics, and its research on complex applications makes the point that inconsistency confuses experienced users too — not only people learning the system. The learning curve gets re-climbed rather than climbed once.
The market is scoring this now, not just the feature list. The Forrester Wave: Content Management Systems, Q1 2025 assessed thirteen vendors across twenty-four criteria, including content generation and editing. How a platform feels to the people in it all day is part of the evaluation.
What we did
We are rebuilding the dotCMS admin on a single shared front-end foundation, one screen at a time. We are almost complete! This latest batch includes:
Tags
Categories
Publishing Queue
ES Search
Query Tool
Velocity Playground
Plugins
Six of them simply replace the screen you were already using — no migration, no configuration, just a more consistent look and feel. Publishing Queue is the exception, it is a redesign rather than a like-for-like rebuild. It ships in beta alongside your existing screen so your team can switch when it suits them. More on that below.
The screens your content team uses daily
Tags now pages, sorts and filters on the server, so it stays fast whether you have 200 tags or 20,000. A few things that save real time:
Page at 10, 25 or 50 rows
Selections survive paging, so a set you build across several pages can be acted on as one batch
Bulk delete asks for confirmation, then tells you exactly what succeeded
A global view for tags shared across every site
CSV export of either your selection or the full list
Categories got the change people ask for most: inline editing that sticks without a page reload. Change a sort order right in the row and it saves in the background. If the save fails, the old value comes back and you are told why. For a deep taxonomy, that removes the reload-and-find-your-place cycle after every single edit.
Also in Categories:
Click a row to move down the hierarchy, with a breadcrumb showing where you are
Variable names generated from the title when you create a category
Bulk delete that reports per item, so a partial failure names what failed and why
Both screens take a CSV by dragging the file onto the dialog, and Categories lets you choose merge or replace at import. Small things on their own. Together they shorten the bulk-maintenance work that eats a whole afternoon.
Publishing Queue: rethought, not ported
Publishing Queue is how content teams confirm their work actually reached production. It is also the screen where a mistake costs the most — a bundle sitting in a failed state that nobody noticed.
So we did not port it. We redesigned it around the question people actually open it to answer: what is the state of everything I have sent?
The answer is now one list. Every bundle appears in it — waiting, in flight, finished or failed — with a status chip on each row. dotCMS tracks eighteen distinct publishing states, and the screen sorts them into four colours you can read at a glance, so "is anything broken?" is a scan of one column rather than a hunt.
From there you can filter by status, search across bundles, click the item count on any row to see exactly what is inside, copy a bundle ID with one click, and use the row menu to view details, retry, generate a download or delete. Select several rows and retry or delete them as a batch.
A bundle, end to end
Build it. In your content, select what you want to move and choose Add to Bundle. The bundle is saved for later.
Send it. In Publishing Queue, choose Add Bundle → Select Bundle, pick your bundle and preview its contents. Configure & Send opens the same push dialog you already use elsewhere in dotCMS — push, remove or both, send now or schedule, choose the environment and filter — then send.
Watch it. The bundle appears in the list and its status chip moves as it is packaged and shipped, landing on success or failure. Failed bundles retry automatically up to three times. If one still fails, retry it from the row menu, or open the bundle details to see exactly which environments it reached and which it did not.
The screens your developers and admins live in
ES Search and the Query Tool are how you find out what is actually in the repository. Both now run on the Monaco editor — the same editor behind VS Code — in a resizable split pane, query on one side, results on the other.
JSON syntax highlighting, and four result views in ES Search: results, aggregations, term suggestions, raw response
Curated query examples behind a help popover, copyable straight into the editor
Export any query you have run as a cURL command or a fetch call, so what you verified by hand goes into a script without retyping
Query state lives in the URL, so you can send a colleague a link instead of a description — and they get your exact result, not their best reconstruction of it
Velocity Playground highlights Velocity syntax as you type, keeps your last ten scripts in a history dropdown, remembers your split-pane ratio, and reports the response content type and execution time for every run.
Plugins changed the most in behavior. Installed OSGi bundles and undeployed JARs share one table, with state shown as a chip in a sortable column — so finding the bundle that did not start is a sort, not a scan. The row menu only offers actions that apply to that bundle's actual state. You can drag multiple JARs onto the page to upload them.
The bigger change: the table updates itself from platform events. It subscribes to framework and bundle-load notifications and refreshes when something actually changes, instead of polling on a timer. Deploy failures show up as errors instead of passing silently, and restarting the OSGi framework shows its own state, so you can tell "the platform is restarting" from "this page is stuck."
One foundation, so it stays consistent
All seven screens are built on Angular 22 with PrimeNG 21, themed with a customized Lara preset carrying the dotCMS palette.
The versions matter less than what they force. Every screen now pulls from the same component set, so consistency is a property of the system instead of a function of who built which screen and when. We are removing the thing that causes drift, not correcting the drift one screen at a time.
These rebuilds mostly reuse REST endpoints that already existed, which is why they can ship incrementally instead of as one large, risky release. Where the work turned up a genuine defect, we fixed it — rebuilding Tags surfaced a case where editing a tag under a delegated storage configuration could move it without telling you, and that fix shipped with the screen.
What it looks like in practice
A healthcare network is renaming a service line across a few dozen facility sites. The ops lead writes a Lucene query in the Query Tool to find everything carrying the old tag, then sends the query as a link so a colleague can confirm the same count independently. In Tags, they filter to that tag, export the affected set to CSV for the change record, and retag. In Categories, they walk the hierarchy by clicking rows and fix sort order inline as they reorganize. When the work publishes, they watch it clear in Publishing Queue.
Every one of those steps was possible before. What changed is how long it takes to go from deciding to do something to having done it — across screens that now work the same way.
Availability
All 7 tools have been rebuilt and are available in your (Evergreen) instance. The publishing queue tool will become the default in your instance shortly.
More are already built and others are in progress. If your team has a strong opinion about which remaining screen slows them down most, tell us. That feedback has shaped the order of this work more than anything else.
From dotCMS 2026 Product Webinar: Organize, Create, Edit, and Reuse Content Easily
FAQ
Get Content to Market Faster with Our New UX!
dotCMS has rebuilt seven admin screens (Tags, Categories, Publishing Queue, ES Search, Query Tool, Velocity Playground, and Plugins) on a single shared front-end foundation, replacing older screens that had drifted apart in look and behavior over time.
No. Six of the seven (Tags, Categories, ES Search, Query Tool, Velocity Playground, and Plugins) are drop-in replacements for the screens you already use. There's no migration and no configuration required.
No, Publishing Queue is the one exception. It was redesigned rather than rebuilt like-for-like, and it currently ships in beta alongside your existing Publishing Queue screen, so your team can switch to it whenever suits them.
Every bundle now appears in a single list, whether it's waiting, in flight, finished, or failed, with a status chip that sorts dotCMS's eighteen distinct publishing states into four colors you can scan at a glance. You can filter by status, search across bundles, view a bundle's contents, copy its ID, and retry or delete bundles individually or as a batch. Failed bundles retry automatically up to three times before you need to step in.
Tags now pages, sorts, and filters on the server, so it stays fast at any scale. You can set page size, keep selections across pages for batch actions, bulk delete with per-item confirmation, view tags shared across every site, and export selections or the full list to CSV.
The main change is inline editing that saves in the background without a page reload, including sort order changes directly in the row. You can also navigate the hierarchy by clicking into rows with a breadcrumb trail, get auto-generated variable names when creating a category, and bulk delete with per-item failure reporting. Both Tags and Categories accept CSV import by drag and drop, and Categories lets you choose merge or replace on import.
ES Search and the Query Tool now run on the Monaco editor (the same editor used in VS Code) in a resizable split pane, with JSON syntax highlighting, curated query examples, and the ability to export any query as a cURL command or fetch call. Query state lives in the URL, so a link reproduces the exact result for a colleague. Velocity Playground adds syntax highlighting, a ten-script history, and per-run response type and execution time. Plugins now shows installed and undeployed bundles in one sortable table that updates automatically from platform events instead of polling, and surfaces deploy failures instead of letting them pass silently.
All seven screens are built on Angular 22 with PrimeNG 21, themed with a customized Lara preset carrying the dotCMS palette. They mostly reuse REST endpoints that already existed, which is why they could ship incrementally rather than as one large release.
All seven rebuilt tools are available now in your Evergreen instance. Publishing Queue will become the default in your instance shortly.
Yes. Additional screens are already built or in progress, and the dotCMS team is prioritizing the rebuild order based on customer feedback about which remaining screens slow teams down the most.