Marketing Reference Public

Module Research Notes

Evidence gathered from the current Marketing module files — controllers, models, configs, and migrations — before writing these user guide pages.

Guide version: r1 Module version: 0.1.0 Updated: 2026-07-30 Estimated time: 3 min
You are viewing version r1 of this guide. View the current version
Module Research Notes

Marketing

Evidence gathered from the current module files before writing the user guide pages.

Slug: marketingVersion: 0.1.0Category: MarketingReviewed: 2026-07-11

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_analytics
  • Marketing_campaigns - delete_campaign_template
  • Marketing_dashboard
  • Marketing_deals
  • Marketing_pipelines
  • Marketing_public
  • Marketing_settings
  • Marketing_social
  • Marketing_studio

Jobs and schedules

No scheduled module jobs were found.

Routes sampled

RouteTarget
marketingMarketing_dashboard/index
marketing/dashboardMarketing_dashboard/index
marketing/dashboard/(:any)Marketing_dashboard/$1
marketing/campaignsMarketing_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/dealsMarketing_deals/index
marketing/deals/(:any)Marketing_deals/$1
marketing/deals/(:any)/(:any)Marketing_deals/$1/$2
marketing/pipelinesMarketing_pipelines/index
marketing/pipelines/(:any)Marketing_pipelines/$1
marketing/pipelines/(:any)/(:any)Marketing_pipelines/$1/$2
marketing/analyticsMarketing_analytics/index
marketing/analytics/(:any)Marketing_analytics/$1
marketing/studioMarketing_studio/index
marketing/studio/(:any)Marketing_studio/$1
marketing/socialMarketing_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.

Report a content problem