Info for Developers
1) How to develop your own plug-ins
You have found a place in Burning Board, where you need a specific function, you want to change an existing feature, or just add new features in WoltLab software? Then this is usually a good opportunity to develop a plugin for it. Plug-ins expand our software easily to get custom functions that are not included in the standard installation. The advantage of plugins is obvious: simple installation or un-installation (no more fumbling in the source code), easily updatable and shareable with other users as well as sellable.
"Plug-ins" are extensions for your Burning Board forum software. They broaden the software with features that it doesn't bring from house, or alters its functions. Plugins are available in the form of a TAR archive, in which different files and subfolders as well as graphics can be included varying by plug-in.
Creating plugins is of course primarily programming work. However, you should not be a beginner in web programming, since our requirements for plug-ins are at a certain quality level. We are guided by applicable standards and put the developers to adhere close to that. In principle, knowledge of various web scripting languages, object-oriented programming, databases, and package management systems are advantageous.
In general, for the development of plug-ins skills in the use of PHP, OOP, MySQL, XML, XHTML und CSS are needed. Various examples and guidance for the actual construction of plugins provides the Technical Documentation (at this time English only).
Depending on the project, special software needed for the plug-in development may be needed, such as a code editor with syntax coloring and code completion, version control, image processing and compression software to create TAR archives, and of course the software from WoltLab. Get used to a clear, orderly and structured way of working, save your work regularly and create versions in order to have access to old states on demand. Bring enough patience! Finally, the most important thing: Test your plugin extensively under different circumstances!
2) Requirements for plug-ins
Shape the surface of your plug-ins visually appealing! Stay as close as possible to the already existing interface elements. This benefits the customers too, providing them a unified user experience.
Plugins uploaded tn the Plugin Store are being examined grossly for defects by us prior to their activation. It is both an automatic testing (search for syntax errors in PHP and XML files, searching for missing files), as well as a manual control (search for serious errors, especially security vulnerabilities, such as SQL injections or XSS vulnerabilities, serious violations of applicable standards).
Here is a summary of important points to note:
- Correct name
- Valid code syntax
- Valid XHTML 1.1
- Valid CSS
- Observe the correct dependencies
- Minimal SQL queries
- Pay attention to security gaps
- Enclose all necessary files in the package
- Avoid hidden files in the package
- Respect the licenses of included files
- Keep the accessibility
- Clear visual preparation
- Follow the WoltLab design specifications
- Does the package install?
- Does everything work as planned?
- Testing, testing, testing!
3) Where can I find documentations?
On the WoltLab site, see the Support section with our documentation and useful documents. In our WoltLab Support Forum is a separate area for the plugin goals and developers. In addition, see the WoltLab Community Forum with the special developer area and its "How-to?" section. Over time you will find more documents here.
4) The plug-in icon
The plug-in icon should have the dimensions of 24x24 pixels and ideally be available as PNG image.
If you want to create your own artwork, you have the option to use our icon template file (requires Adobe Photoshop or similar image editing software) and put your image between the predetermined locked layers. Then save the image as PNG to preserve the transparency. Alternatively, you can also create your own icon without our template. A small piece of advice: You should design the graphics, like our templates, with rounded corners, so that users have a consistent interface experience and immediately recognize plug-ins as such.
If you do not feel comfortable in dealing with graphics, or do not have a suitable image editing program, you don't have to attach an icon to your plug-in. The system detects that no graphics where given when uploading and then provides your plug-in the default icon for plug-ins.
5) The plug-in description
Plugins should be as simple as possible, yet well characterized. A too detailed and comprehensive description makes it difficult for the users to find what they need and can cause more confusion than clarity.
The input field for the description lacks a WYSIWYG editor, because the descriptions should not be overstyled. If you still need formatting, you can manually add some BBCodes, which are also available in the forum. The following BBCodes are being supported: [b], [i], [u], [s], [size=x], [color=#xxx], [list] & [*].
Use formatting sparingly, do not use very large font sizes and don't color complete text passages! A good description is usually made without any formatting. If you need to describe your plug-in more detailed and with much more elaborate formatting, you should do so on your own site.
Plugin descriptions must be created in English and German. Remember that your plug-ins are used by a growing number of international users, which increases the awareness of your plug-ins. International communication can only be done in English and foreign language visitors of the Plugin Store are only able to find and download your plug-in if the description is also available in English. If you are not good in English, or do not feel confident in translating complex descriptions, use Google Translate, the results are often very good and quite sufficient. A poor English description is better than none. If you know someone in your environment who has good English language knowledge, you might also ask whether he'll translate your text, or correct the text provided by Google Translate.
6) Plugin-cover and screenshots
When you upload a plugin it is possible to upload screenshots or other images. You can upload up to 10 images.
Note: The first image in the list of the screenshots is automatically being used as cover image for the description page of the plugin by the system.
If you use another image as cover image, then you should upload the pictures in the correct order. If you have accidentally uploaded the images in the wrong order, you can edit the plugin project and bring the screenshots in the right order by moving, so that a meaningful title image is displayed.
7) Versions and their management
If you have developed your plug-in further, then you have a new version and you can upload that as new version into your plugin project, so that customers can download this version. Older plug-in versions are listed on a separate versions page and can still be downloaded. All versions are equipped with date and version number to distinguish them from recent versions.
You can write release notes for each version to explain to users what has changed in the current version. Here, the same considerations apply as with plug-in descriptions, less is usually more. The best representation for Release Notes is a list, listing the various changes line by line.
8) Information about plug-in licenses
A license is a set of rules, which the customer must accept in order to use the plugin and which he must comply with. Violations can have legal consequences and should therefore be avoided. Choose the license under which you want to release your plug-in carefully!
The Plugin Store provides a set of predefined licenses in a drop-down menu to choose from. You can also specify a link to your own license if your required license is not there.
