SG-Modules

First-party modules that cover what plugin stacks need plugins for.

SG-Modules is the SGEN platform's catalog of first-party modules. Where other platforms grow stacks of third-party plugins to cover form handling, SEO, ecommerce, popups, redirects, and the rest, SGEN ships these as native modules under platform release cadence, platform scope rules, and platform audit logging. The result: one set of update cycles, one set of failure modes, no third-party update that can take down the site.

What is this for?

Read this page to understand the SG-Modules layer of the SGEN platform — what modules exist, what each is for, and how they sit alongside SG-Core (content primitives) and SG-Builder (visual composition).

Good use cases

• You are scoping which capabilities SGEN covers natively before evaluating the platform.
• You are migrating from a stack-based platform and want to know which plugins SG-Modules replaces.
• You are deciding which module to use for a specific workflow.
• You hit a question like "Does SGEN ship a forms module or do I need a plugin?"

What NOT to use this for

• Per-module deep reference — open the specific module's documentation page.
• Custom-code workflows — open the Custom Codes module reference.
• Operator orientation — open Getting Started with SGEN.

Before you start

You should have:

• Basic familiarity with SGEN as a platform.
• A specific question about what coverage SG-Modules provides, or a specific module you want to learn more about.

How this connects to other features

• SG-Core — the engine layer that SG-Modules sits alongside.
• SG-Admin Overview — the operator-facing surface for the modules.
• SG-Builder Overview — the authoring surface that consumes module output.

Where to go

The SG-Admin sidebar lists every module. Each module is one or two clicks from the Dashboard.

How SG-Modules works

Steps — Use the modules

1. Recognize the module catalog

The SGEN platform ships first-party modules covering the workflows that plugin stacks usually serve. The catalog includes:

• Forms — visitor input capture, validation, submission routing.
• SEO — site-wide and per-page SEO controls, sitemap generation, robots.txt, schema editor.
• Page Builder — visual page construction (delivered through SG-Builder).
• Attributions — visitor source tracking and lead attribution.
• Tracking Consent — cookie consent, consent-session review, per-region rules.
• Phone Taps — click-to-call event tracking, per-page reporting.
• Templates — reusable layout patterns paired with SG-Core's template resolver.
• Popups — modal and overlay surfaces with trigger and scope rules.
• Redirects — URL forwarding rules with permanent/temporary toggles.
• Custom Fields — schema extension for records (Pages, Posts, Custom Objects).
• Custom Objects — operator-defined record types beyond Pages and Posts.
• Locations — multi-location business records with map and listing surfaces.
• Events — time-series event records with archive and per-event SEO.
• Analytics — site-wide event aggregation and per-page reports.
• Blacklist — IP and pattern-based traffic blocking.
• Notifications — admin and visitor-facing notification surfaces.
• Tools — site-utility surfaces (Maintenance Mode, Site Protection, Search & Replace, etc.).
• Ecommerce — products, orders, coupons, configuration.
• Activity Feed — operator-facing audit and activity logs.
• Dispenza — vertical-specific workflows for participating businesses.

Each module ships as a native part of the platform. There is no installation step; modules are present from day one of every site.

2. Understand why modules, not plugins

A plugin is a vendor relationship — a separate codebase maintained by a separate team, with its own update cycle and its own potential for breaking. SG-Modules are first-party: they share the platform's release cadence, scope rules, and audit logging.

The difference matters at three levels:

• Reliability. No third-party update can take down the site. Modules update with the platform; the platform's testing covers them.
• Compatibility. Modules are designed to work together. Forms know about Analytics, Popups can host Forms, Templates know about Custom Fields. The platform-level integration is built in.
• Coverage. Modules cover the capability the plugin stack workflow needed. Operators don't have to assemble a stack; the platform provides one.

3. Find the right module for a workflow

Most workflows have an obvious module home. A few that recur:

• Capturing visitor info → Forms.
• Routing submissions → Forms (with Notifications for follow-up alerts).
• Tracking conversions → Attributions + Analytics.
• Showing a CTA at the right moment → Popups.
• Redirecting old URLs to new ones → Redirects.
• Adding a custom record type → Custom Objects + Custom Fields.
• Configuring per-page SEO → SEO module (with Pages or Posts holding the record).

When a workflow doesn't fit any module cleanly, the right move is usually to revisit the workflow shape rather than reach for Custom Codes. Most workflows have a native fit; the cases that don't are rarer than operators expect.

4. Compose modules across workflows

Modules compose. A common multi-module workflow:

A visitor lands on a Page (SG-Core) styled with a Template (Templates module + SG-Core resolver). The Page hosts a Form (Forms module). The Form's submission triggers an Analytics event (Analytics module) and a notification email (Notifications module). The submission is attributed to the visitor's traffic source (Attributions module). All of it works without operator wiring; the platform-level integration is built in.

This composition is the reason modules feel native rather than bolted-on. A plugin stack would require operators to wire each connection manually; SG-Modules' integration is automatic.

5. Find module-level documentation

Every module has its own SG-Admin reference page. The SG-Admin Overview lists them with links to each. Per-module reference covers:

• Configuration surface (what operators can set).
• Integration points (which other modules it works with).
• Operational notes (edge behaviors, common patterns).
• Related reading (sibling modules, supporting documentation).

For deep dives, open the module-level reference. This page is the catalog overview; the module pages are where the detail lives.

What success looks like

A successful understanding of SG-Modules looks like:

• You know which module covers which workflow.
• You stop reaching for plugin-style external tools when SGEN's native module covers the case.
• You understand how modules compose without manual wiring.
• You know where to find module-level documentation.

When all four hold, the catalog is internalized.

What to do if it does not work

You can't find the module for a specific workflow. Most have one. Check the admin sidebar; the module name usually matches the workflow name. If genuinely missing, the Custom Codes module is the fallback — though usually unnecessary.

A module isn't doing what you expected. Check the module's reference page. Most "the module doesn't work" reactions resolve to "the module works differently than the operator expected." The reference clarifies.

Two modules seem to overlap. Usually one is the native home and the other is a related surface. Forms and Submissions, for example — Forms is where forms are configured; Submissions is where their captures land. Both are part of the same workflow.

You want to extend a module beyond its surface. Custom Codes is the fallback. Most extensions can be done within the module's surface; the cases that need Custom Codes are rare and usually involve workflows the platform doesn't otherwise cover.

Best practices

• Use modules for the workflows they cover. Don't reach for Custom Codes when a module exists.
• Compose modules deliberately. The integrations are automatic, but operators decide which integrations matter.
• Read the module-level reference for each module you use regularly.
• Watch for new modules in release notes. The catalog grows over time.

Common questions

How many modules are there? Around twenty as of the most recent release shipped state. The exact count grows over releases.

Do all sites have all modules? Yes. Every SGEN site ships with the full module catalog. Operators choose which to use; nothing requires installation.

Are modules configurable per-site? Yes. Each module has its own configuration surface. Multi-site operators sometimes share configuration patterns across sites; the platform supports this through site-template defaults.

Can I disable a module I don't use? The module remains present in the admin but stays unused if the operator doesn't engage with it. Modules don't impose runtime cost when their workflows aren't active.

What happens when SGEN adds a new module? New modules become available across all sites at the platform's next release. Operators see them appear in the admin sidebar; existing workflows continue unchanged.

Module categories

The modules group into a few operational categories:

Content modules — Templates, Custom Fields, Custom Objects, Locations, Events. Concerned with how content is structured.

Capture modules — Forms, Phone Taps. Concerned with collecting input from visitors.

Distribution modules — SEO, Redirects, Notifications. Concerned with how the site reaches visitors.

Engagement modules — Popups, Attributions, Tracking Consent. Concerned with the visitor journey.

Operational modules — Analytics, Activity Feed, Tools, Blacklist. Concerned with running the site.

Vertical modules — Ecommerce, Dispenza. Concerned with specific business types.

The categorization isn't strict; some modules fit multiple categories. The grouping is a navigation aid, not a hard taxonomy.

How modules sit in the platform

SG-Core provides the content primitives — the records (Pages, Posts, Custom Objects), the storage, the routing. SG-Modules adds capability around the primitives — Forms capture submissions, SEO configures per-record metadata, Templates govern rendering. SG-Dashboard governs deployment — staging, live, account configuration.

The three layers compose:

• SG-Core stores and routes.
• SG-Modules adds workflows.
• SG-Dashboard controls deployment.

Operators usually work primarily in SG-Modules (which lives inside the admin). SG-Core is the layer below; SG-Dashboard is the layer above. Most operator work doesn't require dropping into either of the adjacent layers.

Reading order

Read this overview once. Pair with SG-Core for the content-primitive layer below and SG-Admin Overview for the operator-facing surface.

For each module you'll work with regularly, follow the link from this page to the module's reference. The references go deeper than this overview; they're the working documentation.

Related reading

• SG-Core
• SG-Admin Overview
• SG-Builder Overview
• Getting Started with SGEN

Module testing in operator workflows

When operators set up a new module-based workflow, the platform's normal pattern is configure-then-test. Forms get test submissions; Popups get a manual trigger; Notifications get sent to a test address. The platform supports each pattern with built-in test affordances.

For multi-module workflows, the test cycle covers each module's contribution and then the integration. A Form-on-a-Page-with-an-Analytics-event composition involves three modules; testing each in isolation and then end-to-end is the standard discipline.

The test affordances don't replace real-world validation — operators still review the live workflow once it goes public — but they catch most setup mistakes before any visitor encounters them.

Module versioning

Modules version with the platform. There are no per-module version pins; every site running on a given platform release has the same module versions. The platform team coordinates breaking changes carefully, and major shifts in module behavior are documented in release notes well ahead of the release.

For operators planning ahead, the platform's release schedule and release notes are the canonical source. Modules don't carry their own changelog distinct from the platform's; the platform changelog covers everything.

When a module changes meaningfully — new capability, deprecated configuration, behavior shift — the operator-facing impact is described in the platform release notes.

Operators can review the notes before a release lands and adjust if anything affects their workflows.

The cadence for major module changes is gentle. Most releases ship incremental improvements rather than breaking changes.

Operators rarely have to coordinate around module version transitions.

The platform handles version compatibility automatically across releases.

Module configuration patterns

Each module has its own configuration surface, but a few patterns recur across the catalog.

Per-site configuration. Most modules let operators configure behavior per site. Multi-site teams sometimes share configuration patterns through site templates; the per-site values override the template defaults where they diverge.

Per-record configuration. Modules that work against records (Forms attached to Pages, SEO settings per Page, Custom Fields per type) carry per-record configuration alongside the record. The configuration is co-located with what it governs.

Per-event configuration. Modules that emit events (Forms, Popups, Phone Taps) let operators configure what events fire and what payloads they carry. Most operators stay with the platform defaults; the per-event configuration is for fine-tuning.

Per-trigger configuration. Modules with trigger logic (Popups, Notifications) let operators configure when behaviors fire. The trigger surface is consistent across modules — operators learn one pattern and recognize it across the catalog.

Why config patterns are consistent

The platform team designs modules to share configuration shapes. Operators who learn one module's surface recognize the patterns when they open another. Cross-module learning is faster than per-module learning.

The shared shapes also make multi-module workflows easier to reason about — when a Form fires an event that a Notification consumes, the configuration on each side uses the same pattern.

Module reliability

Modules ship with the platform's release cadence. The platform team's testing covers them; the platform's monitoring covers them; the platform's incident response covers them. Operators don't have to track per-module reliability separately.

When a module has a known issue, the platform's status page surfaces it alongside other platform-level signals. Module-specific incidents are rare; most incidents are platform-level and affect all modules together.

For sites with strict uptime requirements, the module-level reliability is part of the platform's reliability — there is no per-module SLA distinction. A module either works (the platform is up) or doesn't (the platform is having an incident).

About first-party modules

The decision to ship modules first-party rather than supporting a plugin marketplace shapes a lot of what makes SGEN feel different from older platforms.

A plugin marketplace produces variety — many vendors, many competing options, many feature-vs-feature comparisons. Variety can be useful when no clear answer exists.

First-party modules produce coherence — one vendor, one set of behaviors, one update cadence. Coherence is more useful when the right answer is well-known and consistency matters more than choice.

SGEN bets on coherence. The modules are designed together; the integrations are automatic; the failure modes are bounded. Operators trade variety for reliability.

About module catalog growth

The module catalog grows over releases. New modules are added when the platform team identifies a workflow common enough across sites to warrant native coverage. The bar is high — the platform team prefers fewer, more capable modules over many narrow ones.

Operators don't have to track new modules closely. They appear in the admin sidebar at the platform's next release; release notes call them out. Workflows that previously required Custom Codes sometimes get adopted into the catalog as native modules; when this happens, operators who need the workflow gain a cleaner native path.

About platform modules

Platform modules in this context refers to SG-Modules — modules that ship with SGEN as part of the platform release. The phrase appears in this documentation as a synonym for SG-Modules where the catalog-level read is what's meant.

The phrase distinguishes platform modules from custom code or third-party integrations. Platform modules carry the platform's reliability, support, and integration guarantees; custom code carries operator-side responsibility.

About plugin replacement

The phrase plugin replacement appears in this documentation when discussing migrations from plugin-stack platforms to SGEN. The replacement is a workflow replacement, not a code replacement — operators don't install SGEN equivalents of their old plugins; they redesign the workflow using SG-Modules.

The plugin replacement audit (covered in detail in How SGEN Replaces Your Traditional WordPress Stack) walks operators through the per-plugin categorization that drives the migration plan.

About module catalog navigation

The SG-Admin sidebar is the canonical navigation for the module catalog. The sidebar groups modules by area and surfaces sub-pages where modules have multiple surfaces.

For operators new to the catalog, the admin Overview page provides a structured walkthrough. For operators who know the catalog well, the sidebar is faster than any overview.

Scope

This Reference covers the platform-level shape of sg modules: what the surface is responsible for, how it relates to neighboring surfaces, and the structural boundaries that hold across releases. Operator how-to and per-release change land on the linked operator-facing or changelog surfaces, not here.

Examples

• A SGEN operator opens this surface to confirm the structural shape before scoping a configuration change.
• A new team member reads end-to-end to build a mental model of the layer before touching any per-feature settings.
• An integrator references the relationship list to confirm which neighboring surface owns a specific behavior.

Fields