If you've written a piece of functionality that you want to share among multiple applications, or distribute within the li3 community, you'll want to create a plugin. The good news is, if you've already created a li3 application, you're more than half way there.
First, to understand how li3 deals with plugins, it's important to understand how it deals with libraries, so make sure you've read "Working with 3rd Party Libraries". In li3, everything is a library, including the li3 core, other frameworks, your application, and of course, plugins. By convention, plugins are simply libraries that conform to the same organizational conventions as a li3 application.
While there are very few (really no) hard requirements for li3 plugins, there are several very strong recommendations. First and foremost is that you follow the namespacing standards outlined in the
Libraries class documentation. Second, your plugin should include a
config directory containing a
bootstrap.php file. Finally, as mentioned above, it's best to conform to the same directory structure as a li3 application. And of course, classes must be namespaced accordingly, with the root namespace matching the name of the plugin. (An exception to this would be if you were using an organizational or vendor-level namespace within which your plugin lived, in which case the plugin's root namespace would look like
Because li3 treats everything as libraries, and because all libraries are essentially on the same playing field, a plugin can include anything. Any type of class or resource that could be included in the li3 core or in an application can be included in a plugin. This includes models, controllers, helpers, adapters, generic classes, even custom routes and web assets.
Common examples of things to include in plugins are adapters for cache engines, databases or web services, or a collection of models to share between multiple applications that use the same data. Other plugins introduce new classes with new functionality which can have their own types of adapters, such as the
li3_access plugin, which adds access control support. Some plugins, like
li3_pdf, wrap other libraries to provide tight integration with li3.
You can create a plugin simply by running the following from any directory, substituting
my for whatever you want to call it. This creates a new plugin from li3's default plugin template.
git clone https://github.com/UnionOfRAD/li3_plugin li3_my
As with other libraries, plugins are installed in your local or system
libraries directory by cloning, symlinking, etc. (Again, see "Working with 3rd Party Libraries"). An important thing to know when developing plugins is that when your library is registered through
Libraries::add(), it can also be configured with custom settings.
$config parameter specifies several default configuration settings, it is also possible to pass any other arbitrary information that you may wish to use in your plugin. This data can then be retrieved within your plugin by calling
As mentioned above, your plugin can also include custom routing and web assets. By default, these are both based on filters that are registered in the primary application's bootstrap files. To handle routing, you'll find a default filter in
config/bootstrap/action.php, which iterates over all registered libraries in reverse order, looking for
config/routes.php files to include. While the application can easily customize this behavior, by default, simply including
config/routes.php in your plugin will automatically register your custom routes with the application.
config/bootstrap/media.php. By default, this is commented out in the bootstrap of the primary application, so it should first be enabled. Then, assets can be loaded from the
webroot directory of the plugin (this directory can be overridden by passing a custom value to the
'webroot' key in
While this works simply in development, the performance is not as good as direct filesystem access. In production, it's better to create a symlink from