Plugin Help Pages Source

1. Every Plugin Help Page should be categorized. Select the Categorize Tab and check "Documentation » Plugins". This allows all of the Plugin Help Pages to be displayed at the bottom of the page under Related Items
2. All of the Plugin Help Pages should have a Description - I use: The Plugin xxx Help Page
3. Most of the following should be included on every Plugin Help Page.

Introduction

Provide a short Introduction. This should briefly state what the Plugin does. I also like to include a link to the page DataPlugins.

History

Most of the Plugins originally came from TikiWiki but check the source file (I made sure that all of the Authors and their email address were correct). Lets give credit where it is due.
If it does come from TikiWiki - then search TikiWiki or the TikiWiki Doc Site for information on it. I don't know how to stress this enough - but don't rely on that source too heavily. The original idea and source may have came from TikiWiki - but every Plugins was rewritten for bitweaver and many operational changes were made! We did try to maintain backwards compatibility - but don't bet on it! The largest change was the inclusion of the variable $pluginParams['requires_pair'] => FALSE which allows a Plugin to be called without a ending Code Block. Most of the Plugins did not require an ending Code Blocks - so they were changed. Some parameter names were also changed. Again - Check the Code! You don't have to be able to write Php or JavaScript to understand what is going on here.
If you get stuck - you might try reading the Tutorial - Liberty Plugins. If you simply Can Not find the answer and need it Now - the faster response is the #bitweaver IRC channel on FreeNode. Slower methods include - the bitweaver Support Forum or sending an email to The bitweaver Developers Mailing List.
Finally - you just might find a bug during your efforts. I hope that isn't the case - but if it happens - Please Report It. The link to do that is bitweaver Bugs on SourceForge.net

Summary

Provide a more detailed explanation of what the Plugin does.

How It Works?

If the variable $pluginParams['requires_pair'] => TRUE then include:
This Plugin operates on the data placed between the Code Blocks - see the Heading Between The Code Blocks
If the variable $pluginParams['requires_pair'] => FALSE then include:
This Plugin operates with a single Code Blocks. That is - only a single call to the Plugin is required

Provide a brief explanation of how the Plugin operates. That should include when and where it's used.

The Plugin's Help

[+]

Between the Code Blocks

This heading is needed when a Plugins has the variable $pluginParams['requires_pair'] => TRUE
For those of you who don't know - when we say the word Code Block - we are referring to the way you call a Plugin. Some Plugins only use a single Code Block to operate while others need two. Examples are:

• {AGENTINFO info= } requires a Single Code Block
• {CODE source= num= }Source Code to be displayed{/CODE} requires Two Code Blocks. The first is {CODE source= num= } and the second is {/CODE}.

Nearly all Plugins that require 2 Code Blocks do so because they expect a lot of data and are designed to work on it.

Some Plugins use Key-Words or some other device between the Code Blocks. If this one does - you need to specify what it is and how it works like this:
The Data between the Code Blocks falls into three Classifications: Class A / Class B / & Class C.

• A Character Sequence is used to separate that Data into their appropriate Classes. By Default Character Sequence is *** but can be redefined with the Parameter SomeParameterName.
• Class A does this.
• Class B does that.
• Class C does the other thing.

Examples

Most of the examples demonstrate what the Plugin does by setting Parameters and explaining what they are there for. When there are a lot of parameters - this becomes difficult. One method - uses a build-up scheme to make sure everything is covered. Each Example adds a single parameter to those used in the previous Example. When a parameter has several options (Key Word parameters) then each is defined in a ))sub-heading((.

When a parameter does something unexpected or makes an exception that should be noted - make sure it is noticed. As an example - the Plugin PluginHelp was originally designed to use the required parameter plugin. A second (undocumented) parameter is being added and when used - the plugin parameter is ignored. It will take a lot of words to document that so that it will be not be misunderstood.

At any rate - be sure that each Example shows what is happening. Provide a box with the parameters being set. This is easily done by coping the WikiSyntax that calls the Plugin and placing it inside ~ np ~ blocks like this:
With some Plugins - this just does not work. If it doesn't - try replacing the { character with ~123~. When you do - remember that an all capitalized words are normally converted into links - so you will need to prevent that by placing )) characters in front of the Plugins Name and (( behind it. That means that our example should look something like this:

You might also decide to replace the trailing } character as well - even though it doesn't normally cause a problem. A trailing } character is replaced with ~125~. Our example would now look like this:

Since I had to play fast and loose to get those three examples to display right - here are our three examples as you would use them:
{AGENTINFO info='server' }
{AGENTINFO info='server' }
{AGENTINFO info='server' }