Member Avatar for James_43

Hi everyone,

Just after some general advice. I have developed a website that contains several news widgets that will eventually need updating. I am not too fussed about keeping a record of past news events, but that could be nice.

Basically my question is, what is the best way to content manage this? Because the writing of the news stories and website administration will be done by someone with little coding skills, I don't want them to be able to edit the HTML files even on a test platform.

I was thinking I could create a database and the news feeds just draw on that?

Cheers!

  • 4 Contributors
  • 4 Replies
  • 207 Views
  • 1 Week Discussion Span
  • Latest Post Latest Post by mlesniak

Dani AI

Generated

For the scenario described by , a practical, low-friction plan is to keep editable news content separate from the site templates and expose it through a small, controlled admin interface. That lets a non-technical editor add, preview, schedule and archive items without touching HTML. It also keeps the front-end widgets simple: they just request structured data and render it.

A minimal content model that covers common needs (title, body, publish scheduling, soft-archive and basic metadata) is often enough. Example schema (adapt to the chosen database):

CREATE TABLE news (
  id INTEGER PRIMARY KEY,
  title VARCHAR(255) NOT NULL,
  slug VARCHAR(255) UNIQUE NOT NULL,
  content TEXT NOT NULL,
  author VARCHAR(100),
  status VARCHAR(20) DEFAULT 'draft',    -- draft | published | archived
  publish_at TIMESTAMP NULL,
  expire_at TIMESTAMP NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE news_revision (
  rev_id INTEGER PRIMARY KEY,
  news_id INTEGER REFERENCES news(id),
  content TEXT NOT NULL,
  editor VARCHAR(100),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Implementation notes and trade-offs: accept Markdown plus a live preview for slightly technical editors, or a simple WYSIWYG for less technical ones (balance formatting freedom vs XSS risk). Keep media uploads restricted and scanned; sanitize stored HTML. Expose a tiny API endpoint (for example /api/news?limit=3) and cache the JSON response on publish to avoid DB hits from every page view. Provide soft-delete and an optional revisions table so history is cheap to add later. , and touched on related routes; the quickest path is a tiny admin + structured storage, with the option to swap in an off‑the‑shelf system later if needs grow.

Recommended Answers

All 4 Replies

Member Avatar for matrixdevuk

Markdown is usually a great option.
Here's an example of how it could look on the frontend:
Frontend

Member Avatar for DaveAmour

"I was thinking I could create a database and the news feeds just draw on that?" - That's typically how this kind of thing works. You can write this yourself or use an off the shelf package. These are called CMS systems which stands for Content Management System

Member Avatar for matrixdevuk

Whoops, read the question wrong. Ignore my answer. :P

I need to stop doing this.

Member Avatar for mlesniak

Having the content in a database is a good idea. You could have a separate application to allow the editor to submit new items. That application may, or may not be a web application. That way you can keep the application simple. MySQL and PHP are good for this purpose.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.