- Add pico-theme.yml with a theme's API version, theme-specific default Twig config, registering theme-specific custom meta headers and defaults for Pico's `theme_config` config
- Add new `onThemeLoading(&$theme)` and `onThemeLoaded($theme, $themeApiVersion, &$themeConfig)` events
- Enable Twig autoescaping by default
Use the `Formatted Date` meta header to explicitly set a page's formatted date (i.e. `$meta['date_formatted']`), and `Time` to set `$meta['time']`. Use the `Hidden` meta header to manually hide a page (the page is still accessible, but won't show up in the pages list). Note the difference between `$pageData['hidden']` and `$pageData['meta']['hidden']`.
AbstractPicoPlugin::$enabled now defaults to NULL what leaves the decision whether a plugin should be enabled or disabled by default up to Pico (precisely AbstractPicoPlugin::triggerEvent()). If all dependencies of a plugin are fulfilled, Pico enables the plugin by default. Otherwise the plugin is silently disabled (this was the behavior when AbstractPicoPlugin::$enabled was set to TRUE previously).
If a plugin should never be disabled *silently* (e.g. when dealing with security-relevant stuff like access control, or similar), set AbstractPicoPlugin::$enabled to TRUE. If Pico can't fulfill all the plugin's dependencies, it will throw an RuntimeException.
If a plugin rather does some "crazy stuff" a user should really be aware of before using it, you can set AbstractPicoPlugin::$enabled to FALSE. The user will then have to enable the plugin manually. However, if another plugin depends on this plugin, it might get enabled silently nevertheless.
No matter what, the user can always explicitly enable or disable a plugin in Pico's config.
We recommend plugin developers to use templates when serving HTML contents (like the UI of PicoAdmin), however, by supporting multiple file extensions for themes, we make it pretty hard to overwrite a plugin's template with a theme. As always, we preserve BC using PicoDeprecated.
