From B2evolution

[edit] File layout

A plugin that is named "example" must be put into a file _example.plugin.php and the class defined in that file must be named "example_plugin" and extend the Plugin class.

class example_plugin extends Plugin
{
}

This file can be put directly into the plugins/ folder, but the preferred method is to use an additional folder (named after the plugin classname).

Any other files a plugin provides, like additional data (fonts, images, stylesheets) or documentation, must be put into a subfolder named after the plugin. In the above case this would be example_plugin/. Therefor it is better to also put the plugin class file there in the first place.

[edit] Filenames and their meaning in the plugin's subfolder

[edit] README.html, README.XX.html

If found, it gets automagically linked as online help and can be used by the plugin to link to from its Settings (see [1]) or if there a special html-IDs in it, these links get created automagically.

First it gets looked for an localized version in the user's language (e.g. README.de.html for german) and README.html gets used as fallback and should therefor be written in English.

See PluginDocumentation for more details.

[edit] Plugin classname

The plugin classname ("example_plugin" above) should be quite unique, because it's the "key" to the plugin's source: you cannot have different plugins with the same classname installed. So, make sure that it's meaningful and is not likely to conflict with plugins from other authors.

The classname is limited to 40 characters (including the "_plugin" suffix).

[edit] Database tables

[edit] Database table names

To keep the database clean/organized, you should use Plugin::get_sql_table(), which returns a canonical prefix (e.g. "evo_plugin_test_7_" for the test_plugin with ID 7).

[edit] Creating database tables

If you want to use database tables in your plugin, you should provide a Plugin::GetDbLayout() method, which defines what tables you want to use.

Then, on installation of the plugin, the admin gets informed that the tables need to be created, which is done after he confirmed it.

[edit] Dropping database tables

When a plugin gets uninstalled, all database tables, which are prefixed with what Plugin::get_sql_table() returns, are being dropped automatically (after the admin confirmed) it.

[edit] Backoffice

To implement functionality in the backoffice/admin area, there are several methods.

[edit] Tools tab

To register an entry in the Tools tab, hook the method AdminAfterMenuInit and register your tab:

function AdminAfterMenuInit()
{
  $this->register_menu_entry( 'Title of my tab' );
}

Then, implement the methods AdminTabAction and AdminTabPayload.

[edit] Use prefixes

If your plugin includes an external class (in the same source file as the Plugin's class) or are using global variables (which is a bad idea in general), you should prefix the classname/variables with your plugin's name. E.g., your plugin uses a class XmlToArray and you provide this class in your plugin's source code file. Then you should rename the class to example_plugin_XmlToArray.

[edit] Localization

You can make your plugin ready for translation: just use the Plugin::T_() method around your original, english strings and follow this guide to generate the necessary files with translated strings.

[edit] Example

See the shipped Test Plugin for more details.