xpi plugin system

A newer extension of ewiki (namely plugins/feature/xpi) allows to store
addon functions in the database (the code is saved as _BINARY db entry
where usually page text was stored). The "PlugInstall" page allows to load
the extension code from (even remotely located) .xpi files into the
database, from where it can be used later.
In order to use once installed xpi code, only the "feature/xpi0.php"
plugin was needed.

Through the design of the xpi feature extension nearly all plugins could
be converted and installed in the .xpi format. Though this doesn't make
sense for database backends, and converting all to-date plugins is silly.
So this feature is further merely used for fun and mini-extensions.

You could easily write your own .xpi plugins using the description in the
"tools/mkxpi" script. First you need to create a .src file with the plugin
code as usual (write it like an ordinary plugin script, except for page
plugins), and a few meta: informations on top of that file. Then the mkxpi
tool converts this in the binary .xpi format for distribution and
installation.
Typically this would look like:

  id: UniqueExtensionName+
  type: actionlink_and_textdata
  license: Free to use
  author: PutYourNameHere+
  description: adds the search/ action to the control-links line
  icon: data:image/png;base64,iVBORw0KGgoAAAANS...
  code: <?php
     // just look'n'feel settings, no real plugin code here...
     $ewiki_config["action_links"]["view"]["search"] = "SEARCH_ACTION";
     $ewiki_t["en"]["SEARCH_ACTION"] = "search in other pages";
     $ewiki_t["de"]["SEARCH_ACTION"] = "woanders suchen";
  ?>

Most of the fields are optional (author, license, description and of course
icon) but senseful. The type: is required, but only a value of "page" has
a special meaning here (otherwise is merely descriptive). The id: gives that
plugin an internal identifier which will later be used for storing the
extension with a database-wide unique name; for "page" type plugins it of
course would be the name under which it was installed.

The code: contains the usual plugin registration and function definition
code. But for "page" xpi plugins it may not have a function body, but lots
of 'echo' calls to output the dynamic pages contents when called (no return
allowed in this incarnation of page plugins). After this no other fields
should appear.

Future .xpi versions may allow to embed other files for instant installation
(maybe image files for storage in database). But until now onle the code:
entry carries data which will be installed as database page. All the other
meta entries (id, type, author, ...) will however be stored in the xpi
registry database entry, which is also used to control the enable/disable
flag for each of it (only page plugins cannot be disabled).

To share your own extensions simply send them to one of the core project
developers (Andy or Mario) or just leave a link on the "XpiPlugins+" page:
http://erfurtwiki.sourceforge.net/?XpiPlugins

because that way users will immediately see it when remotely installing
.xpi plugins from that default xpi plugin repository. It may be an
security risk for users if they install code from unchecked sources, but
the complete URL is always displayed right before storing the external
code into the database.

The most interesting part of the .xpi system (PlugInstall page) is the
possibility to later disable or remove extensions easily. You only need
to setup the administrator password to install and control click-and-run
extensions without hacking the 'config.php'.



   ------------------------------------------------------------------ 5 ---

prev << "your own block markup plugin"
next >> "mysql database structure"

---

You cannot modify the INTERNALS file, but anyhow any ideas or suggestion should as usually get filed on BugReports, UserSuggestions or even better the INTERNALS.Discussion.