Files
igny8/master-docs/CONTENT-MANAGER-REMOVAL-PLAN.md
2025-11-29 11:23:42 +05:00

8.4 KiB
Raw Blame History

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

  1. Preparation & discovery (completed)
  2. Feature-flag gating & compatibility proxies
  3. Frontend hide + UI refactor (non-destructive)
  4. Backend normalization & compatibility layer
  5. Staged cleanup & code removal
  6. 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_mode to 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/content to /writer/tasks (behind flag).
  • frontend/src/config/routes.config.ts

    • Ensure /writer redirects to /writer/tasks when flag enabled.
  • 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}.
  • frontend/src/services/api.ts

    • Keep publishContent, unpublishContent, generateImagePrompts, fetchContentById unchanged; add wrappers only if needed for compatibility.
  • backend/igny8_core/modules/writer/views.py

    • Keep ContentViewSet endpoints; ensure publish() writes external_id & external_url and has robust validation.
  • backend/igny8_core/business/integration/services/content_sync_service.py

    • Normalize status usage (published not publish) and set canonical content.external_id on successful publish.
  • backend/igny8_core/business/publishing/services/adapters/wordpress_adapter.py

    • Confirm adapter returns external_id and url reliably and handles media errors gracefully.
  • igny8-wp-integration/sync/igny8-to-wp.php

    • Add fallback: if task['content_id'] is present, fetch GET /v1/writer/content/{content_id}/ and use content_html for post body; fallback to legacy task['content'] if content fetch fails.
  • 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

  1. 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).
      • Generate images
        • Visible when status == draft.
        • Action: call POST /v1/writer/content/{id}/generate_image_prompts/; show progress modal if task_id returned.
      • Publish
        • Visible when status == review.
        • Action: call POST /v1/writer/content/{id}/publish/; on success display toast with external_url and refresh.
  2. /writer/content list

    • Remove dropdown row-toggle that shows body.
    • Clicking Title navigates to /writer/content/{id} (no modal).
  3. /writer/review

    • Table columns: [Select] [Title (clickable)] [Categories] [Tags] [Cluster] [Status] [Actions].
  4. /writer/images

    • Remove 'image prompt' column.
    • Image column shows: thumbnail (top) and status badge (below) as vertical stack in a single column.
  5. Table column persistence

    • Store selected columns per route in localStorage key table-columns:${routePath}.
    • On mount, load and apply selection.

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_id and url.

Backend normalization & compatibility

  • Replace any uses of status == 'publish' with status == 'published' (e.g., in ContentSyncService).
  • Standardize storing WP post id in content.external_id (not only in content.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 for content_html.

Tests & verification

  • Unit tests (backend)
    • ContentViewSet.publish() updates external_id & external_url and content status.
    • ContentSyncService picks up published content and updates external_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_id present.
  • Plugin webhook simulation
    • Simulate task_published with content_id present; verify WP post has full body from content_html and metadata keys set.

Rollback & monitoring

  • Quick rollback: flip feature.content_manager_refactor OFF.
  • 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 12: Frontend changes (hide old UI, implement ContentView metadata + buttons behind flag, review/images updates, column persistence).
  • Day 0.5: Backend normalization: ContentSyncService status normalization and external_id writes; confirm publish() 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_html when content_id present
  • Tests and staging validation

Next steps I will take if you approve

  1. Produce exact per-file diffs for the first sprint (safe edits).
  2. 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.