File Structure

Front-end root /

Data directory /data/

data/
├── articles/
│   ├── _index.json        — Lightweight index (metadata only)
│   ├── my-article.json    — Full article data (content, SEO, galleries, all fields)
│   └── other-article.json
├── pages/
│   ├── _index.json
│   └── my-page.json
├── projects/
│   ├── _index.json
│   └── my-project.json
├── categories.json        — Category store (slug → {name, parent, description})
└── tags.json              — Tag store (slug → {name, description})

Other key directories

Admin panel /admin/

Admin templates /admin/templates/

Plugins

A plugin is a self-contained folder under /plugins/ — its own PHP files, its own JSON data storage, and optionally its own admin page. Plugins never modify core files; installing or deleting one is a matter of adding or removing its folder.

plugins/
└── my-plugin/
    ├── plugin.json          — Manifest: name, slug, version, entry file.
    │                          Must contain "synaptik_plugin": true or the
    │                          folder is ignored by the plugin scanner.
    ├── my-plugin-init.php    — Entry file (declared in plugin.json).
    │                          Registers the admin_menu hook and any
    │                          front-end behaviour.
    ├── data/                 — Plugin's own data store, .htaccess-protected,
    │                          created automatically on first write
    ├── private/              — CSRF secrets, rate-limit stores, etc.,
    │                          .htaccess-protected
    ├── admin/
    │   ├── admin-page.php    — Exposes "{slug}_render_admin_page($view)",
    │   │                       the contract read by admin/index.php's
    │   │                       plugin_page router
    │   └── actions.php       — POST-only endpoint for state-changing
    │                           admin operations (CSRF-protected)
    ├── assets/               — Plugin-specific CSS/JS
    └── lang/                 — Translations, front + admin

How plugins are tracked

plugins.json at the CMS root is the activation registry: { "slug": { "active": true|false } }. A plugin present in /plugins/ but absent from this file (or marked inactive) is installed but dormant — none of its code runs. Activating a plugin from Admin → Extensions is what actually loads it on every request, via pl_load_active_plugins() (called once from functions.php).

How plugins integrate with the CMS

• Admin sidebar — a plugin registers its own entry via the admin_menu hook (pl_on_admin_menu() in plugin-api.php). Its admin page then renders inside the standard admin layout (same sidebar, top bar, footer) through admin/index.php?action=plugin_page&slug={slug}.
• Front-end output — the core's shortcode pipeline (render_content_html()) has no filter hook for third-party shortcodes, so a plugin adding one (e.g. [newsletter_signup]) buffers the full page output and resolves its own shortcode string directly, only on genuine front-end HTML responses.
• Data storage — each plugin owns its own flat JSON files under its data/ folder, entirely separate from /data/ (CMS content). Deactivating a plugin preserves this data; deleting the plugin folder removes it permanently.
• Security — plugins do not depend on the core's CSRF/session internals beyond reusing $_SESSION['admin'] for auth. CSRF tokens, rate-limit stores, and any HMAC secrets are generated and stored inside the plugin's own private/ folder.

Distribution

export-release.sh excludes /plugins/ and plugins.json from the public core release ZIP — plugins ship and update independently of core version releases, each as its own downloadable .zip from the Plugins page.

Path changes in v1.2

The following directories were moved in version 1.2. If you are upgrading from 1.1 or earlier and have hardcoded any of these paths in a theme or external script, update them accordingly.

Theme code using the standard API (render_header_scripts(), __t(), _e()) is unaffected — paths are resolved internally.