Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| en:entwickler:plugin_manager [2026/02/08 12:10] – mightymcoder | en:entwickler:plugin_manager [2026/10/23 23:22] (current) – kainhofer | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ========= Plugin Manager ========= | ========= Plugin Manager ========= | ||
| - | {{ : | ||
| - | The Plugin Manager module provides a simple user interface and standardized procedures for | ||
| - | * installing, | ||
| - | * uninstalling, | ||
| - | * updating, | ||
| - | * managing and | ||
| - | * integrating | ||
| - | plugins in Admidio. | ||
| - | With the Plugin Manager | + | The Plugin Manager is the part of Admidio that knows which plugins |
| + | and what has to happen to move them from one state to the next. It provides | ||
| - | A Basic //" | + | * a **plugin administration** page under //Administration → Extensions// for installing, enabling, disabling, updating and removing plugins, |
| - | ======== Make your plugin | + | * a **plugin |
| - | To make your plugin | + | * an **upload** for a plugin that arrives as a ZIP archive, |
| - | * [[en: | + | * a **runtime** that loads the enabled plugins into every request, and |
| - | | + | * a set of **admidio plugin:*** command line tasks that do the same as the web interface. |
| - | | + | |
| - | * A [[en: | + | |
| - | * A [[en: | + | |
| - | ======= Naming conventions ======= | + | <WRAP center round important 80%> |
| - | When using the new Plugin Manager, the following naming conventions must be observed: | + | This page describes |
| - | - For better readability file and folder names containing multiple words should follow | + | that was introduced for Admidio 5.0 and is not compatible with it — see |
| - | - All folder | + | [[en: |
| - | - No plugin file defining | + | </ |
| - | ======= Folder structure ======= | + | |
| - | The basic folder structure | + | |
| - | {{:en: | + | |
| - | ====== classes folder ====== | + | A complete, commented example |
| - | ===== Main plugin | + | **plugins/hello-world/**. It shows every convention |
| - | The main [[en: | + | and its own ``README.md`` is the short form of this page. Copy that directory, rename it, and you |
| + | have a working plugin. | ||
| - | ===== Presenter classes | + | ======= |
| - | ==== Plugin-specific classes ==== | + | |
| - | Inside the // | + | |
| - | ==== Plugin preferences class ==== | + | A plugin |
| - | === Single FormPresenter element === | + | file **plugin.php**. Nothing else is required. A plugin that only registers |
| - | If the plugin | + | two files: no class, no base class, no interface, no settings, no page and no language file. |
| - | | + | The **directory name is the plugin ID** and the only identity a plugin ever has. It is used in |
| + | preference names, in URLs and in the components table, so it must consist of lowercase letters, | ||
| + | digits and single hyphens (e.g. ``hello-world``). The display name may change, be translated or be | ||
| + | duplicated by another plugin without any consequence. | ||
| - | Below is an example snippet of the // | + | ====== Folder structure ====== |
| - | <code php> | + | |
| - | public static function createBirthdayForm(Smarty $smarty): string | + | |
| - | { | + | |
| - | global $gL10n, $gCurrentSession; | + | |
| - | $pluginBirthday = Birthday:: | + | <code text> |
| - | | + | plugins/ |
| + | ├── plugin.json | ||
| + | ├── plugin.php | ||
| + | ├── cli.php | ||
| + | ├── modules/ | ||
| + | ├── src/ | ||
| + | ├── languages/ | ||
| + | ├── templates/ | ||
| + | ├── assets/ | ||
| + | ├── db_scripts/ | ||
| + | └── tests/ | ||
| + | </ | ||
| - | $formBirthday = new FormPresenter( | + | None of the subdirectories has to exist and **none of them has to be declared** in the manifest. |
| - | ' | + | They are conventions the core looks for. |
| - | $pluginBirthday:: | + | |
| - | | + | |
| - | null, | + | |
| - | array(' | + | |
| - | ); | + | |
| - | $selectBoxEntries | + | ====== Naming conventions ====== |
| - | ' | + | |
| - | ' | + | |
| - | ' | + | |
| - | ); | + | |
| - | $formBirthday-> | + | |
| - | ' | + | - Class files below the autoload directory |
| - | Language:: | + | - The plugin ID — the directory name — is lowercase letters, digits and single hyphens. |
| - | | + | |
| - | array( | + | |
| - | ' | + | |
| - | ' | + | |
| - | ' | + | |
| - | ) | + | |
| - | ); | + | |
| - | $formBirthday-> | + | ======= The manifest ======= |
| - | ' | + | |
| - | Language:: | + | |
| - | $formValues[' | + | |
| - | array(' | + | |
| - | ); | + | |
| - | [...] | + | Each plugin has to provide a JSON manifest **plugin.json**. Only ``name`` and ``version`` really |
| + | matter to the core; everything else is optional. A manifest that cannot be read, is not valid JSON | ||
| + | or declares no version makes the plugin **broken**: it is still listed and can still be removed, but | ||
| + | it is never loaded and cannot be installed. | ||
| - | $formBirthday-> | + | ^ Key ^ Mandatory ^ Description ^ |
| - | ' | + | | ``name`` | X | Display name. May be a language string ID such as ``PLG_BIRTHDAY_PLUGIN_NAME``. | |
| - | | + | | ``version`` | X | Version of the files. Compared against the installed version to detect an update. | |
| - | | + | | ``description`` | | Short description shown in the plugin administration. May be a language string ID. | |
| - | ); | + | | ``author`` | | The author of the plugin. | |
| + | | ``url`` | | A URL to a wiki page or a project page. | | ||
| + | | ``icon`` | | Bootstrap icon name, e.g. ``bi-cake2``. | | ||
| + | | ``menu`` | | ``false`` suppresses the menu entry below // | ||
| + | | ``requires`` | | Version constraints and dependencies, | ||
| + | | ``autoload`` | | PSR-4 mappings, as namespace prefix | ||
| + | | ``preferences`` | | Where the settings panel of the plugin appears: ``section`` and ``sequence``. | | ||
| + | | ``settings`` | | The preferences the plugin owns. | | ||
| - | | + | A manifest may carry further keys of its own; they are kept and are readable through |
| - | | + | ``$plugin->manifest``. |
| - | | + | |
| + | ====== requires ====== | ||
| + | |||
| + | <code json> | ||
| + | " | ||
| + | | ||
| + | | ||
| + | " | ||
| + | " | ||
| + | " | ||
| } | } | ||
| </ | </ | ||
| + | A constraint is a **space separated list of terms that all have to match**, e.g. ``>=5.1 <6.0``. | ||
| + | A term is an operator (``>=``, ``>``, ``<=``, ``<``, ``=``, ``!=``) followed by a version; a term | ||
| + | without an operator means ``>=``. | ||
| - | === Multiple FormPresenter elements === | + | ``admidio``, |
| - | With Admidio 5 the preference page has been redesigned. It is now possible to display multiple " | + | plugin broken, so it cannot |
| - | In your PluginPreferencePresenter class you can now define multiple FormPresenter elements and add different preferences | + | ``modules`` is deliberately **not** a requirement. A switched-off Admidio module is neither the |
| + | plugin' | ||
| + | switched on again. The plugin administration therefore tells the administrator about it instead of | ||
| + | refusing | ||
| + | ``photos``, ``messages``), | ||
| - | <code php> | + | ====== |
| - | public static function createBirthdayForm(Smarty $smarty): string | + | |
| - | { | + | <code json> |
| - | [...] | + | " |
| - | + | | |
| - | $formBirthday | + | } |
| - | ' | + | |
| - | $pluginBirthday:: | + | |
| - | SecurityUtils:: | + | |
| - | null, | + | |
| - | array(' | + | |
| - | ); | + | |
| - | $selectBoxEntries | + | |
| - | ' | + | |
| - | ' | + | |
| - | ' | + | |
| - | ); | + | |
| - | $formBirthday-> | + | |
| - | ' | + | |
| - | Language:: | + | |
| - | $selectBoxEntries, | + | |
| - | array(' | + | |
| - | ); | + | |
| - | + | ||
| - | [...] | + | |
| - | + | ||
| - | $formBirthday-> | + | |
| - | ' | + | |
| - | $gL10n-> | + | |
| - | array(' | + | |
| - | ); | + | |
| - | + | ||
| - | $formBirthday->addToSmarty($smarty); | + | |
| - | | + | |
| - | + | ||
| - | [...] | + | |
| </ | </ | ||
| - | Now you can define | + | The prefix must **not** start with ``Admidio\``, |
| + | shadowed, and the directory has to stay inside the plugin directory. Both are verified when the | ||
| + | manifest is read; a violation makes the plugin broken. | ||
| - | <code php> | + | ====== preferences ====== |
| - | $formBirthday2= new FormPresenter( | + | |
| - | ' | + | <code json> |
| - | $pluginBirthday:: | + | " |
| - | SecurityUtils:: | + | |
| - | null, | + | |
| - | array(' | + | |
| - | ); | + | |
| - | + | ||
| - | [...] | + | |
| - | + | ||
| - | $formBirthday2->addSubmitButton( | + | |
| - | ' | + | |
| - | $gL10n-> | + | |
| - | array(' | + | |
| - | ); | + | |
| - | + | ||
| - | [...] | + | |
| </ | </ | ||
| - | This form cannot be added to smarty with the // | + | ``section`` names one of the preference tabs and ``sequence`` places |
| + | are ``system``, ``login_security``, | ||
| + | ``overview_extensions`` and ``extensions``. A plugin is not restricted | ||
| + | used to be part of the Admidio core keeps its own tab once it becomes a plugin. A plugin that names | ||
| + | no section, or one that no longer exists, lands in ``extensions``. | ||
| - | <code php> | + | ====== settings ====== |
| - | [...] | + | |
| - | + | The ``settings`` object declares the preferences the plugin owns. They become **ordinary Admidio | |
| - | | + | preferences** when the plugin is loaded, get a row in every organization when it is installed and are |
| - | | + | removed again when it is uninstalled. |
| - | + | ||
| - | [..] | + | Each setting declares a ``type`` |
| + | ``default``, | ||
| + | Admidio to **build the settings form by itself**, so a plugin only writes a preferences presenter | ||
| + | when it wants more than the manifest can express. | ||
| + | |||
| + | A setting **without** a ``label`` is not put into that form. A preference the plugin owns is not | ||
| + | necessarily one this form edits — the position of an overview widget is edited in the overview | ||
| + | preferences, | ||
| + | |||
| + | An ``enum`` lists its permitted values, and may instead name them so that the generated form has | ||
| + | something readable to show: | ||
| + | |||
| + | <code json> | ||
| + | " | ||
| + | " | ||
| </ | </ | ||
| - | You can add as many forms as you like using this method. | + | An ``integer`` may bound what the generated form offers with ``min``, ``max`` and ``step``. The |
| + | value is stored | ||
| - | When all forms are added to smarty you can use a "wrapper template" | + | <code json> |
| + | "hello_world_repeat": | ||
| + | </ | ||
| - | <code php> | + | Three preference names are conventions the core understands: |
| - | [...] | + | |
| - | + | ^ Preference ^ Meaning ^ | |
| - | | + | | ``plugin_<id>_enabled`` | Registered by the core for every installed plugin. It is what enables the plugin for one organization; |
| - | | + | | ``< |
| - | | + | | ``< |
| - | | + | |
| - | | + | In ``< |
| - | + | ||
| - | | + | ====== A complete manifest ====== |
| - | | + | |
| + | <code json> | ||
| + | { | ||
| + | | ||
| + | | ||
| + | | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | | ||
| + | " | ||
| + | | ||
| + | | ||
| + | " | ||
| + | | ||
| + | | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | }, | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | }, | ||
| + | " | ||
| + | " | ||
| + | }, | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | } | ||
| + | } | ||
| } | } | ||
| </ | </ | ||
| - | The corresponding wrapper template is shown below: | + | ======= |
| - | <code smarty> | + | **plugin.php** registers what the plugin contributes and returns nothing. There is **no plugin |
| - | {foreach $cards as $index => $card} | + | class, no interface and no base class**. It runs inside the fully initialized Admidio request, so it |
| - | <div class=" | + | can call any public Admidio API — normally it registers hooks: |
| - | <div class=" | + | |
| - | < | + | |
| - | {include file=$card.templateFile dataIndex=$index} | + | |
| - | </ | + | |
| - | </ | + | |
| - | {/foreach} | + | |
| - | </ | + | |
| - | This template creates cards for each form element defined in the //$cards// variable and loads the corresponding template file. It is necessary to pass the index of the zero-based $cards array to the corresponding template file to retrieve the correct smarty data that is now also available as a zero-based array for each form variable. | + | <code php> |
| - | These are: | + | <?php |
| - | * // | + | use Admidio\Hooks\Hooks; |
| - | * // | + | use AdmidioPlugin\HelloWorld\Greeting; |
| - | * // | + | |
| - | * // | + | |
| - | * // | + | |
| - | This following example shows a possible implementation | + | /* |
| + | | ||
| + | * Admidio bootstrap it could do nothing anyway; the guard only turns a PHP error into a message. | ||
| + | */ | ||
| + | if (realpath($_SERVER[' | ||
| + | exit(' | ||
| + | } | ||
| - | <code smarty> | + | Hooks:: |
| - | <form {foreach $attributes[$dataIndex] as $attribute} | + | </code> |
| - | {$attribute@key}=" | + | |
| - | {/foreach}> | + | |
| - | {include ' | + | A plugin with more to announce puts that into a class of its own and calls it from the entry file, |
| - | | + | which is what the built-in plugins do: |
| - | {include ' | + | |
| - | {include ' | + | |
| - | {include ' | + | |
| - | {include ' | + | |
| - | {include ' | + | |
| - | {include ' | + | |
| - | {include ' | + | |
| - | {include ' | + | |
| - | {include ' | + | |
| - | {include ' | + | |
| - | {include ' | + | |
| - | {include ' | + | |
| - | {include ' | + | |
| - | | + | <code php> |
| - | </ | + | use AdmidioPlugin\Birthday\Birthday; |
| - | {$javascript[$dataIndex]} | + | |
| + | Birthday:: | ||
| </ | </ | ||
| - | This makes it possible to show seperate forms on the same page. There are no limits to the display options whether as cards (as in the example), tabs, or accordions. With this approach each available Bootstrap/ | + | The entry file is included in a scope of its own, so a variable |
| + | anything in the loader. Top-level code should stay cheap: it runs in **every request** of every | ||
| + | organization | ||
| - | ===== Entity, Service and ValueObjects classes | + | ====== What loading a plugin means ====== |
| - | If the plugin has specific //Entity//, // | + | |
| - | ====== db_scripts folder ====== | + | Loading one plugin means four things |
| - | This folder is optional | + | |
| - | In addition | + | - its ``autoload`` mappings become resolvable classes, |
| + | - its **languages/ | ||
| + | - its ``settings`` and the preference that enables it are registered as ordinary Admidio preferences, | ||
| + | - its **plugin.php** is included once. | ||
| - | Similar to Admidio' | + | A plugin that fails while it is being loaded is **reported and skipped**. A broken extension must not |
| + | be able to take the whole installation down, because then it could not be disabled any more. This is | ||
| + | the opposite of the policy for hooks, where a failing callback fails the operation it extends: an | ||
| + | operation can be aborted, a request that never reaches | ||
| + | |||
| + | ======= Hooks ======= | ||
| + | |||
| + | Hooks are the general extension mechanism of Admidio and the normal way for a plugin to change what | ||
| + | the core does. Three primitives are offered by ``Admidio\Hooks\Hooks``: | ||
| + | |||
| + | ^ Primitive ^ Purpose ^ Dispatch ^ | ||
| + | | **Action** | Notify that something is happening or has happened. Every callback is called, return values are ignored. | ``Hooks:: | ||
| + | | **Filter** | Transform a value. Every callback receives the result of the previous one. | ``Hooks:: | ||
| + | | **Resolver** | Ask for one answer. Callbacks are asked in priority order until one returns something other than ``null``. | ``Hooks:: | ||
| - | The class implementation should look like this: | ||
| <code php> | <code php> | ||
| - | final class UpdateStepsCode | + | // transform a value |
| - | { | + | Hooks:: |
| - | | + | |
| - | * @var Database | + | }); |
| - | */ | + | |
| - | private static Database | + | |
| - | | + | // observe an event |
| - | * Set the database | + | Hooks:: |
| - | * @param Database $database The database instance | + | |
| - | */ | + | |
| - | | + | |
| - | { | + | |
| - | self::$db = $database; | + | |
| - | } | + | |
| - | | + | // ask for one answer |
| - | * @throws Exception | + | Hooks:: |
| - | */ | + | |
| - | | + | |
| - | { | + | |
| - | [...] | + | |
| - | } | + | |
| - | } | + | |
| </ | </ | ||
| - | ====== languages folder ====== | + | A lower priority runs earlier, registrations of the same priority run in registration order. A |
| - | This folder contains | + | callback may be registered with an explicit ID — the last argument in the examples on this page is |
| + | the plugin | ||
| + | ID again replaces the previous registration. Exceptions of a callback are logged and rethrown: a | ||
| + | failing extension fails the operation it extends instead of leaving it half done. | ||
| - | ====== | + | ======= The overview widget ======= |
| - | To move away from the deprecated // | + | |
| + | The overview page used to include one PHP file per plugin through a Smarty function, so a plugin | ||
| + | could only contribute there by being a file at a place the core knew. **A widget is now an ordinary | ||
| + | hook**: | ||
| + | |||
| + | A plugin that follows the Admidio conventions — one widget, an ``_overview_sequence`` preference for | ||
| + | its position and a ``_plugin_enabled`` preference for who may see it — does not write that hook | ||
| + | itself but calls ``PluginWidget:: | ||
| - | ====== Root plugin folder ====== | ||
| - | | ||
| - | | ||
| - | ===== Main plugin file ===== | ||
| - | Inside the root plugin folder a main plugin file is required. This file can contain plugin-specific logic (similar to Admidio’s module entry files) or simply initialize the [[en: | ||
| <code php> | <code php> | ||
| - | <?php | + | PluginWidget:: |
| - | use Birthday\classes\Birthday; | + | ' |
| + | )); | ||
| + | </ | ||
| - | /** | + | ^ Option ^ Default ^ |
| - | *********************************************************************************************** | + | | ``name`` | The name of the plugin, translated if it is a language string ID | |
| - | * Birthday | + | | ``icon`` | The icon of the plugin | |
| - | * | + | | ``sequencePreference`` | ``< |
| - | | + | | ``enabledPreference`` | ``< |
| - | * | + | | ``sequence`` | Position of a widget whose preference has no value | |
| - | * @copyright | + | |
| - | * @see https:// | + | |
| - | * @license https:// | + | |
| - | *********************************************************************************************** | + | |
| - | */ | + | |
| - | try { | + | The render callback receives the overview page and the plugin and returns the HTML of the widget, or |
| - | | + | an empty string for a widget that has nothing to show. ``PluginWidget:: |
| + | of the plugin for it. | ||
| - | $pluginBirthday = Birthday:: | + | The **declaration** is what the overview preferences list, so a widget that is switched off is still |
| - | | + | shown there and can be switched on again. |
| - | } catch (Throwable | + | A plugin that needs more control adds the hook itself: |
| - | | + | |
| - | } | + | <code php> |
| + | Hooks:: | ||
| + | | ||
| + | |||
| + | if (!$gValidLogin) { | ||
| + | return $widgets; | ||
| + | } | ||
| + | |||
| + | $plugin = PluginRegistry:: | ||
| + | $widgets[] = array( | ||
| + | ' | ||
| + | ' | ||
| + | ' | ||
| + | ' | ||
| + | | ||
| + | |||
| + | return $widgets; | ||
| + | }); | ||
| </ | </ | ||
| - | ===== Plugin configuration file ===== | + | ======= The preferences panel ======= |
| - | Each plugin must provide a JSON configuration file containing basic plugin information and configuration (see: [[en: | + | |
| + | A plugin that brings preferences shows them in the Admidio preferences, | ||
| + | names. It used to get there by being **scanned for**: the core looked through the autoload | ||
| + | directories for a file called ``*PreferencesPresenter.php`` and guessed the method to call from its | ||
| + | class name. **A panel is now declared**, like a widget, so that a plugin says what it offers instead | ||
| + | of the core deducing it from file names. | ||
| - | ======= Configuration file ======= | + | For a plugin whose form is generated from the manifest, the manifest is all there is: |
| - | Each plugin has to provide | + | |
| - | ^ Key: ^ Mandatory: ^ Description: | ||
| - | | " | ||
| - | | " | ||
| - | | " | ||
| - | | " | ||
| - | | " | ||
| - | | " | ||
| - | | " | ||
| - | | " | ||
| - | | " | ||
| - | | " | ||
| - | | " | ||
| - | | " | ||
| - | | " | ||
| - | |||
| - | The following example shows the structure based on the " | ||
| <code json> | <code json> | ||
| - | { | + | "preferences": { "section": "overview_extensions", "sequence": |
| - | | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | | + | |
| - | | + | |
| - | } | + | |
| - | }, | + | |
| - | | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | ], | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | } | + | |
| - | } | + | |
| - | } ], | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | }, | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | } | + | |
| - | } | + | |
| - | } | + | |
| </ | </ | ||
| - | ======= Plugin class ======= | + | A plugin that builds its form itself registers |
| - | The //Plugin// class extends | + | |
| - | If there is nothing to render the // | ||
| <code php> | <code php> | ||
| - | namespace Birthday\classes; | + | Hooks:: |
| + | PluginPanel:: | ||
| + | static function (array $panels) use ($plugin): array { | ||
| + | global $gL10n; | ||
| - | use Admidio\Infrastructure\Plugins\PluginAbstract; | + | $panels[] = array( |
| - | use Admidio\UI\Presenter\PagePresenter; | + | ' |
| + | ' | ||
| + | ' | ||
| + | ' | ||
| + | ' | ||
| + | ); | ||
| - | class Birthday extends PluginAbstract | + | return $panels; |
| - | { | + | }, |
| - | | + | |
| - | | + | |
| - | return true; | + | |
| - | | + | ); |
| - | } | + | |
| </ | </ | ||
| - | In its simplest implementation for displaying something | + | The panel takes its section and its sequence from the manifest of the plugin it is named after, so |
| - | <code php> | + | only a plugin that declares **several** panels has to name a ``section`` here as well. |
| - | namespace Birthday\classes; | + | |
| - | use Admidio\Infrastructure\Plugins\PluginAbstract; | + | The ``create`` callback receives the ``PreferencesPresenter`` and returns the HTML of the panel. It |
| - | use Admidio\UI\Presenter\PagePresenter; | + | is only called for the panel the administrator actually opens, because the preferences page fetches |
| + | one panel per request. | ||
| - | class Birthday extends PluginAbstract | + | The settings of a plugin are additionally reachable as a dialog from the plugin administration |
| - | { | + | itself, so a plugin does not have to be found in the preferences tabs to be configured. |
| - | | + | |
| - | { | + | ======= Pages ======= |
| - | | + | |
| - | throw new Exception("The page parameter must be set."); | + | **modules/ |
| - | } | + | ``admFuncVariableIsValid()``, ``PagePresenter``, |
| - | | + | ``handleException()``. Nothing about it is plugin-specific. |
| - | + | ||
| - | | + | Only the files **directly below** ``modules/ |
| - | } | + | recursively, |
| - | } | + | the entry file, the classes below ``src/`` — is refused if it is requested directly. |
| + | |||
| + | A page is always reachable at its real location: | ||
| + | |||
| + | <code text> | ||
| + | plugins/ | ||
| </ | </ | ||
| - | All methods provided | + | When the administrator switches on the preference **plugin_module_pages**, |
| + | publishes it under the ordinary module URL: | ||
| + | |||
| + | <code text> | ||
| + | modules/ | ||
| + | </ | ||
| + | |||
| + | Admidio has no front controller and no rewrite rules — every module URL is a real file — so | ||
| + | publishing writes one generated stub per page, which loads the Admidio bootstrap and hands over to | ||
| + | the page inside the plugin. The page itself is unchanged and works through either URL, because | ||
| + | ``__DIR__`` is per file: the relative includes of the page still resolve against its real location. | ||
| + | Because this writes into the Admidio core tree, which a Git-managed or read-only deployment does not | ||
| + | want, it is **off by default**. A generated directory carries a marker file naming the plugin it | ||
| + | belongs to, and nothing without that marker is ever deleted, so a core module directory cannot be | ||
| + | removed by a plugin whatever the plugin is called. | ||
| + | |||
| + | <WRAP center round tip 80%> | ||
| + | Never hardcode either form — ask ``$plugin-> | ||
| + | </WRAP> | ||
| + | |||
| + | A plugin with a page gets a menu entry below //Extensions// when it is installed. A plugin | ||
| + | pages are not destinations — the calendar answers one month of itself for its own buttons — says | ||
| + | ``" | ||
| + | |||
| + | ======= Languages, templates and assets ======= | ||
| + | |||
| + | * **languages/ | ||
| + | * **templates/** is added to the Smarty template search path. ``$plugin-> | ||
| + | * **assets/** holds css, js and images. ``$plugin-> | ||
| + | |||
| + | ======= Database scripts ======= | ||
| + | |||
| + | **db_scripts/** is optional and holds | ||
| + | |||
| + | * ``install.sql`` — run when the plugin is installed, | ||
| + | * ``uninstall.sql`` — run when the plugin is removed, | ||
| + | * ``update_x_y.xml`` — the update scripts, structured exactly like Admidio' | ||
| + | |||
| + | The update scripts are resolved through the plugin ID, and they may call plugin-specific update | ||
| + | steps. Those live in a class ``UpdateStepsCode`` | ||
| + | is the first ``autoload`` prefix of the manifest followed by ``Service\``, | ||
| + | ``"AdmidioPlugin\\HelloWorld\\": | ||
| + | ``AdmidioPlugin\HelloWorld\Service\UpdateStepsCode`` in ``src/ | ||
| <code php> | <code php> | ||
| - | public static function getPluginConfig() : array | + | final class UpdateStepsCode |
| { | { | ||
| - | | + | |
| - | | + | |
| - | | + | |
| - | if (array_key_exists(' | + | { |
| - | | + | self::$db = $database; |
| - | | + | |
| } | } | ||
| - | | + | |
| - | && | + | { |
| - | | + | [...] |
| } | } | ||
| - | |||
| - | return $config; | ||
| } | } | ||
| </ | </ | ||
| - | ======== | + | ======= |
| - | <WRAP center round todo 60%> | + | |
| - | methods documentation | + | |
| - | </ | + | |
| - | The //PluginAbstract// class is the base class for all plugins usable with the Plugin Manager. | + | A plugin owns the CLI command namespace named after its directory, exactly like a module. Where a |
| + | module registers its commands in ``modules/< | ||
| + | **plugins/< | ||
| + | so the autoload mappings, settings and languages of the plugin are available. It only registers | ||
| + | metadata and callbacks; the command itself runs later, after the actor and the component have been | ||
| + | authorized. | ||
| - | Provides: | + | <code php> |
| - | * installation / uninstallation | + | CliTaskRegistry::register( |
| - | * updates | + | ' |
| - | * configuration handling | + | ' |
| - | * dependency checks | + | |
| - | * autoload registration | + | ' |
| - | * visibility + activation control | + | ' |
| + | ); | ||
| + | </ | ||
| - | All custom plugins should extend this class. | + | A command name must have the form ``extension: |
| + | cannot replace a command that is already registered, and a broken ``cli.php`` is reported without | ||
| + | taking the rest of the command line down. | ||
| - | ----- | + | ====== The plugin:* commands ====== |
| - | ===== Singleton / Basic Handling ===== | + | The plugin |
| - | ^ Method ^ Description ^ Return ^ | + | |
| - | | getInstance() | Returns the singleton instance of the plugin | + | |
| - | | __construct() | Protected constructor (singleton pattern) | void | | + | |
| - | | __clone() | Prevents cloning of the singleton | void | | + | |
| - | | __wakeup() | Prevents unserializing | void | | + | |
| - | ----- | + | ^ Command ^ Purpose ^ |
| + | | ``plugin: | ||
| + | | ``plugin: | ||
| + | | ``plugin: | ||
| + | | ``plugin: | ||
| + | | ``plugin: | ||
| + | | ``plugin: | ||
| + | | ``plugin: | ||
| + | | ``plugin: | ||
| + | | ``plugin: | ||
| + | | ``plugin: | ||
| + | | ``plugin: | ||
| + | | ``plugin: | ||
| - | ===== Menu Integration / Preferences | + | ======= The lifecycle ======= |
| - | ^ Method ^ Description ^ Return ^ | + | |
| - | | addMenuEntry() | Adds the plugin menu entry to the database | void | | + | |
| - | | removeMenuEntry() | Removes the plugin menu entry from the database | void | | + | |
| - | | initPreferencePanelCallback() | Initializes plugin preference panel integration | void | | + | |
| - | ----- | + | A plugin has **two independent states**: |
| - | ===== Metadata / Identity ===== | + | * **installed** is global, because |
| - | ^ Method ^ Description ^ Return ^ | + | * **enabled** is per organization, |
| - | | getName() | Returns | + | |
| - | | getIcon() | Returns | + | |
| - | | getVersion() | Returns | + | |
| - | | getMetadata() | Returns | + | |
| - | | getDependencies() | Returns declared dependencies | array | | + | |
| - | | getSupportedLanguages() | Returns supported languages | array | | + | |
| - | ----- | + | The plugin administration groups every plugin it knows by six states: |
| - | ===== Static Files ===== | + | ^ State ^ Meaning |
| - | ^ Method | + | | ``available`` |
| - | | getStaticFiles(? | + | | ``disabled`` | Installed, but not enabled for the current organization. | |
| + | | ``enabled`` | Installed and enabled for the current organization. | | ||
| + | | ``update`` | Installed, but the files declare a newer version than the database. | | ||
| + | | ``broken`` | The manifest is missing, malformed or the requirements are not met. | | ||
| + | | ``orphaned`` | Installed in the database, but the files are gone. | | ||
| - | Example: | + | The operations are deliberately separate and mean different things: |
| - | <code php> | + | |
| - | Plugin:: | + | |
| - | </ | + | |
| - | ----- | + | ^ Operation ^ Scope ^ Touches data ^ |
| + | | install | installation | creates the schema and the preferences of the plugin | | ||
| + | | update | installation | runs ``db_scripts/ | ||
| + | | enable | organization | nothing, only the preference that loads the plugin | | ||
| + | | disable | organization | nothing | | ||
| + | | remove | installation | removes the preferences, | ||
| - | ===== Configuration & Component Information ===== | + | **Disabling is therefore always safe and reversible.** Enabling a plugin that was never installed |
| - | ^ Method ^ Description ^ Return ^ | + | installs it first, so the administrator has one decision to make and not two. Removing is the only |
| - | | getPluginConfigValues() | Returns stored config values | + | destructive operation there is: it takes the plugin away from **every** organization at once, runs |
| - | | getPluginConfig() | Returns merged configuration (defaults + DB) | array | | + | ``uninstall.sql`` and deletes the files. A plugin of the Admidio distribution is refused, because the |
| - | | getPluginPath() | Absolute filesystem path | string | | + | next core update would put its files back and quietly undo the decision. |
| - | | getComponentId() | Database component ID | int | | + | |
| - | | getComponentName() | Plugin folder name | string | | + | |
| - | | getPluginSequence() | Overview sorting sequence | int | | + | |
| - | ----- | + | Reading a plugin never executes plugin code and never throws. An unreadable, malformed or |
| + | incompatible manifest produces a plugin whose ``error`` describes the problem, so the plugin | ||
| + | administration can list, disable and remove a broken plugin instead of breaking with it. The reason | ||
| + | comes from the manifest reader and from ``checkRequirements()``, | ||
| + | developer, so it is shown as the diagnostic it is and not as a translated member-facing message. | ||
| - | ===== Dependency Handling | + | ======= Distributing a plugin ======= |
| - | ^ Method ^ Description ^ Return ^ | + | |
| - | | checkDependencies() | Verifies all dependencies are available | bool | | + | |
| - | Internal helper: | + | ====== The archive ====== |
| - | <code php> | + | |
| - | private static function findAdmidioClass(string $shortName): | + | |
| - | </ | + | |
| - | ----- | + | ``admidio plugin: |
| + | holds a single top-level directory named after the plugin ID, and it is checked with the very gate | ||
| + | the installer uses before it is handed back. | ||
| + | |||
| + | These are left out of the archive: ``.git``, ``.svn``, ``.hg``, ``node_modules``, | ||
| + | ``tests``, ``phpunit.xml``, | ||
| + | ``Thumbs.db``, | ||
| + | the tests of every plugin that is present, and a distributed one would run in installations that | ||
| + | have nothing to do with developing the plugin. | ||
| + | |||
| + | Everything an archive contains is written by somebody the installation does not know, so it is | ||
| + | checked before a single byte of it reaches the plugins directory. An archive may hold at most 5000 | ||
| + | entries, 32 MB compressed and 128 MB extracted, and a failure at any point removes the temporary | ||
| + | directory rather than leaving a partial plugin behind. | ||
| + | |||
| + | ====== The plugin store ====== | ||
| + | |||
| + | The store is one JSON file on a web server — by default ``plugins.json`` next to the ``update.txt`` | ||
| + | that the version check already reads. Admidio fetches it, caches it in ``adm_my_files`` and refreshes | ||
| + | it at most once a day or when an administrator asks. The remote call never happens while a page is | ||
| + | being built, and a catalogue that cannot be reached or cannot be understood makes the store | ||
| + | unavailable rather than breaking the page. | ||
| + | |||
| + | ``plugin: | ||
| + | then run the update scripts — which is all that is needed for a plugin whose files somebody replaced | ||
| + | by hand. Updating is one action whatever the plugin needs. | ||
| + | |||
| + | ====== Tests ====== | ||
| + | |||
| + | Every test suite of Admidio also reads ``plugins/ | ||
| + | it lives and with the same command as the core. The example plugin ships | ||
| + | ``plugins/ | ||
| + | |||
| + | ======= API reference ======= | ||
| + | |||
| + | All classes live in the namespace ``Admidio\Infrastructure\Plugins``. | ||
| + | |||
| + | ====== Plugin ====== | ||
| + | |||
| + | One plugin as it exists on disk. Reading it never executes plugin code and never throws. | ||
| + | |||
| + | ^ Property ^ Description ^ | ||
| + | | ``id`` | Plugin ID, which is the directory name | | ||
| + | | ``path`` | Absolute path of the plugin directory | | ||
| + | | ``manifest`` | The decoded manifest, so a plugin may carry metadata the class does not interpret | | ||
| + | | ``name``, ``description``, | ||
| + | | ``autoload`` | PSR-4 mappings, as prefix => absolute directory | | ||
| + | | ``settings`` | The preferences the plugin owns, as name => definition | | ||
| + | | ``requires`` | ``admidio``, | ||
| + | | ``preferences`` | ``section`` and ``sequence`` of the settings panel | | ||
| + | | ``error`` | Why the plugin cannot be used, or ``null`` | | ||
| - | ===== Installation State / Visibility ===== | ||
| ^ Method ^ Description ^ Return ^ | ^ Method ^ Description ^ Return ^ | ||
| - | | isInstalled() | Plugin exists | + | | ``read(string $directory)`` | Read the plugin |
| - | | isActivated() | Installed and activated | + | | ``isValidId(string $id)`` | Whether a directory name is a usable plugin ID | bool | |
| - | | isVisible() | Visible depending on config and login state | bool | | + | | ``isValid()`` | Whether the plugin can be used at all | bool | |
| - | | isOverviewPlugin() | Registered as overview | + | | ``getEntryFile()`` | Absolute path of ``plugin.php`` | string | |
| - | | isAdmidioPlugin() | Built-in overview | + | | ``getDirectory(string $directory)`` | Absolute path of a conventional subdirectory, |
| - | | isUpdateAvailable() | Installed | + | | ``getPages()`` / ``hasPages()`` | The PHP files directly below ``modules/ |
| + | | ``wantsMenuEntry()`` | Whether the plugin | ||
| + | | ``getUrl(string $page = '' | ||
| + | | ``getSettingValues()`` | Every declared preference with its value, cast to the declared type | array | | ||
| + | | ``renderTemplate(PagePresenter $page, string $template, array $variables)`` | Render a template of the plugin | string | ||
| + | | ``getAssetUrl(string $file)`` | URL of a file below ``assets/`` | string | | ||
| + | | ``getEnabledSettingName()`` | ``plugin_< | ||
| + | | ``getAccessSettingName()`` | ``< | ||
| + | | ``checkRequirements(array $installedPlugins)`` | One English diagnostic per unsatisfied requirement | array | | ||
| + | | ``getDisabledModules()`` | The Admidio modules the plugin needs that are switched off | array | | ||
| + | | ``versionMatches(string $version, string $constraint)`` | Check a version | ||
| - | ----- | + | ====== PluginRegistry ====== |
| + | |||
| + | The only place that answers "which plugins are there" and "may this one run". It never includes | ||
| + | plugin code. Discovery and the installation states are read once per request. | ||
| - | ===== Autoloading ===== | ||
| ^ Method ^ Description ^ Return ^ | ^ Method ^ Description ^ Return ^ | ||
| - | | doClassAutoload(string $class) | Registers PSR-4 autoload mappings | + | | ``all()`` | Every plugin below ``plugins/ |
| + | | ``get(string $id)`` | One plugin, or ``null`` | ?Plugin | | ||
| + | | ``getState(Plugin or string $plugin)`` | One of the six ``STATE_*`` constants | string | | ||
| + | | ``isInstalled(string $id)`` | Installed in this installation | ||
| + | | ``isEnabled(string $id)`` | Enabled for the current organization | bool | | ||
| + | | ``isBuiltIn(string $id)`` | A plugin of the Admidio distribution | bool | | ||
| + | | ``getInstalledVersion(string $id)`` | The version the database records | string | | ||
| + | | ``getComponentId(string $id)`` / ``getComponentUuid(string $id)`` | Component record of the plugin | int / string | | ||
| + | | ``getEnabledOrganizations(string $id)`` | Which organizations have it enabled | array | | ||
| + | | ``getLoadable()`` | The plugins that may be loaded in this request | array | | ||
| + | | ``getEnabledVersions()`` | pluginId => version of every installed and enabled plugin | array | | ||
| + | | ``getOwnerOfSetting(string $name)`` | Which plugin owns a preference | ?Plugin | | ||
| + | | ``requireEnabled(string $id)`` | Refuse the request unless the plugin is enabled | Plugin | | ||
| + | | ``requirePage(string $id, string $page)`` | Guard a plugin page | void | | ||
| + | | ``getScriptPluginId()`` | The plugin the running script belongs to | ? | ||
| - | Example metadata: | + | ====== PluginLoader ====== |
| - | <code json> | + | |
| - | " | + | |
| - | " | + | |
| - | " | + | |
| - | } | + | |
| - | } | + | |
| - | </ | + | |
| - | ----- | + | Loads the plugins that are enabled for the current request. |
| - | ===== Lifecycle Methods ===== | + | ^ Method ^ Description ^ Return ^ |
| + | | ``loadEnabled()`` | Load every enabled plugin | void | | ||
| + | | ``load(Plugin $plugin)`` | Load one plugin | bool | | ||
| + | | ``getLoaded()`` / ``isLoaded(string $id)`` | What was loaded in this request | array / bool | | ||
| + | | ``getFailures()`` | pluginId | ||
| + | | ``getTemplateDirectories()`` | The template search path contributed by plugins | array | | ||
| + | | ``registerLanguages(Plugin $plugin)`` | Add the language directory of a plugin | void | | ||
| - | ==== doInstall(bool $addMenuEntry | + | ====== PluginInstaller ====== |
| - | Installs the plugin. | + | |
| - | Steps: | + | ^ Method ^ Description ^ Return ^ |
| - | * store default config values | + | | ``install(Plugin $plugin, bool $addMenuEntry = true)`` | Run ``install.sql``, |
| - | * execute | + | | ``update(Plugin $plugin)`` | Run the update scripts up to the version |
| - | * register | + | | ``updateWithNewerFiles(Plugin $plugin)`` | Fetch newer files where the store publishes them, then update | Plugin | |
| - | * run update | + | | ``remove(Plugin or string $plugin)`` | Remove the plugin from every organization, |
| - | * set version | + | | ``enable(Plugin $plugin)`` / ``disable(Plugin $plugin)`` | The per-organization decision | void | |
| - | * optionally create menu entry | + | | ``getPreferenceNames(Plugin $plugin)`` | Every preference the plugin owns | array | |
| - | Returns: bool | + | ====== PluginWidget ====== |
| - | ---- | + | ^ Method ^ Description ^ Return ^ |
| + | | ``register(Plugin $plugin, callable $render, array $options)`` | Declare the widget and add the hook that renders it | void | | ||
| + | | ``render(PagePresenter $page, Plugin $plugin, string $template, array $variables)`` | Render a template as the widget body | string | | ||
| + | | ``getDeclarations()`` | Every declared widget, whether visible in this request or not | array | | ||
| + | | ``isVisible(string $preference)`` / ``getAccess(string $preference)`` | Who may see the widget | bool / int | | ||
| + | | ``getSequence(string $preference, | ||
| + | | Constants | ``HOOK``, ``DEFAULT_SEQUENCE``, | ||
| - | ==== doUninstall(bool $removeMenuEntry | + | ====== |
| - | Removes the plugin completely. | + | |
| - | Steps: | + | ^ Method ^ Description ^ Return ^ |
| - | * execute uninstall SQL scripts | + | | ``collect()`` | Every declared preferences panel | array | |
| - | * delete config values | + | | ``inSection(string $section)`` | The panels of one preference tab | array | |
| - | * remove menu entries | + | | ``get(string $id)`` | One panel declaration | ?array | |
| - | * delete component | + | | ``create(string $id, PreferencesPresenter $presenter)`` | Build the HTML of one panel | string | |
| - | * reset version | + | | ``normalizeId(string $id)`` | The panel ID a plugin ID maps to | string | |
| - | Returns: bool | + | ====== PluginPages ====== |
| - | ---- | + | ^ Method ^ Description ^ Return ^ |
| + | | ``isAllowed()`` | Whether ``plugin_module_pages`` permits publishing | bool | | ||
| + | | ``isWritable()`` | Whether the modules directory can be written | bool | | ||
| + | | ``getObstacle(Plugin $plugin)`` | Why a plugin cannot be published, or ``null`` | ?string | | ||
| + | | ``isPublished(Plugin or string $plugin)`` | Whether the stubs exist | bool | | ||
| + | | ``getUrl(Plugin $plugin, string $page)`` | The URL that is currently live | string | | ||
| + | | ``publish(Plugin $plugin)`` / ``unpublish(Plugin or string $plugin)`` | Write or remove the stubs | bool / void | | ||
| + | | ``reconcile()`` / ``syncAll()`` | Bring the modules directory in line with the preference | array | | ||
| + | | Constants | ``SETTING`` (``plugin_module_pages``), | ||
| - | ==== doUpdate() | + | ====== PluginStore ====== |
| - | Updates an installed plugin. | + | |
| - | Steps: | + | ^ Method ^ Description ^ Return ^ |
| - | * add missing config defaults | + | | ``getPlugins()`` | What the catalogue publishes for this Admidio | array | |
| - | * run update classes | + | | ``getEntry(string $id)`` | One catalogue entry | ?array | |
| - | * update stored version | + | | ``getNewerRelease(string $id)`` | A published release newer than the installed one | ?array | |
| + | | ``install(string $id)`` / ``updateFiles(string $id)`` | Fetch and place the files | string | | ||
| + | | ``refresh()`` | Fetch the catalogue now | array | | ||
| + | | ``getUrl()`` / ``isDeveloperCatalogue()`` / ``getError()`` | Where it comes from and why it failed | string / bool / ?string | | ||
| - | Returns: bool | + | ====== PluginPackage ====== |
| - | ---- | + | ^ Method ^ Description ^ Return ^ |
| + | | ``install(string $archivePath, | ||
| + | | ``describe(string $archivePath)`` | The plugin an archive holds | Plugin | | ||
| + | | ``create(Plugin $plugin, string $directory)`` | Build the distributable archive | string | | ||
| + | | ``inspect(string $archivePath)`` | The gate: everything it rejects is rejected before a file is written | string | | ||
| + | | Constants | ``MAX_ARCHIVE_BYTES``, | ||
| - | ==== initParams(array $params | + | ======= What changed since the first plugin manager ======= |
| - | Optional initialization hook for plugins. | + | |
| - | Returns: bool | + | The plugin manager of Admidio 5.0 was built around a ``PluginAbstract`` base class and a |
| + | ``plugin.json`` that described it. The runtime was replaced, and a plugin written for it has to be | ||
| + | converted. The differences that matter to a plugin author: | ||
| - | ----- | + | ^ Then ^ Now ^ |
| + | | A main plugin class extending ``PluginAbstract``, | ||
| + | | The main file was named by ``mainFile``, | ||
| + | | ``" | ||
| + | | ``" | ||
| + | | ``" | ||
| + | | A preferences presenter was found by scanning the autoload directories for ``*PreferencesPresenter.php`` | The panel is declared through the ``PluginPanel`` hook, or generated from the manifest and not written at all | | ||
| + | | ``" | ||
| + | | ``classes/ | ||
| + | | Install and uninstall were one pair of operations | Four distinct operations: install and update are installation-wide, enable and disable are per organization, | ||
| + | | ``db-install.sql`` / ``db-uninstall.sql`` | ``install.sql`` / ``uninstall.sql`` in ``db_scripts/ | ||
| + | | Plugins were installed by copying files | Plugin store, ZIP upload and ``admidio plugin:*`` commands | | ||
| - | ===== Internal Helpers (private) ===== | + | The generated settings form is the largest simplification: |
| - | ^ Method ^ Description ^ | + | preference fields declares them in the manifest |
| - | | readPluginMetadata() | Loads and parses metadata file | | + | code at all. |
| - | | getClassNameFromFile(string $file) | Extracts class name from PHP file | | + | |
| - | | toggleForeignKeyChecks(bool $enable) | Enables/ | + | |
