Referensi Plugins

Plugin adalah kumpulan konfigurasi Panel yang dapat digunakan kembali.

Semua yang dilakukan Plugin tetap melalui public API milik Panel.

Contohnya:

mendaftarkan Resource;
mendaftarkan Page;
mendaftarkan Widget;
menambahkan asset;
menambahkan render hook;
menambahkan navigation group;
mengubah konfigurasi Panel.

Secara konsep, Plugin melakukan hal yang sama seperti:

php

PanelProvider

tetapi dalam bentuk reusable package atau reusable module.

Tidak ada configuration surface kedua yang khusus untuk Plugin.

Prinsipnya:

Plugin tidak boleh dapat melakukan sesuatu yang bahkan tidak dapat dilakukan Panel melalui public API-nya sendiri.

Pendekatan ini membuat behavior Plugin tetap:

dapat diprediksi;
dapat direview;
dapat diuji;
dan mengikuti API framework yang sama dengan application.

Namespaces

Class	Kegunaan
`PandaPanel\Contracts\PanelPlugin`	Contract utama yang digunakan framework untuk me-resolve Plugin
`PandaPanel\Plugins\Plugin`	Base class praktis untuk membuat Plugin
`PandaPanel\Plugins\PluginMetadata`	Metadata yang menjelaskan Plugin
`PandaPanel\Plugins\PluginCompatibility`	Melakukan pemeriksaan `requiresPanel`

Contoh Plugin Lengkap

php

<?php

namespace App\Panels\Plugins;

use PandaPanel\Core\Panel;
use PandaPanel\Plugins\Plugin;

final class ReportingPlugin extends Plugin
{
    private ?string $group =
        'Reporting';

    public static function make(): self
    {
        return new self;
    }

    public function group(
        ?string $group
    ): self {
        $this->group = $group;

        return $this;
    }

    public function getGroup(): ?string
    {
        return $this->group;
    }

    public function register(
        Panel $panel
    ): void {
        if (
            $this->group !== null
        ) {
            $panel
                ->navigationGroups([
                    $this->group,
                ]);
        }

        $panel->resources([
            RevenueResource::class,
        ]);
    }

    public function boot(
        Panel $panel
    ): void {
        $panel->cssHooks([
            'page' =>
                'reporting-page',
        ]);
    }
}

Kemudian gunakan pada Panel:

php

public function panel(
    Panel $panel
): Panel {
    return $panel
        ->path('admin')
        ->plugins([
            ReportingPlugin::make()
                ->group(
                    'Analytics'
                ),
        ]);
}

Lihat Plugin yang terpasang:

bash

php artisan panel:plugins

Plugin yang configurable merupakan salah satu tujuan utama desain ini.

Plugin yang sama dapat dipasang pada dua Panel dengan configuration yang berbeda.

Contohnya:

text

Admin Panel
└── ReportingPlugin
    group = Analytics

Operations Panel
└── ReportingPlugin
    group = Reports

Tidak perlu membuat class Plugin baru hanya karena cara Plugin tersebut ditampilkan berbeda.

Contract `PanelPlugin`

Namespace:

php

PandaPanel\Contracts

Contract:

php

interface PanelPlugin
{
    public function id(): string;

    public function register(
        Panel $panel
    ): void;

    public function boot(
        Panel $panel
    ): void;

    public function metadata():
        PluginMetadata;

    /**
     * @return array<string, string>
     * absolute source
     * =>
     * absolute destination
     */
    public function publishes(): array;
}

Framework tidak bergantung pada concrete class:

php

Plugin

Semua lookup dan lifecycle menggunakan:

php

PanelPlugin

Termasuk:

Plugin registration;
Plugin lookup;
Plugin boot;
panel:publish.

Karena itu Plugin yang didistribusikan sebagai package independen sebaiknya mengimplementasikan:

php

PanelPlugin

secara langsung atau melalui base class yang sesuai.

Package tidak sebaiknya bergantung pada class yang hanya ada di application tertentu.

Contohnya, package sebaiknya tidak:

php

extends App\Panels\Plugins\BasePlugin

karena package tersebut menjadi tightly coupled terhadap application.

Tiga Fase Plugin

Plugin memiliki tiga lifecycle phase utama:

Fase	Kapan Dijalankan	Cocok untuk
`register()`	ketika Panel sedang dikonfigurasi	Resource, Page, Widget, navigation group, settings
`boot()`	setelah Panel di-resolve untuk request	logic yang membutuhkan container, user, URL, tenant, atau request context
`publishes()`	tidak otomatis; hanya ketika `panel:publish` dijalankan	file yang ingin disalin ke application

`register()`

register() berjalan selama application boot.

Artinya method ini dapat berjalan pada setiap request, termasuk request yang bahkan tidak masuk ke Panel.

Karena itu jangan melakukan pekerjaan mahal di sini.

Contoh yang sebaiknya dihindari:

php

public function register(
    Panel $panel
): void {
    $count =
        Order::query()->count();

    $user =
        auth()->user();

    $url =
        route('something');

    // ...
}

Operation seperti:

database query;
membaca authenticated user;
resolve current URL;
resolve tenant;
service request-scoped;

tidak sebaiknya dilakukan di register().

Jika tidak, request untuk:

asset;
API lain;
route non-Panel;

tetap membayar biaya tersebut.

`boot()`

boot() berjalan setelah Panel di-resolve untuk current request.

Dan hanya berjalan jika request memang mencapai Panel tersebut.

Ini tempat yang lebih tepat untuk logic yang membutuhkan:

current user;
tenant;
container service;
URL;
request state.

Contoh:

php

public function boot(
    Panel $panel
): void {
    $panel->cssHooks([
        'page' =>
            auth()->user()?->is_admin
                ? 'admin-page'
                : 'user-page',
    ]);
}

Urutan Boot

Plugin di-boot sebelum callback:

php

Panel::bootUsing()

Secara konsep:

text

Panel resolved
    ↓
Plugin boot()
    ↓
Plugin boot()
    ↓
Panel bootUsing()

Dengan demikian application selalu memiliki kesempatan terakhir untuk mengoverride konfigurasi Plugin.

Prinsipnya:

Plugin memberikan default atau contribution, tetapi application tetap memiliki keputusan akhir.

Kesalahan Umum: `register()` dan `boot()` Tertukar

Ini adalah salah satu bug Plugin yang paling umum.

Contohnya register() melakukan query:

php

public function register(
    Panel $panel
): void {
    Order::query()->count();
}

Di development mungkin terlihat tidak bermasalah.

Namun di production, query tersebut dapat terjadi pada:

setiap request;
bahkan request asset;
bahkan request yang tidak menggunakan Panel.

Gunakan boot() jika operation membutuhkan runtime request context.

Contoh Lifecycle

php

$panel =
    Panel::make('plug')
        ->path('plug')
        ->plugins([
            ReportingPlugin::make(),
        ]);

Setelah registration:

php

$panel->getResources();

sudah mengandung:

php

RevenueResource::class

karena:

php

register()

sudah berjalan.

Tetapi:

php

$panel->getCssHooks();

belum memiliki:

text

page

karena boot() belum dijalankan.

Setelah:

php

$panel->boot();

maka:

php

$panel
    ->getCssHooks()['page'];

menghasilkan:

text

reporting-page

`Plugin`

Base class:

php

abstract class Plugin
    implements PanelPlugin
{
    public function id(): string;

    public function boot(
        Panel $panel
    ): void;

    public function metadata():
        PluginMetadata;

    public function publishes(): array;

    public static function in(
        ?Panel $panel
    ): ?static;
}

Base class menyediakan implementasi untuk empat dari lima method contract.

Method yang tetap abstract:

php

register()

karena Plugin yang tidak mendaftarkan atau mengubah apa pun bukan Plugin yang berguna.

`id()`

Default Plugin id dibuat dari nama class.

Contoh:

text

ReportingPlugin

menjadi:

text

reporting

Suffix:

text

Plugin

dihapus, lalu nama diubah menjadi kebab-style identifier.

Plugin id harus stabil antar-versi.

Contohnya:

text

reporting

sebaiknya tetap sama dari:

text

v1
v2
v3

Application menggunakan id untuk pertanyaan seperti:

php

$panel->hasPlugin(
    'reporting'
);

Id mengidentifikasi Plugin, bukan release version-nya.

`Plugin::in()`

Method:

php

Plugin::in()

merupakan kebalikan dari:

php

Panel::plugin()

Gunakan ketika Resource/Page milik Plugin ingin membaca konfigurasi instance Plugin yang dipasang pada current Panel.

Contoh:

php

$currency =
    BillingPlugin::in(
        panel()
    )?->currency()
    ?? 'usd';

Jika Panel tersebut tidak memiliki Plugin:

php

null

dikembalikan.

Bukan exception.

Hal tersebut merupakan kondisi normal.

Misalnya satu Resource digunakan pada:

text

Admin Panel
→ BillingPlugin tersedia

Operations Panel
→ BillingPlugin tidak tersedia

Resource yang shared tidak seharusnya gagal hanya karena salah satu Panel tidak memasang Plugin.

Mengapa Lookup Berdasarkan Class

in() mencari Plugin berdasarkan class.

Bukan dengan membuat instance baru kemudian membaca:

php

id()

Alasannya Plugin dapat memiliki constructor yang membutuhkan configuration.

Contoh:

php

new BillingPlugin(
    currency: 'idr'
);

Framework tidak dapat membuat instance baru hanya untuk bertanya:

text

Apa id-mu?

karena configuration constructor tersebut tidak diketahui.

`PluginMetadata`

Class:

php

final readonly class PluginMetadata
{
    public function __construct(
        public string $name,
        public ?string $package = null,
        public ?string $requiresPanel = null,
        public ?string $url = null,
    );

    public function version():
        ?string;

    public function toArray(): array;
    // {
    //   name,
    //   package,
    //   version,
    //   requiresPanel,
    //   url
    // }
}

Contoh:

php

public function metadata():
    PluginMetadata
{
    return new PluginMetadata(
        name: 'Billing',

        package:
            'acme/panda-billing',

        requiresPanel:
            '^1.2',

        url:
            'https://example.com/docs/billing',
    );
}

Plugin Version Tidak Ditulis Manual

Method:

php

version()

membaca version dari Composer installed-package metadata.

Plugin tidak perlu menulis:

php

version: '1.4.1'

secara manual.

Alasannya manual version string mudah terlupakan.

Contoh masalah:

text

Composer installed:
1.4.1

Metadata manual:
1.2.0

Informasi seperti itu lebih buruk daripada tidak memberikan version sama sekali.

Plugin Tanpa Package

Jika:

php

package = null

maka:

php

version()

mengembalikan:

php

null

Ini benar untuk Plugin yang hidup langsung di application.

Plugin tersebut mengikuti version project, bukan package tersendiri.

Jika package name diberikan tetapi Composer tidak mengenalnya:

php

version()

juga menghasilkan:

php

null

Kesalahan package name di metadata dianggap documentation/configuration issue.

Bukan alasan untuk menggagalkan seluruh application boot.

`PluginCompatibility`

API:

php

public static function assert(
    PanelPlugin $plugin,
    string $panelId,
    ?string $installed = null
): void;

Compatibility diperiksa oleh:

php

Panel::plugins()

sebelum:

php

register()

dijalankan.

Urutannya:

text

Plugin
    ↓
Read metadata
    ↓
Compatibility check
    ↓
Compatible?
├── no
│   ↓
│   exception
│
└── yes
    ↓
store Plugin
    ↓
register()

Dengan begitu Plugin yang incompatible tidak pernah sempat mengubah Panel.

`requiresPanel`

Plugin dapat mendeklarasikan:

php

requiresPanel:
    '^2.0'

Jika version PandaBear yang terinstall tidak memenuhi constraint, framework melempar:

php

PanelRegistrationException::incompatiblePlugin()

Contoh:

text

The [Billing] plugin ([billing], registered on the [admin] panel) requires
panda-panel ^2.0, and 1.4.1 is installed. Upgrade the plugin, or pin this
framework to a version it supports.

Pesan tersebut lebih informatif dibanding kegagalan seperti:

text

Call to undefined method Panel::whatever()

yang baru muncul ketika Plugin memanggil API framework yang sudah berubah.

Mengapa Compatibility Check Penting

Tanpa compatibility check:

text

Plugin membutuhkan PandaBear 2.x
        ↓
Application menggunakan 1.x
        ↓
Plugin register()
        ↓
memanggil method baru
        ↓
undefined method

Developer hanya melihat framework error.

Tidak jelas Plugin mana yang menyebabkan masalah.

Dengan compatibility check:

text

Plugin name
Plugin id
Panel id
required version
installed version

semuanya tersedia dalam error.

Kondisi Compatibility Check Dilewati

Pemeriksaan dilewati jika:

Plugin tidak mendeklarasikan constraint;
PandaBear tidak diinstall sebagai Composer package;
installed version merupakan branch alias seperti:
- dev-main;
- no-version-set.

Kondisi tersebut berarti framework tidak memiliki version stabil yang dapat dibandingkan secara bermakna.

Testing Compatibility

Anda dapat memberikan installed version secara manual.

Contoh:

php

PluginCompatibility::assert(
    $plugin,
    'admin',
    installed: '1.4.1'
);

Dengan begitu test tidak bergantung pada version PandaBear yang benar-benar sedang terinstall di environment test.

Plugin Registration API

php

public function plugins(
    array $plugins
): self;
// array<array-key, PanelPlugin>

public function getPlugins(): array;
// array<string, PanelPlugin>

public function hasPlugin(
    string $id
): bool;

public function plugin(
    string $id
): ?PanelPlugin;

Urutan `plugins()`

Untuk setiap Plugin dalam array:

text

1. assert compatibility
2. store Plugin berdasarkan id
3. register()

Urutan tersebut dilakukan satu per satu.

Duplicate Plugin ID

Jika dua Plugin memiliki id yang sama:

php

PanelRegistrationException::duplicatePlugin()

dilempar.

Contoh:

text

Plugin A
id = billing

Plugin B
id = billing

Tidak boleh ada dua jawaban untuk:

php

$panel->plugin(
    'billing'
);

Karena application juga menggunakan:

php

hasPlugin('billing')

untuk menentukan feature availability.

Duplicate ditolak saat registration, bukan dibiarkan muncul sebagai Resource atau Page ganda.

Membaca Plugin dari Panel

Contoh:

php

$panel->hasPlugin(
    'reporting'
);
// true

Mendapatkan instance:

php

$panel->plugin(
    'reporting'
);

Membaca configuration instance:

php

ReportingPlugin::in(
    $panel
)?->getGroup();

Hasilnya adalah configuration yang benar-benar digunakan ketika Plugin tersebut dipasang.

Publishing Assets

Plugin package dapat membawa Vue component sendiri.

Namun component registry PandaBear menggunakan:

text

import.meta.glob

terhadap application tree.

Contohnya:

text

resources/js/pages/**

Ini merupakan build-time allowlist.

Component yang masih berada di:

text

vendor/acme/plugin/resources/...

tidak otomatis ikut masuk registry application.

Karena itu Plugin harus publish component ke application tree.

Mengapa Asset Dipublish

Setelah dipublish, component menjadi bagian nyata dari application:

text

repository
build
application tree

Developer dapat:

melihat source;
mengedit;
debug;
customize.

Ini merupakan design feature, bukan workaround.

Prinsipnya:

Component yang tidak dapat dilihat source-nya juga lebih sulit di-debug dan di-customize.

`publishes()`

Contoh:

php

public function publishes(): array
{
    return [
        __DIR__
            . '/../resources/js/Widgets'
            =>
            resource_path(
                'js/pages/Panels/Admin/Widgets'
            ),

        __DIR__
            . '/../resources/js/Fields/Signature.vue'
            =>
            resource_path(
                'js/pages/Panels/Admin/Fields/Signature.vue'
            ),
    ];
}

Mapping:

text

absolute source
→
absolute destination

Source dapat berupa:

directory;
single file.

Publish Semua Plugin

bash

php artisan panel:publish

Command tersebut mempublish asset dari seluruh Plugin pada seluruh Panel.

Publish Satu Plugin

bash

php artisan panel:publish reporting

Plugin dipilih berdasarkan id:

text

reporting

Force Overwrite

bash

php artisan panel:publish --force

Tanpa --force, existing file tidak ditimpa.

Dengan --force, file yang sudah ada dapat dioverwrite.

Source yang Tidak Ada

Jika source path pada:

php

publishes()

tidak ditemukan, command memberikan warning.

Command tidak langsung gagal total.

Hal ini memungkinkan satu missing optional asset dilaporkan tanpa membuat seluruh publishing process berhenti.

`panel:plugins`

Lihat Plugin yang terpasang:

bash

php artisan panel:plugins

Filter berdasarkan Panel:

bash

php artisan panel:plugins \
    --panel=admin

Contoh output:

text

 Panel  ID         Name       Package               Version   Requires
 admin  reporting  Reporting  in this application   unknown   any
 admin  billing    Billing    acme/panda-billing    1.4.1     ^1.2

Command ini sangat berguna untuk bug report karena langsung menunjukkan:

Panel;
Plugin id;
nama Plugin;
package;
version;
compatibility constraint.

Plugin Application vs Package

Plugin tanpa Composer package ditampilkan sebagai:

text

in this application

Plugin yang menyebut package tetapi Composer tidak dapat menemukan package tersebut ditampilkan:

text

unknown

Keduanya sengaja dibedakan.

Karena:

text

Plugin lokal application

dan:

text

Metadata package salah

adalah dua kondisi berbeda.

Testing Plugin

Plugin dapat diuji tanpa HTTP request.

Contoh:

php

use PandaPanel\Core\Panel;

it(
    'registers its resource',
    function (): void {
        $panel =
            Panel::make('plug')
                ->path('plug')
                ->plugins([
                    ReportingPlugin::make(),
                ]);

        expect(
            $panel->getResources()
        )
            ->toContain(
                RevenueResource::class
            )
            ->and(
                $panel
                    ->getNavigationGroups()
            )
            ->toContain(
                'Reporting'
            );
    }
);

Testing Configuration

Contoh:

php

it(
    'is configurable',
    function (): void {
        $panel =
            Panel::make(
                'plug-bare'
            )
                ->path(
                    'plug-bare'
                )
                ->plugins([
                    ReportingPlugin::make()
                        ->group(null),
                ]);

        expect(
            $panel
                ->getNavigationGroups()
        )
            ->not
            ->toContain(
                'Reporting'
            );
    }
);

Testing `register()` Tanpa HTTP

Panel yang dibuat melalui:

php

Panel::make()

tidak perlu:

HTTP request;
route;
Panel registration global.

Karena itu register() Plugin dapat diuji secara terisolasi.

Untuk menguji fase kedua:

php

$panel->boot();

Contoh Testing Lifecycle

php

$panel =
    Panel::make('plug')
        ->path('plug')
        ->plugins([
            ReportingPlugin::make(),
        ]);

Pada titik ini:

text

register()
→ sudah berjalan

boot()
→ belum

Assert:

php

expect(
    $panel->getResources()
)->toContain(
    RevenueResource::class
);

Kemudian:

php

$panel->boot();

baru assert konfigurasi boot():

php

expect(
    $panel
        ->getCssHooks()['page']
)->toBe(
    'reporting-page'
);

Hal yang Perlu Diperhatikan

Plugin Tidak Dapat Melakukan Lebih dari Panel

Ini bukan keterbatasan.

Ini adalah design boundary.

Plugin hanya menggunakan public API Panel.

Contohnya:

text

Panel::resources()
Panel::pages()
Panel::widgets()
Panel::assets()
Panel::renderHook()
Panel::navigationGroups()

Jika suatu behavior tidak tersedia pada Panel API, Plugin juga tidak memiliki hidden API khusus untuk melakukannya.

Keuntungannya:

behavior Plugin dapat diaudit;
documentation surface tetap satu;
tidak ada secret Plugin API;
application dapat mereplikasi behavior Plugin secara manual jika dibutuhkan.

`register()` Berjalan pada Setiap Request

register() merupakan bagian dari application boot.

Karena itu:

Jangan menaruh operation mahal di register().

Contoh yang buruk:

php

public function register(
    Panel $panel
): void {
    ExternalApi::fetch();

    Order::query()->count();

    auth()->user();
}

Gunakan boot() untuk operation request-sensitive.

Plugin Boot Sebelum Panel Callback

Urutan:

text

Plugin boot
↓
Panel bootUsing

Application dapat mengoverride perubahan Plugin.

Contohnya Plugin:

php

public function boot(
    Panel $panel
): void {
    $panel->cssHooks([
        'page' => 'plugin-page',
    ]);
}

Kemudian application:

php

$panel->bootUsing(
    static function (
        Panel $panel
    ): void {
        $panel->cssHooks([
            'page' =>
                'application-page',
        ]);
    }
);

Final configuration dapat mengikuti application.

Compatibility Sebelum Registration

Plugin yang incompatible tidak pernah mencapai:

php

register()

Artinya tidak mungkin terjadi kondisi:

text

Plugin mengubah setengah konfigurasi
↓
baru compatibility gagal

Framework memastikan compatibility terlebih dahulu.

Plugin ID adalah Stable Identifier

Jangan mengubah:

text

reporting

menjadi:

text

reporting-v2

hanya karena major release berubah.

Plugin id bukan version.

Version tersedia melalui metadata/Composer.

Id digunakan oleh application untuk:

php

hasPlugin()

plugin()

Plugin::in()

dan harus stabil.

`publishes()` Tidak Pernah Berjalan Otomatis

Plugin installation tidak diam-diam menyalin file ke application.

File hanya disalin ketika developer menjalankan:

bash

php artisan panel:publish

Ini disengaja.

Application harus mengetahui kapan source tree-nya diubah.

Ringkasan Plugin Lifecycle

text

Application boot
    ↓
PanelProvider
    ↓
Panel::plugins()
    ↓
PluginCompatibility::assert()
    ↓
compatible?
├── no
│   ↓
│   PanelRegistrationException
│
└── yes
    ↓
Store Plugin by id
    ↓
Plugin::register()
    ↓
Resources
Pages
Widgets
Navigation
Settings

──────── REQUEST MASUK PANEL ────────

ResolvePanel
    ↓
Panel::boot()
    ↓
Plugin::boot()
    ↓
Panel::bootUsing()
    ↓
Controller/Page

Ringkasan `register()` vs `boot()`

text

register()
──────────
application boot
semua request
bahkan non-panel request

Gunakan untuk:
✓ Resource
✓ Page
✓ Widget
✓ navigation
✓ static configuration

Hindari:
✗ database query
✗ current user
✗ current tenant
✗ request URL
✗ expensive I/O


boot()
──────
hanya setelah Panel resolved

Gunakan untuk:
✓ authenticated user
✓ current tenant
✓ request-aware config
✓ runtime container services
✓ URL-aware configuration

Ringkasan Compatibility

text

Plugin
    ↓
metadata()
    ↓
requiresPanel?
    ↓
installed framework version
    ↓
Semver comparison
    ↓
compatible?
├── yes
│   ↓
│   register()
│
└── no
    ↓
incompatiblePlugin()

Ringkasan Plugin Lookup

text

Panel
├── reporting
│   └── ReportingPlugin instance
│
├── billing
│   └── BillingPlugin instance
│
└── audit
    └── AuditPlugin instance

Lookup:

php

$panel->hasPlugin(
    'billing'
);

atau:

php

$panel->plugin(
    'billing'
);

Dari class Plugin:

php

BillingPlugin::in(
    $panel
);

Ringkasan Publishing Assets

text

Plugin Package
└── resources/js
    ├── Widgets
    └── Fields

        ↓

publishes()

        ↓

php artisan panel:publish

        ↓

Application
└── resources/js/pages/Panels/...
        ↓
Vite build
        ↓
import.meta.glob registry
        ↓
Vue component tersedia

Prinsip Utama Plugins

PandaBear memperlakukan Plugin sebagai reusable Panel configuration, bukan framework di dalam framework.

Plugin:

text

tidak memiliki route system sendiri
tidak memiliki registry sendiri
tidak memiliki hidden configuration API
tidak memiliki frontend loader khusus

Sebaliknya Plugin menggunakan:

text

Panel Public API
        ↓
Resources
Pages
Widgets
Navigation
Assets
Hooks
Settings

Dengan desain tersebut:

Plugin hanyalah konfigurasi Panel yang dapat digunakan kembali, dikemas dalam sebuah object yang memiliki lifecycle, metadata, compatibility check, dan optional publishable assets.

Prinsip lainnya:

register() digunakan untuk deklarasi yang stabil, boot() digunakan untuk runtime context, dan application selalu memiliki keputusan terakhir atas Plugin yang dipasangnya.

Referensi Plugins ​

Namespaces ​

Contoh Plugin Lengkap ​

Contract PanelPlugin ​

Tiga Fase Plugin ​

register() ​

boot() ​

Urutan Boot ​

Kesalahan Umum: register() dan boot() Tertukar ​

Contoh Lifecycle ​

Plugin ​

id() ​

Plugin::in() ​

Mengapa Lookup Berdasarkan Class ​

PluginMetadata ​

Plugin Version Tidak Ditulis Manual ​

Plugin Tanpa Package ​

PluginCompatibility ​

requiresPanel ​

Mengapa Compatibility Check Penting ​

Kondisi Compatibility Check Dilewati ​

Testing Compatibility ​

Plugin Registration API ​

Urutan plugins() ​

Duplicate Plugin ID ​

Membaca Plugin dari Panel ​

Publishing Assets ​

Mengapa Asset Dipublish ​

publishes() ​

Publish Semua Plugin ​

Publish Satu Plugin ​

Force Overwrite ​

Source yang Tidak Ada ​

panel:plugins ​

Plugin Application vs Package ​

Testing Plugin ​

Testing Configuration ​

Testing register() Tanpa HTTP ​

Contoh Testing Lifecycle ​

Hal yang Perlu Diperhatikan ​

Plugin Tidak Dapat Melakukan Lebih dari Panel ​

register() Berjalan pada Setiap Request ​

Plugin Boot Sebelum Panel Callback ​

Compatibility Sebelum Registration ​

Plugin ID adalah Stable Identifier ​

publishes() Tidak Pernah Berjalan Otomatis ​

Ringkasan Plugin Lifecycle ​

Ringkasan register() vs boot() ​

Ringkasan Compatibility ​

Ringkasan Plugin Lookup ​

Ringkasan Publishing Assets ​

Prinsip Utama Plugins ​

Lihat Juga ​

Referensi Plugins

Namespaces

Contoh Plugin Lengkap

Contract `PanelPlugin`

Tiga Fase Plugin

`register()`

`boot()`

Urutan Boot

Kesalahan Umum: `register()` dan `boot()` Tertukar

Contoh Lifecycle

`Plugin`

`id()`

`Plugin::in()`

Mengapa Lookup Berdasarkan Class

`PluginMetadata`

Plugin Version Tidak Ditulis Manual

Plugin Tanpa Package

`PluginCompatibility`

`requiresPanel`

Mengapa Compatibility Check Penting

Kondisi Compatibility Check Dilewati

Testing Compatibility

Plugin Registration API

Urutan `plugins()`

Duplicate Plugin ID

Membaca Plugin dari Panel

Publishing Assets

Mengapa Asset Dipublish

`publishes()`

Publish Semua Plugin

Publish Satu Plugin

Force Overwrite

Source yang Tidak Ada

`panel:plugins`

Plugin Application vs Package

Testing Plugin

Testing Configuration

Testing `register()` Tanpa HTTP

Contoh Testing Lifecycle

Hal yang Perlu Diperhatikan

Plugin Tidak Dapat Melakukan Lebih dari Panel

`register()` Berjalan pada Setiap Request

Plugin Boot Sebelum Panel Callback

Compatibility Sebelum Registration

Plugin ID adalah Stable Identifier

`publishes()` Tidak Pernah Berjalan Otomatis

Ringkasan Plugin Lifecycle

Ringkasan `register()` vs `boot()`

Ringkasan Compatibility

Ringkasan Plugin Lookup

Ringkasan Publishing Assets

Prinsip Utama Plugins

Lihat Juga