53 lines
6.5 KiB
Markdown
53 lines
6.5 KiB
Markdown
# Bundle 1 course correction: simple site content CMS
|
||
|
||
Decision recorded 2026-09-27. The owner rejected the draft/publish/revision workflow and custom content admin screens. This plan supersedes the CMS workflow and API portions of the approved Bundle 0 contract and the pending Checkpoint D review. Checkpoint C remains an accurate record of what was reviewed then, but its revision-based schema is no longer the target design. The approved Home/About visual direction and the content ownership inventory remain useful.
|
||
|
||
## Agreed behavior
|
||
|
||
- The CMS edits the shared site identity and the four fixed public pages: Home, About, Events listing, and Blog listing. Event and blog detail records remain in their existing systems.
|
||
- A superuser, or an active staff user with the standard Django `change` permission for the relevant content model, edits the record in Django admin. There are no content-specific editor/publisher roles, drafts, publication flags, preview endpoints, revision snapshots, or custom restore action.
|
||
- Saving a valid record makes its text, images, and SEO available to the public site on the next request. The frontend must not retain a stale page cache after an admin save; verify the actual deployed cache behavior before cutover.
|
||
- Each fixed page has one editable record with named fields that match the approved layout. Editors do not create pages, edit slugs, manipulate section types/order/visibility, or edit raw JSON. A record's SEO title, description, and social image are editable; canonical routes and structured-data shape stay in code. Shared site identity supplies defaults.
|
||
- Admin forms use the project's installed Unfold `ModelAdmin`, native fieldsets and supported widgets, matching the existing Blog Category form. No handwritten content admin CSS or custom dashboard/form templates.
|
||
- Keep useful plain-text, URL, image-signature, size, dimension, and alt-text validation. Use direct image upload fields where practical. Remove media approval and immutability rules that existed only for publication.
|
||
|
||
## Work sequence and review gates
|
||
|
||
### 1. Migration and permissions audit
|
||
|
||
Inspect each target environment for applied `content` migrations, existing content/media rows, and assignments to the content-specific permissions or groups. Record the result before changing schema. Preserve real content and images; map any existing public revision to the new current record. If no published revision exists, do not expose an unreviewed draft automatically. Add forward migrations for shared or applied migration history; do not silently rewrite committed migrations. Translate any actual staff access to standard model permissions before retiring custom permissions. Keep other apps and their permissions untouched.
|
||
|
||
**Check:** migration works from a fresh database and a copy with the current content schema; existing real records and access are accounted for.
|
||
|
||
### 2. Replace the content model and admin
|
||
|
||
Create one fixed record per page and one shared site record, using explicit text, image/alt, and SEO fields for the approved design. Use ordinary Unfold change forms grouped into Content, Images, and SEO. Ensure the four records exist without presenting an arbitrary “Add editorial page” flow; disable deletion. Remove the draft/revision services, publication audit, custom content groups, and custom admin templates after data and permission migration. Django's normal admin history is sufficient for basic change history.
|
||
|
||
**Check:** a superuser and a staff user with the relevant `change` permission can save; a staff user without it cannot. Review the actual Home, About, Events, Blog, and site forms at phone and desktop widths against the supplied Blog Category example. Saving invalid text or media shows a field error in the Unfold form.
|
||
|
||
### 3. Serve current content
|
||
|
||
Expose only the small public read API needed by the frontend for shared site content and the four fixed pages. The implementation and response shapes are documented in the backend [content API v1 note](../../guilan-ace-backend/docs/content-api-v1.md). Responses contain current text, media URLs/alt text, and SEO fields. Remove revision IDs, status, draft preview, publish, and restore from the schema. Define empty-record behavior and cache handling so a successful admin save appears on the next public request.
|
||
|
||
**Check:** anonymous reads return current saved values; unknown pages and missing records have explicit responses; an admin save is visible through the API immediately. No draft or preview route exists.
|
||
|
||
### 4. Populate reviewed starting content
|
||
|
||
Use the existing content inventory to prepare the four fixed records and site identity. Review disputed claims, contacts, and media rights before they become public. Import approved values once without overwriting subsequent admin edits. A small repeatable initialization/data migration is preferable to a general-purpose seed workflow; a dry run is only needed if the environment audit reveals existing data that could be overwritten.
|
||
|
||
**Check:** compare each imported value and image with its approved source; a second initialization leaves edited records unchanged.
|
||
|
||
### 5. Connect the frontend and verify SEO
|
||
|
||
Keep the frontend feature flag defaulting to legacy content until the new records are complete and checked. Read the fixed page records server-side, populate the approved Home/About layout and Events/Blog listing copy, and use CMS SEO values in rendered HTML and social metadata. Existing event/blog detail APIs and dynamic content stay in place. Remove frontend preview/publish assumptions from later redesign tasks.
|
||
|
||
**Check:** editing a heading, image, and SEO title in Unfold changes the public page and server-rendered metadata after Save, with no separate publication action. Verify at 390px and desktop, including Persian text and missing optional images.
|
||
|
||
### 6. Release gate
|
||
|
||
Rehearse migrations and media on a database copy, check backups, then enable the frontend flag after content and admin walkthrough approval. Keep flag rollback available. Verify public pages, metadata, permissions, and unaffected blog/event flows. Production changes require the existing release gate.
|
||
|
||
## Explicit removals from the old plan
|
||
|
||
Retire old T08–T11's draft/publish/restore/preview requirements and Checkpoint D's role review. Replace T12–T13's draft seed workflow with reviewed initial records. Update T14, T16–T18, T24, T30, and T38–T39 so their checks require direct-save content, not publication. The old review and contract files remain as historical evidence and are marked superseded, not presented as active instructions.
|