Skip to main content
Version: v1 (Current)

Plugin Development Overview

This page covers the core concepts behind GXP plugin development — the Developer Hub, plugin types, version lifecycle, dependency model, settings, and configuration flags. If you're ready to follow a hands-on walkthrough, jump to the Tutorials.

The Developer Hub​

The Developer Hub lives in your team dashboard and is the central workspace for managing everything you build on GXP. Access it from the team-level navigation.

From the Developer Hub you can create and manage:

SectionWhat it contains
PagesFull-page attendee apps (registration, agenda, social feed, etc.)
WidgetsGlobal components injected into every portal page
ThemesPortal layout and styling packages
TilesAdmin dashboard analytics displays
PlansExperience templates that provision entire project structures

Each plugin type shares the same core workflow: create a template, develop versions, publish, and install into projects. The difference is where and how they're rendered in the platform.

Plugin Types​

Pages​

Pages are full-screen attendee-facing apps embedded in a portal. Each page is a standalone plugin that can be installed into one or more projects and configured independently per installation.

Examples: event schedule, registration form, social feed, gamification leaderboard.

Widgets​

Widgets are small components injected into every page of a portal. They run alongside page plugins and are useful for persistent UI — chat panels, notification overlays, analytics tracking.

Themes​

Themes control the portal's overall layout, typography, color palette, and structural chrome. Only one theme is active per portal at a time.

Tiles​

Tiles display metrics and quick-action panels on the admin project dashboard (the "Overview" tab). They're only visible to admins.

Plans​

Plans are the highest-level construct. A plan bundles a set of pages, widgets, and configuration presets into a reusable template. When a project admin creates a new project from a plan, the plan provisions all the linked plugins, default settings, and navigation shortcuts automatically.

Git Repositories​

When you create any plugin template, GXP automatically creates a Git repository on the platform's self-hosted Gitea server at git.eventfinity.app. This gives you:

  • Source control via SSH or HTTPS
  • Automated CI/CD builds triggered on every push to the build branch (main by default)
  • Collaborator access management synced with the platform

See Git Repos & Build Pipelines for setup instructions, build configuration, and output requirements.

Version Lifecycle​

Plugins use independent version management. There is always exactly one draft version under active development, and any number of published versions that projects can install from.

Draft (v3)        ← active development, can be edited
Published (v2)    ← installed by projects, immutable
Published (v1)    ← older published version, still usable
Deprecated (v0)   ← marked outdated, still functional if pinned

Publishing​

When you publish the current draft:

  1. The draft is marked published and becomes immutable
  2. A new draft is created with an incremented version number, copying all assets
  3. Projects can now install or upgrade to the newly 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
  • Breaking changes in a new version never affect existing installations
  • Security scope is locked to the pinned version's dependency declarations

Plugin Assets​

Each version contains the following editable assets:

AssetPurpose
body_templateHTML/Vue template rendered in the attendee portal
styleCSS stylesheet scoped to the plugin
javascriptCompiled JavaScript module (plugin.es.js from your build)
dependenciesData and permission declarations
settingsConfigurable options exposed to project admins

Assets can be edited directly in the dashboard code editor or uploaded via the CI/CD build pipeline from your Git repository.

Dependencies​

Dependencies are the core of the plugin security model. Each version declares exactly what data and permissions it needs at install time. When a project admin installs the plugin, they resolve each dependency to a concrete value for their project.

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

At runtime the platform enforces these declarations — plugins can only access data their dependencies explicitly declare. No undeclared data access is possible.

See Plugin System for the full security model.

Settings​

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

Settings use a three-level merge hierarchy:

Plugin Version Defaults  (set by developer, in the version)
    └── overridden by → Project Instance Settings  (set by admin at install)
        └── overridden by → Portal/Page-Level Settings  (set by admin per portal)

This lets you ship sensible defaults while giving project admins full control over their configuration.

Configuration Flags​

Plugins can declare configuration flags that control platform-level behavior for that plugin:

  • Navigation flags — control how a page appears in portal navigation (visible, hidden, external link, anchor, etc.)
  • Feature flags — enable or disable platform behaviors (caching, authentication requirements, analytics tracking, etc.)

Configuration flags are declared per-version and can be set to different values per project installation.

Next Steps​