How a Newsroom CMS Works: One Story From Pitch to Published

The test of a publishing platform is whether an editor can change the front page at 6pm without filing a developer ticket.

Most newsroom software fails in the same two places. The layout is code, so every presentation decision becomes an engineering request. And edits are destructive, so a bad change made at speed is unrecoverable.

What follows is one story through a system where neither is true. Every step below is a capability described on the News Pro product page.

The draft

A reporter writes in the admin, in a category that already exists as a nested section with its own colour, and adds tags — which are created on first use rather than requested from an administrator in advance.

Every save stores the version it replaced, with a field-level diff. The last twenty-five versions are kept per article, so a paragraph removed on Tuesday is still readable on Friday.

The press photograph

The photographer sends a 4000×3000 file straight off the camera. It is capped, resized into four sizes, re-encoded to WebP and given a thumbnail on upload — automatically, with nothing for an editor to remember.

The reader is never served the original. That is the single most common cause of a slow news site, and it is handled at the point of upload rather than left to discipline.

The edit, and the edit that goes wrong

A sub-editor tightens the intro and, in doing so, cuts a line that mattered. Restoring the earlier version is one action — and the restore is itself a save, so the text it replaced also goes into history. There is no one-way door.

Every admin action is logged with the account, the IP address and the exact fields that moved. When someone asks who changed the headline after publication, the answer is a record rather than a recollection.

Publication, at the right moment

The story is scheduled rather than published by someone sitting up until midnight. Scheduled publishing runs as a single command on the server, alongside verified backups, image processing and storage reclaim.

The front page, at 6pm, without a developer

The news desk decides Trending should sit above Editor's Picks. On most platforms that is a ticket. Here the homepage is built from data rather than code: the feed column and the right rail can be reordered, retitled, hidden or removed, and widgets know which column they are allowed to occupy.

A widget that resolves to nothing is dropped rather than left as an empty heading, so an editor cannot accidentally publish a blank box. Navigation, nesting, icons and order are edited the same way.

What the reader gets

An infinite feed sorted by latest, popular or most discussed, filtered by news, video or gallery. On the article itself: reading progress, auto-generated contents, related-by-tag, previous and next, and an author box.

Readers with accounts keep bookmarks, upvotes and follows, and history resumes an article where they left it. Personalisation draws topics from what someone actually read, topped up with trending so the feed is never empty. Light and dark are both first-class and the whole shell is keyboard navigable.

The comments, which are where trust is lost

Threaded replies go one level deep — deliberately, because deeper threads become unmoderatable. There is a moderation queue, per-user likes, and notifications when a reply lands.

Comments, media, pages, ads, users and roles are all editable in the admin across fourteen screens. Permissions are tickboxes rather than code, and the editor refuses a change that would leave nobody able to grant permissions again.

Advertising and identity

Three ad placements carry scheduled start and end dates, with impressions and clicks counted per ad. Site identity, socials and SEO defaults are settings, so rebranding is a form rather than a code edit.

None of this decides whether the journalism is any good. It decides whether the newsroom spends its afternoon on the story or on the software.