Plugin lifecycle

Bedriox creates your entry class and calls three lifecycle methods. Most plugins only need onEnable(), but understanding all three keeps setup and cleanup in the right place.

<?php

declare(strict_types=1);

namespace Acme\Arena;

use Bedriox\Api\Plugin\Plugin;

final class Main extends Plugin
{
    public function onLoad(): void
    {
        $this->logger()->debug('Arena is loading');
    }

    public function onEnable(): void
    {
        $this->context()->events()->registerSubscriber($this);
        $this->context()->commands()->register(new ArenaCommand());
        $this->logger()->info('Arena enabled');
    }

    public function onDisable(): void
    {
        $this->saveArenaState();
        $this->logger()->info('Arena disabled');
    }
}

onLoad() — prepare the plugin

Bedriox calls onLoad() after the manifest and required dependencies have been validated. Use it for small, self-contained preparation that must happen before the plugin is enabled. Do not start gameplay or assume the plugin is enabled yet.

An exception from onLoad() marks the plugin as failed, so report a clear reason when required configuration cannot be accepted.

onEnable() — join the server

Bedriox calls onEnable() after required dependencies are enabled. This is the normal place to register the plugin's public behavior:

• event subscribers;
• commands and changing command choices;
• recipes and item behavior;
• entities and world generators; and
• scheduled work.

Use $this->context() to reach the capabilities Bedriox gives your plugin and $this->logger() for server-console messages. Keep startup work bounded. An exception from onEnable() fails the plugin instead of leaving a partly enabled plugin running.

onDisable() — save and finish

Bedriox disables dependent plugins first, then calls onDisable(). Save any plugin-owned state and close external resources such as files or network clients here. Bedriox releases owner-scoped registrations after the callback, even if the callback throws, but your plugin is still responsible for resources it created outside those Bedriox registries.

Do not use onDisable() to begin new gameplay work. Keep it short and make cleanup safe to run during normal shutdown or failure recovery.

What happens in order

1. Bedriox validates plugin.json and prepares the entry class named by main.
2. It checks that required dependencies are available.
3. It calls onLoad() in dependency order.
4. It calls onEnable() after required dependencies are enabled.
5. During shutdown or disable, it disables dependents before their dependency.
6. It calls onDisable() and releases owner-scoped registrations.

Next, use that lifecycle to register a typed command.