Plugin Lifecycle

​

State diagram

​

Stage details

​

Upload

• Checks for a valid manifest.json
• Validates the plugin type and slug format
• Scans PHP files for blocked functions (eval, exec, etc.)
• Rejects the upload if any check fails

​

Install

1. The ZIP is extracted to plugins/{slug}/
2. manifest.json is parsed and stored in the op_plugins database table
3. Database migrations in migrations/ run in order inside a transaction
4. The plugin enters the installed state

​

Activate

1. The plugin class is instantiated
2. register() is called - hooks and filters are registered
3. boot() is called - the plugin can access services and the container
4. Routes from routes/api.php and routes/web.php are loaded
5. The plugin enters the running state for that brand

public function register(EventManager $events, Container $container): void
{
 // Called once per brand activation
 $events->addAction('payment.transaction.completed', $this->onPayment(...));
}

public function boot(): void
{
 // Called after register, all services are available
 $this->service = $this->container->get(MyService::class);
}

​

Deactivate

• All hooks registered by this plugin for the brand are removed (removeByOwner)
• Routes are unloaded
• Data is preserved - database tables, settings, and files remain

​

Uninstall

1. All migrations are reversed (down() methods) inside a transaction
2. The op_plugins row is deleted
3. All plugin files are removed from disk
4. Settings stored in the database are deleted

​

Reinstall

​

Brand-level vs platform-level

​

Update flow

1. Upload a new ZIP with a higher version in manifest.json
2. OwnPay detects the version bump and runs any new migrations
3. Existing data is preserved
4. If the plugin is active for a brand, it is automatically re-booted

​

Related pages

• Directory structure
• Manifest reference
• Hooks reference
• Capabilities reference