With WCF 2.2, we will make it more convenient for developers to use package installation plugins.
Default Package Installation Plugin Filenames
When writing the instructions to install or update packages, most of the time, you entered the same information twice: naming the package installation plugin and giving a filename with essentially the same name:
<instructions type="install">
<instruction type="acpMenu">acpMenu.xml</instruction>
<instruction type="userGroupOption">userGroupOption.xml</instruction>
<instruction type="template">templates.tar</instruction>
<instruction type="file">files.tar</instruction>
<instruction type="language">language/*.xml</instruction>
<instruction type="sql">install.sql</instruction>
</instructions>Now with 2.2, the code with the same result is just
<instructions type="install">
<instruction type="acpMenu" />
<instruction type="userGroupOption" />
<instruction type="template" />
<instruction type="file" />
<instruction type="language" />
<instruction type="sql" />
</instructions>Package installation plugins can now define a default filename which will be used in case the package author did not specify one themselves. By default, the following rules apply:
For a XML-based package installation plugin called wcf\system\package\plugin\FooBarPackageInstallationPlugin, the default filename is fooBar.xml. Essentially, the PackageInstallationPlugin is removed from the unqualified class name and the first letter is in lower case now.
Please note that some XML-based package installation plugins overwrite this default implementation, like wcf\system\package\plugin\ACPMenuPackageInstallationPlugin returning acpMenu.xml instead of aCPMenu.xml and wcf\system\package\plugin\LanguagePackageInstallationPlugin returning language/*xml.
For file-based package installation plugins like to install ACP templates, files and templates, s.tar is appended to the lower case PIP name.
The default filename for the sql package installation plugin is install.sql.
In general, the default filenames match the naming convention WoltLab and most developers already use and regardless of these default values, you still can (and in some cases have to) use different filenames.
Cronjob Package Installation Plugin
Cronjobs can now be installed with <options>…</options> given. This element behaves like the option elements for page menu items or for user group options: At least one option has to be "set", otherwise the cronjob will not be executed.
Furthermore, cronjobs now support a name attribute which will be used to identify cronjobs to update or uninstall them. In order to add a name to an existing cronjob, you need to uninstall the existing cronjob first and then install it again with the name given.
Event Listener Package Installation Plugin
The event listener package installation plugin got the same updates as the cronjob package installation plugin. Furthermore, you can now also specify permissions required for the active user so that the event listener is only executed if the active user has at least one of the given permissions.
Very often, especially when adding new input fields on a form, you need to listen to different events of the same class using the same event listener class. Prior to WCF 2.2, you needed to create an event listener for each event separately, now you can concatenate multiple event names by commas:
<eventlistener name="myEventListener">
<eventclassname>wcf\form\RegisterForm</eventclassname>
<eventname>assignVariables,readFormParameters,saved</eventname>
<listenerclassname>wcf\system\event\listener\MyRegisterFormListener</listenerclassname>
<environment>user</environment>
</eventlistener>This event listener now listens to the assignVariables, readFormParameters and the saved event.
Template Listener Package Installation Plugin
Like event listeners, template listeners now also support <options>…</options> and <permissions>…</permissions>. Please note that due to the way template listeners internally work, specifying these elements will create an if condition around the template listener code when the template listener code is inserted into the template. If a permission user.foo.canBar should be required, the code inserted into the template will essentially look like this:
{if $__wcf->session->getPermission('user.foo.canBar')}
// template listener code
{/if}