Extension architecture, lifecycle, manifest format, discovery flow, and templates

Extension System

Extensions are database-backed plugins with a filesystem discovery mechanism. There are two sources:

Source	Path	Example
Bundled (first-party)	`packages/Cartxis//extension.json`	Payment gateways
Filesystem (third-party)	`extensions//extension.json`	User-installed

Extension Lifecycle

Discoverable → Installed → Active
     ↑              ↑          ↑
  Filesystem    extensions   ServiceProvider
  scanning     DB record     dynamically loaded

extension.json Manifest

{
    "code": "stripe",
    "name": "Stripe Payment Gateway",
    "version": "1.0.0",
    "description": "Accept payments via Stripe",
    "author": "Cartxis Team",
    "icon": "credit-card",
    "requires": [],
    "provider": "Cartxis\\Stripe\\Providers\\StripeServiceProvider",
    "provider_file": "src/Providers/StripeServiceProvider.php",
    "category": "payment-gateway"
}

Key Manifest Fields

Field	Purpose
`code`	Unique identifier — must match DB extension record
`provider`	Fully-qualified ServiceProvider class name
`provider_file`	Fallback file path if autoloading isn't available
`requires`	Array of extension codes this extension depends on
`category`	Classification (e.g., `payment-gateway`, `shipping`, `analytics`)

Extension Discovery Flow

ExtensionService::discover() scans both extensions/ and packages/Cartxis/ for extension.json files.
Validated manifests are matched against the extensions database table.
During boot, CoreServiceProvider::bootExtensions() loads the ServiceProvider of every active extension.
Bundled extensions use PSR-4 autoloading; filesystem extensions use require_once on provider_file.

An extension template is provided at extension/templates/payment-gateway/ with scaffold files for creating new payment gateway extensions.