NewsFeaturesDownloadsDevelopmentSupportAbout Us

Porting Plugins

From LifeType Wiki



The API did not change extensively in LifeType 1.2 compared to LifeType 1.1, so all plugins from LifeType 1.1 should work out of the box (except that any include, include_once, require, require_once should be changed to lt_include). However, they will not make use of some of the new plugin-related features such as the global plugin framework or the new fine-grained permission system.

Please see Plugin Development for more details.

Porting Plugins to LifeType 1.2

This section will list all the major plugin-related changes that must be kept into account when upgrading our older plugins to work with LifeType 1.2.

BlogOwnerAction and SiteAdminAction

Up to LifeType 1.1, action classes that were only meant to be used by the blog owner had to extend BlogOwnerAdminAction, whereas those that were meant for site administrators had to extend SiteAdminAction. Since LifeType 1.2 these action classes do not exist anymore and now all access control is handled by the permissions framework. All plugin actions that extended these two need to be modified so that they only extend the base AdminAction class and access control is done via permissions.

For those classes that extended BlogOwnerAdminAction, the permission that should be required is "manage_plugins":

class MyPluginAdminAction extends AdminAction {
  function MyPluginAdminAction( $actionInfo, $request ) {
    $this->requirePermission( "manage_plugins" );

For those classes that extended SiteAdminAction, the permission that should be required is "manage_admin_plugins":

class MyPluginSiteAdminAction extends AdminAction {
  function MyPluginAdminAction( $actionInfo, $request ) {
    $this->requireAdminPermission( "manage_admin_plugins" );

This is the quickest way to fix this problem, but it is also possible to modify our plugins to register their own permissions (like for example the templateeditor plugin does) and then require such permission via requirePermission() or requireAdminPermission() instead of using the built-in ones. This approach would also offer greater flexibility.

Global plugin settings framework

  • All plugins must implement PluginBase::getPluginConfigurationKeys() and report all configurable keys that are using.
  • All plugins must call their configuration keys "plugin_xxxx_key" so that BlogSettings::getValue() can detect that we're asking a plugin config key and use the global plugin settings framework.

The way in which the plugin configuration keys and the changes needed to the user interface/template pages is described in more detail here


  • All plugin actions must require at least the "manage_plugins" permission. If other plugin-specific permissions are needed, they should be required in addition to this one.
  • All plugins must modify their calls to PluginBase::addMenuEntry() as it now requires an array with the permissions needed to even see the new entry. Please see here for more information on the permissions framework.