Skip to main content
Version: v1 (Current)

Creating a Plugin

Plugins are the building blocks of the GXP platform. This guide covers creating a plugin through the dashboard, understanding the version lifecycle, and configuring plugin settings.

Create a Plugin Template​

Navigate to the Developer Hub in your team dashboard, then choose the plugin type to create:

  • Pages — full-page attendee apps (registration, agenda, social feed, etc.)
  • Widgets — global components injected into every portal page
  • Themes — portal layout and styling packages
  • Tiles — admin dashboard analytics displays

Click Create and provide:

FieldDescription
NameDisplay name for the plugin
SlugURL-friendly identifier (must be unique within your team)
DescriptionBrief description of what the plugin does

Automatic Git Repository​

When you create a plugin page, GXP automatically creates a Git repository on the platform's self-hosted Gitea server. This gives you:

  • Source control for your plugin code
  • Automated CI/CD builds on push
  • Collaborator management

See Git Repos & Build Pipelines for details on cloning, pushing, and the build process.

First Version​

A first version is automatically created with a blank JavaScript file. This draft version is where you develop and test before publishing.

Each version contains:

AssetPurpose
body_templateHTML/Vue template code
styleCSS stylesheet
javascriptJavaScript code or compiled bundle
dependenciesData and permission declarations
settingsConfigurable options for project admins

Version Lifecycle​

Plugins use independent version management:

Draft (v3)        ← active development
Published (v2)    ← installed by projects, immutable
Published (v1)    ← older version, still in use
Deprecated (v0)   ← marked outdated, still functional

Publishing a Version​

When you publish a version:

  1. The current draft is marked as published and becomes immutable
  2. A new draft version is created with an incremented version number
  3. All assets are copied to the new draft for continued development
  4. Projects can now install or upgrade to the published version

Version Pinning​

Projects pin to a specific version — publishing a new version does not automatically update existing installations. This means:

  • Different projects can run different versions of the same plugin
  • Updating a plugin template doesn't affect existing installations
  • Security scope is locked to the pinned version's dependencies

Dependencies​

Dependencies are the core of the plugin security model. Each version declares what data and permissions it needs:

[
    {
        "identifier": "attendee_profile",
        "model": "Attendee",
        "key": "id",
        "permissions": ["Attendee:view", "Attendee:update"],
        "events": { "onUpdate": "attendee.updated" }
    }
]

When a project admin installs the plugin, they resolve each dependency to a concrete value. At runtime, the platform enforces these declarations — plugins can only access data their dependencies explicitly declare.

See Plugin System for the full security model.

Settings​

Plugin settings are configurable options exposed to project admins. Define a settings schema in the version, and admins configure values through the dashboard form builder when installing the plugin.

Settings follow a merge hierarchy:

Plugin Version Defaults (set by developer)
    └── overridden by → Project Instance Settings (set by admin)
        └── overridden by → Portal/Page-Level Settings (set by admin)

Configuration Flags​

Plugins can declare configuration flags that control platform behavior:

  • Navigation flags — control how the page appears in portal navigation (visible, hidden, external link, etc.)
  • Configuration flags — enable/disable platform features for the plugin (caching, authentication requirements, etc.)

Next Steps​