Submit Your New Plesk Extension to Plesk Extensions catalog

Develop Plesk Extensions Series: Submit your extension to the official Plesk Extensions Catalog

In the first three parts of this series we’ve learned how to install Plesk locally, setup the development environment properly and how to write the first Plesk extensions. Today I will show you how to submit your shiny new extension to the official Plesk Extension Catalog. It’s up to you, make Plesk users happy and become famous!

Part 4 – Submit your extension to the official Plesk Extension Catalog

It’s not really hard to submit an extension to Plesk’s Extension Team if you follow a checklist that the team has provided on their submission page. Let’s go through the list together and clarify each point:

Your extension should be packaged in zip archive.

This one is easy. Select all files that belong to the extension and compress them into an zip archive. You can use the build-in compress feature of your OS or an external archive program for this purpose.

Tipp: If you are using a MacBook (iOS), then you can use the free app YemuZip to get rid of the iOS-specific hidden files and folders in the archive using the “PC” option.

The archive should not contain unused files. When the extension is uploaded in Plesk there should be no warnings about unused files found.

See my comment above. Get sure that you don’t add folders or files that are not used by Plesk, e.g. the PhpStorm project folder. You should test the upload and installation processes for each Plesk and OS version before submitting your extension!

The archive should contain meta.xml file with valid description.

Without the meta.xml your extension won’t work. The XML code must be both well-formed and valid, this means that it follows a defined structure. Check existing extensions or use the extension stubs to create a correct manifest file.

Extension description should contain at least one sentence. It’s recommended to use two or three sentences for proper explanation of the idea behind your extension.

I think this is self explanatory. The better your description is the more likely users will install and use it! Describe exactly what the extension contains and what the user can do with it.

Extension name and description should be in English. It’s possible to provide translations into other languages as long English is present.

Always use English in your extension and provide local language files directly in your package. Place the files in plib/resources/locales. It you share your code on a collaboration platform, such as GitHub, then it makes sense to write also your comments in English. In general, it always makes sense but you should know it! 😉

Extension UI must have full English language support. It’s possible to provide UI translations into other languages as long English is present.

See my comment above!

Your extension should have icons in .png format.
32×32 icon location: _meta/icons/32×32.png
64×64 icon location: _meta/icons/64×64.png

Download a free icon or create an own icon with the help of an image program or an online icon generator.

Your extension should have at least one screenshot (1024х768 size) in .png format. It’s possible to provide up to three screenshots.
Screenshots location: _meta/screenshots/
Screenshot names should be: 1.png, 2.png, 3.png

Create screenshots from your extension and add them you the package. You may use just 3 screenshots, so try to depict the most important parts of your extension which will help the users to choose your extension!

If your extension works only on Linux or Windows (or was tested on only one platform), this should be stated in meta.xml.

Add this information into the description and also to the email that you write to the Plesk team. It’s important else the team will test you extension on the other operation system as well and reject your submission. For instance, if your extension only runs on Unix systems, then you should add to the meta.xml:

Your extension should only use API calls described in official documentation. Private API calls not described in the documentation should not be used.

Use the provided API calls from the Plesk developers. Take a look to part 2 of this tutorial where I describe how to add the API stubs to your project.

Don’t use external calls which can not be verified by the team. If you integrate your private service, then make the API transparent and provide all needed details to the Plesk team so that they can check your integration thoroughly.

Last but not least, write good and clean code what makes it easier for the team to check it and speeds up the successful inclusion in the catalog.

Plesk Extension team will review your extension and contact you with the result

Once submitted, the team will review your submission and either add your extension into the catalog or write you an email with issues that have to be corrected. Don’t hesitate to contact the team at any time if you have questions regarding the correct submission process.

You can find the submission form and all important information here: Submit Your Extension.

All right, I wish you a great journey with Plesk and looking forward to some great extensions from you.

Stay Plesky!

About

Leave a Comment

Start typing and press Enter to search