Extension Structure

Starting from Plesk 11, developers can pack extensions in a cross-platform format, in a ZIP archive with a metadata file placed in the root directory. Such extensions are also supported by Plesk for Windows.

Plesk for Linux is backwards-compatible with previously used extension (module) packages in RPM and Deb package formats. However, we highly recommend that you pack and distribute extensions in ZIP archives.

In this chapter:

File Structure

meta.xml

Conflict Resolution on Upgrade

Removal Procedure

Creating and Packaging Extensions

Class Naming Conventions

 

File Structure

A typical ZIP archive with an extension has the following structure of files and directories:

example-extension.zip
 |
 +-meta.xml
 +-/htdocs/
   |
   +-index.php
   +-public/
   +-...
 +-/plib/
   |
   +-/hooks/
     |
     +-...
   +-/library/
     |
     +-EventListener.php
     +-...
   +-/scripts/
     |
     +-pre-install.php
     +-post-install.php
     +-pre-uninstall.php
     +-...
 +-/sbin/
   |
   +-...
 +-/var/
   |
   +-...

The description of the most important files and directories is as follows:

  

 

meta.xml

A file that describes an extension, meta.xml, can look as follows:

<?xml version="1.0"?>
<module>
  <id>test-extension</id>
  <name>Test extension</name>
  <description>Add description here...</description>
  <version>1.0</version>
  <release>1</release>
  <vendor>Plesk</vendor>
  <url>http://your-company-web-site</url>
  <plesk_min_version>12.5.0</plesk_min_version>
</module>

The description of the available elements within the module node is as follows:

 

Conflict Resolution on Upgrade

When administrators upload a new version of an extension to Plesk, the possible conflicts between the existing and new files are resolved in the following way.

If one of these conflict resolution rules is not satisfied (for example, an existing file is blocked and cannot be overwritten), the upgrade procedure fails.

 

Removal Procedure

The following files are removed when an extension is removed:

Here PRODUCT_ROOT_D is /usr/local/psa on Linux systems and %plesk_dir% on Windows systems.

If an extension file cannot be removed, the removal procedure fails.

All files that are used by an extension should be removed by the pre-uninstall script.

 

Creating and Packaging Extensions

You can create the file structure necessary for an extension in one step, using the following command-line call:

plesk bin extension --create <EXTENSION_NAME>

Read more about the utility in the following documents:

With this utility, you can create a ready-for-distribution extension (by creating a ZIP archive of the extension file structure). The following call prepares the archive in the current directory:

plesk bin extension -p my-project

If you need to create an archive in a different directory, supply the utility call with the -destination /path/to/directory/ option.

 

Class Naming Conventions

The system allows to call your classes from almost all places of your code without preliminary requiring them. For this, you should properly name the classes and put the file which contains the class into a particular directory. This simplification is not necessary in most cases, it just makes your code more compact, but sometimes you are required to adhere to the naming conventions. For example, if you wish to add a dashboard widget, you are required follow the conventions because the system needs to automatically discover and load this class.

The naming conventions are as follows:

Zend uses a similar approach for auto-loading classes. Read more about it in http://framework.zend.com/manual/1.11/en/learning.autoloading.design.html .

Limitations

The auto-loading of classes does not work in the /htdocs/public/ directory. If you need this feature, start the auto-loading manually by adding the following code to the beginning of a file:

require_once('sdk.php');