8.4 KiB
Content Manager Removal & Refactor Plan
Purpose: Provide a safe, staged, reversible plan to remove the Content Manager UI and perform the requested content-manager refactor while preserving Writer pages and integrations. This file is a single-source plan for developers and QA.
Objectives
- Safely remove/hide the Content Manager dashboard UI and related code paths without breaking Writer flows: Tasks, Content (detail), Images, Published, Sites, Site integration, and WordPress sync.
- Implement requested UI changes (three buttons, metadata block, table column changes) behind a feature flag.
- Ensure background syncs, plugin webhooks, and publish adapters continue to function.
- Do not perform destructive DB schema removals during initial rollout; deprecate first, remove later after validations.
High-level Phases
- Preparation & discovery (completed)
- Feature-flag gating & compatibility proxies
- Frontend hide + UI refactor (non-destructive)
- Backend normalization & compatibility layer
- Staged cleanup & code removal
- Tests, rollout, monitoring, and rollback
Feature flag and admin control
- Add server-side feature flag
feature.content_manager_refactor(default OFF in production). - Add admin option
enable_content_manager_removal_modeto WP plugin and backend config for controlled toggles. - All major UI changes and route behavior changes must be gated behind the feature flag.
Per-file action plan (first sprint - non-destructive)
-
frontend/src/layout/AppSidebar.tsx
- Change Writer menu link default from
/writer/contentto/writer/tasks(behind flag).
- Change Writer menu link default from
-
frontend/src/config/routes.config.ts
- Ensure
/writerredirects to/writer/taskswhen flag enabled.
- Ensure
-
frontend/src/pages/Writer/Content.tsx
- Hide inline body toggle and modal behavior behind flag; ensure title click navigates to content detail.
-
frontend/src/components/common/ToggleTableRow.tsx
- Remove usage on Content list (do not delete component globally).
-
frontend/src/pages/Writer/ContentView.tsx (or ContentViewTemplate)
- Add metadata block (Cluster, Sector, Categories, Tags).
- Add three buttons with conditional visibility (Edit content, Generate images, Publish).
-
frontend/src/pages/Writer/Review.tsx
- Add Categories and Tags columns after Title; make Title clickable to open ContentView.
-
frontend/src/pages/Writer/Images.tsx
- Remove image prompt column; render image and status badge stacked.
-
frontend/src/config/pages/content.config.tsx and table-actions.config.tsx
- Add/adjust columns and action visibility rules to support the UI changes.
-
frontend/src/templates/TablePageTemplate.tsx
- Persist column selector state per-page using localStorage key
table-columns:${routePath}.
- Persist column selector state per-page using localStorage key
-
frontend/src/services/api.ts
- Keep
publishContent,unpublishContent,generateImagePrompts,fetchContentByIdunchanged; add wrappers only if needed for compatibility.
- Keep
-
backend/igny8_core/modules/writer/views.py
- Keep
ContentViewSetendpoints; ensurepublish()writesexternal_id&external_urland has robust validation.
- Keep
-
backend/igny8_core/business/integration/services/content_sync_service.py
- Normalize status usage (
publishednotpublish) and set canonicalcontent.external_idon successful publish.
- Normalize status usage (
-
backend/igny8_core/business/publishing/services/adapters/wordpress_adapter.py
- Confirm adapter returns
external_idandurlreliably and handles media errors gracefully.
- Confirm adapter returns
-
igny8-wp-integration/sync/igny8-to-wp.php
- Add fallback: if
task['content_id']is present, fetchGET /v1/writer/content/{content_id}/and usecontent_htmlfor post body; fallback to legacytask['content']if content fetch fails.
- Add fallback: if
-
igny8-wp-integration/includes/functions.php
- Ensure cron jobs and connection toggles can be disabled via admin option to stop sync during rollback.
UI Requirements & Exact Behavior
-
Content detail
/writer/content/:id(ContentView)- Metadata block (top-right or top section):
- Cluster: label + cluster name (link to cluster detail if clicked)
- Sector: label + value
- Categories and Tags: chips below Sector
- Buttons (top toolbar):
- Edit content
- Visible when
status∈ {draft,review}. - Action: navigate to PostEditor (use existing PostEditor route, pass
content_id).
- Visible when
- Generate images
- Visible when
status==draft. - Action: call
POST /v1/writer/content/{id}/generate_image_prompts/; show progress modal iftask_idreturned.
- Visible when
- Publish
- Visible when
status==review. - Action: call
POST /v1/writer/content/{id}/publish/; on success display toast withexternal_urland refresh.
- Visible when
- Edit content
- Metadata block (top-right or top section):
-
/writer/contentlist- Remove dropdown row-toggle that shows body.
- Clicking Title navigates to
/writer/content/{id}(no modal).
-
/writer/review- Table columns: [Select] [Title (clickable)] [Categories] [Tags] [Cluster] [Status] [Actions].
-
/writer/images- Remove 'image prompt' column.
- Image column shows: thumbnail (top) and status badge (below) as vertical stack in a single column.
-
Table column persistence
- Store selected columns per route in
localStoragekeytable-columns:${routePath}. - On mount, load and apply selection.
- Store selected columns per route in
Data flow & canonical fields (reference)
- Task (lightweight): id, title, cluster_id, content_type, content_structure, taxonomy_term_id, keywords (M2M), status (
queued|completed). - Content (canonical body): id, title, content_html, ai_raw/json (if present), content_type, content_structure, cluster_id, taxonomy_terms (M2M), source (
igny8|wordpress), status (draft|published), external_id, external_url. - WordPress: expect adapter to return
external_idandurl.
Backend normalization & compatibility
- Replace any uses of
status == 'publish'withstatus == 'published'(e.g., inContentSyncService). - Standardize storing WP post id in
content.external_id(not only incontent.metadata['wordpress_id']). - Keep old metadata keys supported for one release by copying
metadata['wordpress_id']→external_id(migration or compatibility write). - Plugin fallback: if webhook provides
task.content_id, plugin must fetch content detail forcontent_html.
Tests & verification
- Unit tests (backend)
ContentViewSet.publish()updatesexternal_id&external_urland content status.ContentSyncServicepicks uppublishedcontent and updatesexternal_id.
- Frontend unit tests
- ContentView button visibility by status.
- Review table shows categories/tags and clickable title.
- Integration/E2E tests
- End-to-end flow: Idea → Task → Generate content → verify Content saved → generate images → publish → WP post created →
content.external_idpresent.
- End-to-end flow: Idea → Task → Generate content → verify Content saved → generate images → publish → WP post created →
- Plugin webhook simulation
- Simulate
task_publishedwithcontent_idpresent; verify WP post has full body fromcontent_htmland metadata keys set.
- Simulate
Rollback & monitoring
- Quick rollback: flip
feature.content_manager_refactorOFF. - If publish failures spike: set WP plugin option
igny8_connection_enabled= 0 to stop cron and inbound sync. - Instrument logs for publish path and plugin webhook calls; monitor error rates, failed publishes, missing credentials.
Timeline & sprint breakdown (first sprint - non-destructive)
- Day 0.5: Feature flag & admin option + small plugin fallback change.
- Day 1–2: Frontend changes (hide old UI, implement ContentView metadata + buttons behind flag, review/images updates, column persistence).
- Day 0.5: Backend normalization:
ContentSyncServicestatus normalization andexternal_idwrites; confirmpublish()stable. - Day 1: Tests, staging deploy, integration E2E.
- Day 0.5: Staged canary release and monitoring.
Deliverables for first sprint
master-docs/CONTENT-MANAGER-REMOVAL-PLAN.md(this file)- Feature flag implemented and documented
- Frontend UI changes behind flag: ContentView metadata/buttons, Review table updates, Images table updates, Column persistence
- Backend fixes: status normalization, external_id unification
- WP plugin fallback to fetch
content_htmlwhencontent_idpresent - Tests and staging validation
Next steps I will take if you approve
- Produce exact per-file diffs for the first sprint (safe edits).
- Optionally implement the edits and run the test suite in staging.
If you want me to generate the diffs now, say "generate diffs" and I will produce the changes for review.
End of plan.