← Back to directory

legacy-implementation.md

reference/legacy-implementation.md · 17.6 KB · 2026-11-02 12:48

Legacy Implementation Reference

Reference Boundary

REFERENCE ONLY. Selective snapshot dated 2026-09-11, retained for implementation lessons and source lineage. This is not the product definition, runtime architecture, acceptance checklist, compatibility promise or a migration plan. There is no requirement to preserve the old application's data, tables, APIs, selected-client model, administrator roles or marketing scope. No old documentation or source is deleted by this document. Retirement follows the source map and documentation governance. The four provisional product/architecture/MVP documents are architectural source material, not obsolete marketing requirements; their canonical successors own their meanings. Use implementation architecture, UI system, security and operations, WordPress and status for active implementation guidance.

Reading the Snapshot

"Observed" means visible in inspected source or recorded by the old application notes, not newly executed end-to-end. The existence of a controller, form, table, badge or service name does not establish a reusable engine or a working product feature. There is no configured automated test suite, general worker, scheduler or dynamic module loader in this snapshot. The earlier app is PHP with MySQL PDO persistence. The current implementation specification separately chooses the new modular-monolith mechanism; this historical inventory does not define its schema or semantic contracts. The useful layer lesson is HTTP handling -> business orchestration -> repositories, with explicit dependency wiring and scoped access. Existing controller SQL, database singletons and inline scripts are historical limitations, not conventions to multiply.

Shell and Dashboard

resources/views/dashboard.php demonstrates the common sidebar/header/workspace shell and an authenticated landing placeholder. It does not render a working metrics dashboard, activity summary or campaign workspace. app/Controllers/DashboardController.php loads an active campaign using a query without organization/client scope, although that data is not used as a functional dashboard display. That query is a caution against reusing legacy handlers without scope review, not a pattern to preserve. Several search boxes and shell controls are presentation-only; their visibility does not establish search or analytics. The code loads Outfit rather than Inter and sets the shared sidebar to 260px rather than the old prose's 240px. The sidebar includes fixed marketing destinations and a "Marketing OS" subtitle; these do not constrain model-driven application navigation. The shared script and templates duplicate sidebar behavior with differing element IDs/overlay conventions. Extract the layout idea, then validate actual keyboard, mobile and event binding behavior rather than copying entire pages unchanged.

Brand and Assets

app/Controllers/BrandController.php loads old organization-level brand settings, assets and palette values. Three logo slots are supported: logo-light, logo-dark, logo-icon. Upload handling checks uploaded-file status, server MIME and a 5 MiB limit; raster images are moved and SVG is sanitized before storage with a random name. The handler replaces a database record for that asset slot and cleans up a newly written file after database failure. Previously replaced files are not visibly removed from disk, so this is not a complete asset lifecycle. Palette operations add/edit/delete custom colors and update primary/secondary colors, validating six-digit hexadecimal values and labels. The old mutations require CSRF and an administrator role; this is historical access behavior, not the target governance hierarchy.

resources/views/brand.php contains Identity, Assets, Voice and Deliverables tabs. Mission, vision, values, narrative, positioning, language, services, products and guidance fields are useful editor examples but lack persistence routes. Typography management, broad asset-library functions, document upload and export affordances are not completed features. The useful successor is a family of text/file/palette/font editors with real save/error states and permission-aware model binding, not a preserved brand schema. Guidance and explanatory documents can be knowledge; they need not be forced into ordinary structured properties.

Campaign Lists and Readiness

resources/views/campaigns.php presents selected-client campaigns with dates, readiness, active state and selected automation links. The intended primary row action opens the edit modal; status controls and workflow badges remain independent actions. app/Services/CampaignService.php validates a name, ordered start/end dates and a nonempty allowlisted workflow selection through an injected repository. Old workflow names are a fixed marketing vocabulary, not type definitions or execution-engine contracts. Readiness is computed from campaign fields/dates/selections, not from proof that external connections or runnable workflows are operational. Campaign deactivation also deactivates selected automations; activation gates are old business rules, not universal policy/autonomy semantics. The snapshot lacks campaign deletion and working detail/scheduling/publishing/reporting actions. The previously described campaign-detail hub, calendar, content/channel/goal handling and richer lifecycle were future concepts, not an implemented central platform workspace. Retain row/modal, status-feedback and detail-layout lessons without preserving those domain APIs or tables.

Automations and WordPress

resources/views/automations.php groups operations under WordPress, Email, Social, Workflows and Reporting tabs. The WordPress workspace contains connection, test, discovery, resource inspection, WP Populate, saved work and recent activity paths. Email, Social, Workflows and Reporting are placeholders; workflow selections and active toggles do not make a general automation runtime. WP Populate supports title, page/post type, selected connection, brief and Gutenberg markup with a sandboxed local iframe preview. Optional generation returns markup for human review; manual editing, local saving and remote drafting do not require a Groq key. Saved actions can be resumed/discarded; they are editor payloads, not canonical workflow executions or historical events. app/Controllers/PageBuilderController.php sanitizes content and can create a WordPress draft, complete saved work and record selected activity. A successful remote draft may return a WordPress edit URL. The operation does not publish live content. No generic approval queue, scheduled publishing, reliable retry/idempotency protocol or cross-system transaction is established. Discovery retains names, titles, identifiers and sampled stylesheet cues, not complete validated normalized tools. Per-site variation, incomplete coverage and rendering fidelity matter more than raw resource counts. Exact endpoints, size/time limits, credential mechanisms and source mapping requirements are retained once in WordPress implementation knowledge. The old permanent-support statement, 40+ customer narrative and native-CMS replacement/migration commitments are not carried forward.

CRM, Analytics and Native CMS

resources/views/crm.php is a placeholder, not contact, pipeline, note or CRM CRUD functionality. Separate old account/context controls can create, edit and select clients; this does not demonstrate a reusable CRM capability. The selected client belongs to the old organization/session context and is not automatically the future tenant or a canonical business-organization object. resources/views/analytics.php is a placeholder with no rendered measures, collection jobs, charts or exports. Old analytics descriptions mentioned impressions, clicks, engagement, conversions and follower growth; the target analytics responsibility is not limited to marketing. resources/views/web_cms.php is a placeholder, not a native CMS or functioning module. Native CMS ideas about coherent editing, media, forms, redirects, SEO, revisions and controlled extensions are considerations for a chosen backend, not proof of implementation or a support obligation.

Activity and Account Flows

app/Controllers/ActivityController.php and app/Controllers/NotificationController.php expose scoped read-only activity feeds. The full feed supports pagination; the compact notification preview takes the latest five events, with an empty result when no client is selected. Messages use actor/System, event type and time rather than a complete notification delivery model. There is no unread state, dismissal, preference management, channel delivery or notification creation UI. Do not equate these rows with the new Event Engine, object version history or Communication Engine acceptance.

app/Controllers/ProfileController.php updates name/email, raster avatar and password; the old administrator can also change the organization name. Avatar uploads use server MIME checks and a 5 MiB limit, but previous files are not cleaned up by this controller. Password replacement has a 14-character minimum and hashing; comprehensive reauthentication/session revocation is not demonstrated by the form. Sign-in uses MFA setup/verification and recovery-code paths; exact mechanisms and review gaps are retained in security and operations. Profile lacks visible notification preferences, team/role management, API keys and connected-service settings.

Operational Lessons and Disposition

The external configuration loader and documented Plesk path are useful environment knowledge; no credentials need to be read to preserve it. Current encryption is AES-256-GCM; libsodium was only a proposed alternative, and a key-version label is not a working key ring. app/Services/RateLimiter.php directly queries a legacy table and separates counting from insertion; reuse needs concurrency and persistence review. bin/setup.php is trusted-shell, old empty-schema setup only, not a new-runtime installer or an upgrade mechanism. Past module-folder and job-worker descriptions were proposed architecture without runtime discovery/execution support; they are not executable instructions. Preserve security principles, practical source observations and useful UI patterns, but replace the obsolete domain bindings and remove misleading placeholder obligations from the target. Use the explicit RETAIN, REFACTOR, REPLACE, REMOVE and REFERENCE ONLY inventory in status before implementation reuse. Source retirement and canonical link completion are ledger/governance tasks; this selective reference is not a duplicate archive of every old document.

Surface Visual Archaeology and Disposition

This section is reference material, not current UI authority. The current visual standard is implementation/ui-system.md. These findings preserve evidence so future builders do not repeat the archaeology; they do not restore the old application's information architecture, data model, authorization model or workflows.

| Category | Disposition | Evidence found | Rationale | | --- | --- | --- | --- | | Admission/login composition | Adapt | resources/views/login.php uses a full-screen branded background, constrained card, accent treatment and visible form feedback. | Recover the hierarchy and calm branded entry surface, but use current principal registration, confirmation and authentication states. | | Wordmark and logo variants | Recover | assets/idiosyncrasy-dark-text.svg, assets/Idiosyncrasy-light-text.svg and assets/brand/ light/dark/icon variants. | Existing assets support light/dark shell and admission contexts; verify rendering before use. | | Authenticated shell | Adapt | resources/views/dashboard.php demonstrates sidebar, header, context area and independently scrolling workspace. | Preserve the composition and density; replace marketing destinations and legacy context semantics with actual target capabilities and server-resolved Business context. | | Sidebar/navigation | Adapt | Legacy sidebar uses a dark branded surface, icon/text navigation, active treatment, account context and logout. | Retain visual hierarchy, responsive drawer and focus behavior; do not restore the fixed Marketing OS sitemap. | | Typography | Adapt | Legacy loads Outfit 300/400/500/600; target evidence uses Georgia. | These are competing observed systems. Choose and document final roles during visual implementation; do not treat either as an unreviewed universal replacement. | | Colour treatment | Adapt | Legacy tokens include #202d3d, #38A895, #B04AC6, #2c3e50, #8c9ba5, #e1e7ed; target uses darker teal and light neutral surfaces. | Recover dark/light contrast and teal emphasis, then consolidate semantic roles and test contrast. Purple and Business colors cannot override status meaning. | | Forms and focus | Recover | Labels, native controls, autocomplete, validation, CSRF fields and visible focus patterns appear across legacy forms and stylesheet. | Presentation and accessibility patterns are reusable; identity and authorization behavior are not migrated. | | Feedback | Recover | Flash messages, profile toast feedback and copy-to-clipboard confirmation are visible patterns. | Retain explicit success/error/warning feedback with accessible text; only implement behavior supported by the current platform. | | Panels/cards | Adapt | White panels, modest radii, borders and restrained shadows recur in login and application views. | Use for genuinely framed tools and repeated items without decorative nested-card layouts. | | Tables/lists/rows | Adapt | Campaign/list rows, table density and hover treatment are present. | Retain readable comparison and interaction patterns; do not carry over campaign readiness or selected-client semantics. | | Tabs | Adapt | Bootstrap tab navigation and horizontal overflow behavior are present in Brand and Automations views. | Use only where the current target has real alternate views; no placeholder tabs. | | Responsive drawer | Recover and adapt | js/app.js and css/style.css implement a mobile sidebar, overlay, close behavior and transitions, though template IDs differ. | Reconcile into one target interaction contract with focus return, dismissal and reduced-motion support. | | Motion | Reference only | Sidebar transform, button hover and performance-ring hover transitions are observed. | Use restrained state-comprehension motion where useful; performance rings and decorative animation are not target requirements. | | Brand/assets editor | Reference only | Brand tabs, three logo slots, palette swatches and upload handling exist. | Preserve editor presentation lessons only; the old organization schema, administrator role and incomplete asset lifecycle are not target contracts. | | Campaign/automation/CRM/analytics surfaces | Reference only | Legacy pages contain campaign rows, automation tabs, CRM and analytics placeholders. | Their visual composition may inform generic records, but their business vocabulary, readiness rules and placeholder promises are obsolete. | | Activity/notification/account flows | Reference only | Scoped activity feeds, notification preview, account switcher and profile forms exist. | Readable event rows and account-form treatment are useful; selected-client authority, unread/delivery assumptions and old admin behavior are excluded. | | Marketing OS identity/navigation | Retire | Legacy subtitle and fixed destinations for Brand, Web CMS, Campaigns, Automations, CRM and Analytics. | Conflicts with the current Business/object/capability-driven surface. | | Selected-client and administrator authority | Retire | Legacy client context switching and administrator checks. | Conflicts with principal-first identity, explicit Business resolution and current AuthorityGrant/Policy boundaries. | | Legacy schemas/readiness/direct writes | Retire | Campaign/CRM tables, readiness computation and controller/repository persistence patterns. | Visual reconstruction must not restore obsolete data models or bypass CommandHandler. | | Decorative unsupported controls | Retire | Search, export, guidance and placeholder controls that do not perform their advertised behavior. | The current all-controls policy requires functional behavior or explicit unavailability. |

The disposition is subordinate to ui-system.md. If future implementation evidence conflicts with this historical snapshot, update the current standard and record the evidence in status; do not reinterpret this reference record as a second specification.