Product engineering
How to plan a useful first release
Choose one complete user task, define its boundaries and make acceptance examples part of the brief.
ExploreContent updates should not need a deployment
Keep editable content and uploaded files separate from application releases, and give editors a workflow that matches the website.
Separate three kinds of change
Code changes alter behaviour. Content changes alter what the site says. Uploads add files that editors or customers need to retain. Treating all three as one deployable folder risks overwriting work.
A CMS should store content in persistent storage and give uploads their own durable location. Backups must include the information that is not in the repository.
Design fields around real content
A service page needs a title, summary, sections and enquiry path. An article needs an author, category and publication details. A location resource needs accurate service coverage.
Putting everything into one unrestricted HTML field makes editing flexible at first but difficult to keep consistent. Structured fields and a limited set of useful layouts offer a better balance.
Publishing has consequences
Drafts
Let editors review unpublished material without exposing it publicly.
URL changes
Preserve useful old links with redirects and reject loops.
Revisions
Keep previous versions so a mistaken update can be recovered.
Images
Check where an asset is used before deleting it. An older revision may still need it.
Test the editor, not only the homepage
Create content, preview it, publish it, replace an image and restore a revision. Then restart the application and confirm the changes persist.
A successful page render does not prove the content-management workflow is complete.
Explore web development