Module Research Notes
Evidence gathered from the current module files before writing the user guide pages.
Research Sources Inspected
Source path
modules/Marketing
Feature flags marked true
- Controllers
- Models
- Views
- Language
- Permissions
- Left Menu
- Default Menu
- Routes
- Migrations
- Helpers
- Dashboard Widgets
Evidence Summary
Manifest
module.json defines slug marketing, version 0.1.0, category Marketing, and the module capability flags used in this guide.
Runtime surface
9 controller file(s), 44 view file(s), and 33 route mapping(s) were found.
Data surface
10 model file(s), 14 declared table(s), and 4 migration file(s) were found.
Operations surface
41 permission key(s), 0 job(s), 0 seeder(s), and 2 test file(s) were found.
Detailed File Evidence
Controllers and methods
Marketing_analyticsMarketing_campaigns- delete_campaign_templateMarketing_dashboardMarketing_dealsMarketing_pipelinesMarketing_publicMarketing_settingsMarketing_socialMarketing_studio
Jobs and schedules
No scheduled module jobs were found.
Routes sampled
| Route | Target |
|---|---|
marketing | Marketing_dashboard/index |
marketing/dashboard | Marketing_dashboard/index |
marketing/dashboard/(:any) | Marketing_dashboard/$1 |
marketing/campaigns | Marketing_campaigns/index |
marketing/campaigns/(:any) | Marketing_campaigns/$1 |
marketing/campaigns/(:any)/(:any) | Marketing_campaigns/$1/$2 |
marketing/campaigns/(:any)/(:any)/(:any) | Marketing_campaigns/$1/$2/$3 |
marketing/campaigns/(:any)/(:any)/(:any)/(:any) | Marketing_campaigns/$1/$2/$3/$4 |
marketing/deals | Marketing_deals/index |
marketing/deals/(:any) | Marketing_deals/$1 |
marketing/deals/(:any)/(:any) | Marketing_deals/$1/$2 |
marketing/pipelines | Marketing_pipelines/index |
marketing/pipelines/(:any) | Marketing_pipelines/$1 |
marketing/pipelines/(:any)/(:any) | Marketing_pipelines/$1/$2 |
marketing/analytics | Marketing_analytics/index |
marketing/analytics/(:any) | Marketing_analytics/$1 |
marketing/studio | Marketing_studio/index |
marketing/studio/(:any) | Marketing_studio/$1 |
marketing/social | Marketing_social/index |
marketing/social/(:any) | Marketing_social/$1 |
| 13 additional route(s) omitted for readability. | |
README topics
- Boundaries (what stays in core)
- Toggle
- Make it visible
- Tests
- Contracts
Operating Implications
- Permission coverage is part of the module contract, so every workflow should be tested with a role-limited user and an administrator.
- The module has migrations, so fresh installs and tenant databases need migration validation before go-live.
- The module has a public or portal-facing surface, so privacy review and logged-out testing are required.
- Dashboard widgets summarize module state and should be verified against the source list before management reporting.
Known Risks from the Manifest
- Umbrella toggle: module_marketing is the master flag; the legacy module_emails flag is honored as a READ ALIAS for one release (marketing_module_enabled() in helpers/marketing_helper.php) until the CORE seed migration sets module_marketing=1. Forms was extracted into its OWN standalone Forms module (modules/Forms/, slug forms, module_forms toggle, Productivity category) and is NOT part of Marketing - its controllers, models, views, routes, permissions, menu and system-logs live in modules/Forms/. Only the read-only REST/v1 Forms API controllers stay core (they load the Forms module models via package paths).
- Campaign MODELS are module-owned (models/Marketing_emails_model + contacts/sents + Campaign_templates_model - verified sole consumers are this module's controllers), but their TABLES keep the core names (marketing_emails, marketing_email_contacts, marketing_email_sents, campaign_templates) and ship in the base schema, not module migrations. The core EmailTemplateVariablesTrait (renamed from MarketingEmailTrait) stays in application/traits/ - it is the system-wide template-variable registry shared with core Email_templates.php.
- Campaigns settings screen relocated from core Settings::marketing_emails to Marketing_settings (marketing/settings); core keeps NO stub - the legacy settings/marketing_emails + settings/save_marketing_email_settings URLs are module-owned dual-route aliases in config/routes.php (full-relocation rule: never leave a core redirect stub). Log types + the marketing_emails label token moved to config/system_logs.php + config/control_tokens.php sidecars (merged ungated).
- Landing pages are plain Content/CMS pages (cms_contents, PRIMARY-DB global); a campaign links one by cms_content_ref slug/id. Marketing ships no landing engine and no config/public_pages.php.