getMinNucleusVersion
appropriately.
Back to the developer docs index
This document contains information on how you can write your own Nucleus plugins
NucleusPlugin
class<%plugin(...)%>
skinvar<%plugin(...)%>
templatevaraction.php
Nucleus plugins allow just about anyone to extend the functionality that Nucleus offers, without having to alter the PHP code itself. Plugins are simple php scripts that must implement certain methods, and can easily be exchanged between Nucleus users. Installing goes as easy as adding the plugin file to the plugin directory and letting Nucleus know it's there.
Some advantages of plugins are listed below:
All plugin files should be placed in the directory that is listed in config.php
. Commonly, this will be /your/path/nucleus/plugins/
. Plugin files can be recognized by their form: NP_name.php
. Some plugins require a subdirectory with the same name to store extra files or their admin area.
NP_
, not Np_
or np_
. Also note that when the plugin uses a subdirectory, the name of that directory should be all lowercase.
Ok, lets start by writing a simple plugin. Basically, each plugin is a PHP class that inherits from the predefined class NucleusPlugin
. Below is an example of a HelloWorld
-plugin:
<?php
class NP_HelloWorld extends NucleusPlugin
{
// name of plugin
function getName()
{
return 'Hello World';
}
// author of plugin
function getAuthor()
{
return 'Wouter Demuynck';
}
// an URL to the plugin website
// can also be of the form mailto:foo@bar.com
function getURL()
{
return 'http://nucleuscms.org/';
}
// version of the plugin
function getVersion()
{
return '1.0';
}
// a description to be shown on the installed plugins listing
function getDescription()
{
return 'Just a sample plugin.';
}
function doSkinVar($skinType)
{
echo 'Hello World!';
}
function supportsFeature ($what)
{
switch ($what)
{
case 'SqlTablePrefix':
return 1;
default:
return 0;
}
}
}
?>
NP_HelloWorld.php
, and put it in your plugins directory. Make sure that there are no spaces after the last ?>
or before the first <?php
.. NP stands for "Nucleus Plugin", if you were wondering about that.
<%HelloWorld%>
Note that the name (HelloWorld
) is case sensitive!
plugin
-skinvar.So, that wasn't so hard after all. Read on to find out more.
All Nucleus plugins must inherit from the PHP class NucleusPlugin
. If this sounds complicated, don't worry, it isn't. It even makes your life easier, allowing you to only implement the methods that your plugin needs, and giving access to some auxiliary functions.
Below is an overview of the methods that the NucleusPlugin
offers, and that you can re-implement in your own plugin. If you want to see the source of the class itsself, it's located at nucleus/libs/PLUGIN.php
Method Signature | Explanation |
---|---|
getName() |
Returns the name of the plugin. This will be the name that will show up on the list of installed plugins. You should definately redefine this method, since the default implementation returns Undefined |
getAuthor() |
Returns the name of author of the plugin. This name will show up on the list of installed plugins. You should definately redefine this method, since the default implementation returns Undefined |
getURL() |
Returns the URL of the site where the plugin can be downloaded, or where additional information about the plugin can be found. If no such site exists, a mailto: -link with the authors email address is appropriate. You should definately redefine this method, since the default implementation returns Undefined |
getDescription() |
Returns a longer description of the plugin. This will show up on the list of installed plugins. The default implementation returns Undefined |
getVersion() |
Returns the current version of the plugin. Returns 0.0by default |
getMinNucleusVersion() |
(v2.0b) Returns the minimum required Nucleus version. By default, this returns 155 (v1.55). If you are using plugin features that were introduced later, please implement this function (e.g. v2.0 => 200). Please note that Nucleus v1.55 does not use this function at all, so it remains possible to install newer plugins there, even if they use newer features. |
getMinNucleusPatchLevel() |
(v3.1) Returns the minimum required Nucleus patch level that needs to be present when running the minimal required Nucleus version (getMinNucleusVersion ). By default, this returns 0 . This function is generally used when new plugin features are available only as patches to the latest released Nucleus version. |
init() |
Initializes the plugin. This method gets called immediately after the plugin object is created and the plugid -attribute has been set. By default, this method does nothing. |
doSkinVar($skinType) |
When plugins are called using the <%plugin(...)%> -skinvar, this method will be called. the $skinType parameter contains the type of skin (item , archive , ...) from where the plugin is called. Don't get confused by the fact that there's only one parameter. Multiple parameters can still be passed. More info on implementing the doSkinVar method. By default, this method does no output at all. |
doTemplateVar(&$item) |
Basically the same as doSkinVar , but this time for calls of the <%plugin(...)%>-var in templates (item header/body/footer and dateheader/footer). By default, this method forwards the handling to the doSkinVar -method, using template as skintype. More information on implementing the doTemplateVar method |
doTemplateCommentsVar(&$item, &$comment) |
(v2.0b) Basically the same as doSkinVar , but this time for calls of the <%plugin(...)%>-var in templates (comments-related parts). By default, this method forwards the handling to the doSkinVar -method, using template as skintype. More information on implementing the doTemplateCommentsVar method |
doAction($type) |
When a plugin wants to allow user interaction, it can allow actions through action.php . This is the script that Nucleus uses itself to handle new comments and karma votes. Called with the correct parameters, the doAction -method from a plugin can be called. The $type contains an optional message type. Extra variables from the request can be accessed from within the doAction method. By default, this method returns a string No Such Actionwhich will trigger an error message. More info on doAction . |
install() |
This method gets called on the moment the plugin is installed. It can perform initializing actions, such as the creation of database tables, the creation of plugin options, etc... By default, this method does nothing. |
unInstall() |
Called when the plugin is uninstalled. It's a good thing to clean up information your plugin created in the database at this point. By default, this method does nothing. |
getEventList() |
Plugins can subscribe to events. Events get generated whenever Nucleus performs a certain action. An AddItem event for example, will call all plugins that subscribed to this event. The called method will be event_AddItem($params) . The $params -parameter is an associative array containing several fields of information, like the itemid for AddItem . Returns an empty array by default, indicating that the plugin does not subscribe to any event at all. More information about events. |
getTableList() |
This method should return an array of database tables that the plugin has created. It's used in the backup feature that Nucleus offers, so plugin tables are also included in the backup. By default, returns an empty array. |
hasAdminArea() |
Should return 1 if the plugin has an admin area of its own, and 0 if it doesn't. By default, 0 is returned. |
getPluginDep() |
(v3.2) Returns an array of plugin names. Nucleus refuses to install the plugin if any of these plugins is not installed. By default, an empty array is returned. More information on plugin dependencies. |
Next to the methods that can be implemented, the class NucleusPlugin
offers some extra methods which you should not implement yourself. They can be called from within your plugin using the $this->functionName()
syntax.
Method Signature | Explanation |
---|---|
createOption(...)
createBlogOption(...) (v2.2)
createCategoryOption(...) (v2.2)
createMemberOption(...) (v2.2)
createItemOption(...) (v3.2)
|
Creates a new option |
deleteOption(...)
deleteBlogOption(...) (v2.2)
deleteCategoryOption(...) (v2.2)
deleteMemberOption(...) (v2.2)
deleteItemOption(...) (v3.2)
|
Deletes an option |
setOption(...)
setBlogOption(...) (v2.2)
setCategoryOption(...) (v2.2)
setMemberOption(...) (v2.2)
setItemOption(...) (v3.2)
|
Sets the value of an option |
getOption(...)
getBlogOption(...) (v2.2)
getCategoryOption(...) (v2.2)
getMemberOption(...) (v2.2)
getItemOption(...) (v3.2)
|
Retrieves the value of an option |
getAllBlogOptions(...) (v2.2)
getAllCategoryOptions(...) (v2.2)
getAllMemberOptions(...) (v2.2)
getAllItemOptions(...) (v3.2)
|
For a given option, returns an associative of all values (one value per context) |
getBlogOptionTop(...) (v3.2)
getMemberOptionTop(...) (v3.2)
getCategoryOptionTop(...) (v3.2)
getItemOptionTop(...) (v3.2)
|
For a given option, returns the top of all values |
getID() |
Returns the ID for this plugin (this is the ID internally used inside Nucleus) |
getAdminURL() |
Returns the URL of where the admin area of the plugin is located (if there is no such admin area, this information is invalid) |
getDirectory() |
Returns the path in the servers filesystem where the extra files for the plugin are stored (if there are no such files, this information makes no sense). The result is something like ".../nucleus/plugins/plugname/ " |
getShortName() |
Returns the part of the plugin classname without the "NP_ "-part, and in all-lowercase. This information is used in the functions getAdminURL and getDirectory |
You can create your own skinvars, and call them using <%plugin(PlugName,parameters)%>
or <%PlugName(parameters)%>
(when this does not conflict with an existing skinvar). Parameters are comma-separated.
To handle skinvars, you'll need to implement the doSkinVar
method. Some samples of signatures are given below:
function doSkinVar($skinType)
function doSkinVar($skinType, $param1, $param2)
function doSkinVar($skinType, $skinVar, $param1, $param2)
function doSkinVar($skinType, $skinVar, $param1 = 'default value')
$skinType
parameter will be one of 'index', 'item', 'archive', 'archivelist', 'member', 'error', 'search', 'imagepopup' or 'template'$skinVar
is actually the first parameter that's being interpreted as a type of skinvar (e.g. <%plugin(PlugName,VarType)%>
)doSkinVar()
(no parameters) and retrieve the parameters using the PHP function func_get_args()
. Could be handy if you have different types of skinvars with different numbers of arguments$currentSkinName
Template plugin variables work in the same way as skin plugin vars. There are two differences:
$skinType
parameter. Instead, they take extra parameters with info on the item and comment that is currently being parsed:
doTemplateVar
-method gets a &$item
parameter.doTemplateCommentsVar
-method gets an &$item
parameter as well as a &$comment
parameter.Template variables are called in exactly the same way as skinvars (using <%plugin(PlugName,parameters)%>
or <%PlugName(parameters)%>
)
By default, all template variables are passed on to the doSkinVar
-method, using 'template
' as skinType
-parameter.
If you want to provide your own implementation, you'll need to redefine the method doTemplateVar
and/or doTemplateCommentsVar
. It works in the same way as doSkinVar
, except that now the skinType
-parameter is missing.
function doTemplateVar(&$item)
function doTemplateVar(&$item, $param1, $param2)
function doTemplateVar(&$item, $type, $param1, $param2)
function doTemplateVar(&$item, $type, $param1 = 'default value')
function doTemplateCommentsVar(&$item, &$comment)
function doTemplateCommentsVar(&$item, &$comment, $param1, $param2)
function doTemplateCommentsVar(&$item, &$comment, $type, $param1, $param2)
function doTemplateCommentsVar(&$item, &$comment, $type, $param1 = 'default value')
$currentTemplateName
Plugins can perform actions through action.php
, the same script that's being used to receive comments and karma votes. You can call it using both GET and POST methods. Required parameters are action
(should be 'plugin'), name
(name of the plugin) and type
(type of requested action)
To enable these actions, you should implement the doAction($actionType)
method in your plugin. Extra parameters from the request can be received using requestVar('name')
(requestVar
takes care of magic_quotes_gpc that PHP might have added)
When your doAction
method returns a string, it will be interpreted as an error, and an error message will be shown.
Nucleus Plugins can subscribe to events that occur whenever something important happens. The plugin can then execute some actions, or output some text.
Below is an example of how a plugin subscribes to the PreAddComment
-event, an event that is generated immediately before a comment is added to a blog.
class NP_Acronyms extends NucleusPlugin {
...
function getEventList() { return array('PreAddComment'); }
...
function event_PreAddComment(&$data) {
// replace acronym HTML
$data['comment']['body'] =
strreplace('HTML',
'<acronym title="HyperText Markup Language">HTML</acronym>',
$data['comment']['body']);
}
}
This plugin replaces the text HTML
in each comment by the text <acronym title="HyperText Markup Language">HTML</acronym>
. The acronym
-tag is a HTML-tag that allows authors to provide extra information on acronyms.
Here's the steps you need to take to subscribe to an event:
getEventList
-methodevent_EventName($data)
, in which the handling of the event is doneMultiple plugins can subscribe to the same event. The order in which these plugins are notified is the same order as the ordening in the plugin list of the admin area. Plugins higher in the list get notified earlier on.
The event_EventName
-method gets only one parameter, $data
, of which the contents differs depending on the event. It is an associative array with data. Objects and arrays that are passed in this array, are passed by reference, so the changes you make there will be remembered.
The event list below uses some colors to indicate if changes in the parameters will be seen by nucleus or not:
Objects that are passed as parameters are indicates as follows: object. Most objects are also passed by reference, making them look like object by ref
Name | When | Parameters |
---|---|---|
InitSkinParse | Just before the skin is initialized |
|
PreSkinParse | Immediately before the parsing of a skin begins |
|
PostSkinParse | Immediately after parsing a skin |
|
PreItem | Before an item is parsed, but after the item header has been placed |
|
PostItem | After an item has been parsed, but before the item footer has been parsed |
|
PreComment | Before a comment is shown |
|
PostComment | After a comment has been shown |
|
PreDateHead | Before a date header is shown |
|
PostDateHead | After a date header has been parsed |
|
PreDateFoot | Before a date footer is parsed |
|
PostDateFoot | After a date footer has been parsed |
|
LoginSuccess | After a successful login |
|
LoginFailed | After a failed login |
|
Logout | After logout |
|
PreBlogContent | Before blog content has been inserted through a skinvar |
|
PostBlogContent | After blog content has been inserted through a skinvar |
|
PreAddComment | Before adding a comment to the database |
|
PostAddComment | After adding a comment to the database |
|
PostRegister | After a new user has registered |
|
PostAddItem | After an item has been added to the database |
|
PostUpdateItem | Immediately after an item gets updates in the database |
|
PreAddItem | Immediately before an item is added to the database |
|
PreUpdateItem | Immediately before an item gets updates in the database |
|
PrepareItemForEdit | Called after getting an item from the database, and before presenting it to the user to be edited. |
|
PreUpdateComment | Immediately before a comment is updated and saved into the database |
|
PrepareCommentForEdit | After a comment is retrieved from the database, and before it is presented to the user to be edited. |
|
PrePluginOptionsEdit |
(v2.0b) before the 'edit plugin options' form is created.
(v2.2) extra parameters (v3.2) extra parameter for every option |
|
PrePluginOptionsUpdate | (v3.2) Before the options for a plugin have been updated. (using this event you can validate/change the new value for an option) |
|
PostPluginOptionsUpdate |
(v2.0b) After the options for a plugin have been updated.
(v2.2) Different parameters depending on context |
|
PostAuthentication | (v2.0b) After the login procedure has been completed. This occurs on each page request. |
|
PreAddItemForm | (v2.0b) Immediately before an add item form (bookmarklet or admin area) is created. |
|
AddItemFormExtras | (v2.0b) Somewhere inside the add item page or bookmarklet. Here, plugins can add their custom fields without having to alter one of the .template files. |
|
EditItemFormExtras |
(v2.0b) Somewhere inside the edit item page or bookmarklet. Here, plugins can add their custom fields without having to alter one of the .template files.
Don't add too much data, and please generate valid XHTML, looking like this:
This way, multiple plugins can add options here while things keep a good structure. Also try to use prefixes for your fieldnames, in order to avoid nameclashes (e.g. plug_tb_url )
|
|
BlogSettingsFormExtras | (v2.0) On the blog settings page. You can add your own forms here.
Don't add too much data, and please generate valid XHTML, looking like this:
This way, multiple plugins can add options here while things keep a good structure. Also try to use prefixes for your fieldnames, in order to avoid nameclashes (e.g. plug_tb_url )
|
|
PreDeleteItem | (v2.0) Immediately before an item gets deleted in the database |
|
PostDeleteItem | (v2.0) Immediately after an item has been deleted in the database |
|
PreDeleteCategory | (v2.0) Immediately before a category gets deleted from the database |
|
PostDeleteCategory | (v2.0) Immediately after a category has been deleted from the database |
|
PreDeleteBlog | (v2.0) Immediately before a blog gets deleted from the database |
|
PostDeleteBlog | (v2.0) Immediately after a blog has been deleted from the database |
|
PreDeleteMember | (v2.0) Immediately before a member gets deleted from the database |
|
PostDeleteMember | (v2.0) Immediately after a member has been deleted from the database |
|
PreDeleteTeamMember | (v2.0) Immediately before a member gets deleted from a weblog team |
|
PostDeleteTeamMember | (v2.0) Immediately after a member has been deleted from a weblog team |
|
PreDeleteComment | (v2.0) Immediately before a comment gets deleted from the database |
|
PostDeleteComment | (v2.0) Immediately after a comment has been deleted from the database |
|
ActionLogCleared | (v2.0) After the action log has been cleared | None |
PreDeleteTemplate | (v2.0) Immediately before a template gets deleted from the database |
|
PostDeleteTemplate | (v2.0) Immediately after a template has been deleted from the database |
|
PreDeleteSkin | (v2.0) Immediately before a skin gets deleted from the database |
|
PostDeleteSkin | (v2.0) Immediately after a skin has been deleted from the database |
|
PreDeletePlugin | (v2.0) Immediately before a plugin gets deleted from the database |
|
PostDeletePlugin | (v2.0) Immediately after a plugin has been deleted from the database |
|
PreDeleteBan | (v2.0) Immediately before an IP ban gets deleted from the database |
|
PostDeleteBan | (v2.0) Immediately after an IP ban has been deleted from the database |
|
PreAddCategory | (v2.0) Immediately before a new category is created in the database |
|
PostAddCategory | (v2.0) Immediately after a new category has been created in the database |
|
PreAddBlog | (v2.0) Immediately before a new blog is created |
|
PostAddBlog | (v2.0) Immediately after a new blog has been created |
|
PreAddPlugin | (v2.0) Immediately before a plugin is added |
|
PostAddPlugin | (v2.0) Immediately after a plugin has been added |
|
PreAddTeamMember | (v2.0) Immediately before a member gets added to a blog team |
|
PostAddTeamMember | (v2.0) Immediately after a member has been added to a blog team |
|
PreAddTemplate | (v2.0) Immediately before a new template is created (note: this one also gets called when a template is cloned)) |
|
PostAddTemplate | (v2.0) Immediately after a new template has been created |
|
PreAddSkin | (v2.0) Immediately before a new skin is created (note: this one also gets called when a skin is cloned)) |
|
PostAddSkin | (v2.0) Immediately after a new skin has been created |
|
PreAddBan | (v2.0) Immediately before a new ban is added to a weblog |
|
PostAddBan | (v2.0) Immediately after a new ban has been added |
|
PreMoveItem | (v2.0) Immediately before an item is moved to another blog/category |
|
PostMoveItem | (v2.0) Immediately after an item has been moved to another blog/category |
|
PreMoveCategory | (v2.0) Immediately before a catgeory is moved to another blog |
|
PostMoveCategory | (v2.0) Immediately after a catgeory has been moved to another blog |
|
MemberSettingsFormExtras | (v2.0) On the member settings page. You can add your own forms here.
Don't add too much data, and please generate valid XHTML, looking like this:
This way, multiple plugins can add options here while things keep a good structure. Also try to use prefixes for your fieldnames, in order to avoid nameclashes (e.g. plug_tb_url )
|
|
GeneralSettingsFormExtras | (v2.0) On the general settings page. You can add your own forms here.
Don't add too much data, and please generate valid XHTML, looking like this:
This way, multiple plugins can add options here while things keep a good structure. Also try to use prefixes for your fieldnames, in order to avoid nameclashes (e.g. plug_tb_url )
|
None |
AdminPrePageHead | (v2.5) On admin area pages, immediately before the page head is printed. This event could be used to add extra script/css includes in the head section |
|
AdminPrePageFoot | (v2.5) On admin area pages, immediately before the page footer is printed. |
|
PreSendContentType | (v2.5) Immediately before a content type is being set in the HTTP header |
|
QuickMenu | (v2.5) At the end of the Admin Area quick menu. This can be used to add extra plugin entries. To add entries, push associative arrays on the options array. An example can be found in the section about creating a plugin admin area. |
|
BookmarkletExtraHead | (v2.5) Somewhere inside the head section of the bookmarklet XHTML code. |
|
FormExtra | (v3.2) Inside one of the comment, membermail or account activation forms. This event allows plugins to insert extra fields in the form. This event corresponds with the ValidateForm event that is fires when the form is handled. |
|
ValidateForm | (v3.2) Called when one of the comment, membermail or account activation forms is being handled. This event allows plugins to perform their own validation on the data, and prevent further handling if something is wrong. When used together with the FormExtra field, it can be used to add extra fields to forms. |
|
A series of methods are offered to make it easy for plugins to set and retrieve options. These options can be directly edited from inside the Nucleus admin area, taking the need away for the plugin to provide an admin area of its own, and avoiding that options need to be set inside the PHP file itself.
Options are available in different contexts:
Several types of options are provided
yes
' or the value 'no
' (on edit, shown as radio button)Option 1|value1|Option 2|value2|Option 3|value3
As of Nucleus v3.2, some option types can be limited to only accept certain values using option-metadata. This metadata is stored in the $typeExtras
-field, and is a semicolon-seperated list of values. Note: In a select-option, the select list must be the first value in $typeExtras
.
key | explanation |
---|---|
datatype |
Using 'datatype ' you can give some extra hints to Nucleus about the datatype you want to use. Currently only 'numerical ' is available. 'numerical ' will cause Nucleus to only accept numerical values for this option (using both client-side and server-side check) (available for optiontypes: 'select ' and 'text ') |
access |
If set to 'readonly ', the option will not be editable (available for optiontypes: 'text ' and 'textarea ')If set to ' hidden ', the option will be completely hidden for the end-user (available for optiontypes: 'text ') |
some examples:
// following code creates a text-option that only accepts numerical values
$this->createBlogOption('FooBar', 'foobar', 'text', '0', 'datatype=numerical');
// following code creates a select-option that only accepts numerical values
$this->createItemOption('FooBar', 'foobar', 'select', '0', '0|0|1|1|2|2;datatype=numerical');
// following code creates a textarea-option that is readonly
$this->createOption('FooBar', 'foobar', 'textarea', 'This textarea is readonly', 'access=readonly');
Creates a new option in the global context
parameter | value |
---|---|
$name | Option name |
$desc | Textual description, to be shown on the page where options can be edited |
$type | Option type (see above) |
$defValue | Initial value |
$typeExtras | Extra info on option type (see above) |
Creates an option in the blog context (see createOption
)
Creates an option in the category
context (see createOption
)
Creates an option in the member
context (see createOption
)
Creates an option in the item
context (see createOption
)
changes the value of an option that was already in the database
parameter | value |
---|---|
$name | Option name |
$value | New value for option |
Changes the value for a blog option. The blogid
attribute indicates for which blog the option is valid. (other options: see setOption
)
Changes the value for a category option. The catid
attribute indicates for which category the option is valid. (other options: see setOption
)
Changes the value for a member option. The memberid
attribute indicates for which member the option is valid. (other options: see setOption
)
Changes the value for an item option. The itemid
attribute indicates for which item the option is valid. (other options: see setOption
)
Returns the value for an option in the database
parameter | value |
---|---|
$name | Option name |
Returns the value for a blog option. blogid
indicates for which blog a value is requested (other parameters: see getOption
)
Returns the value for a category option. catid
indicates for which category a value is requested (other parameters: see getOption
)
Returns the value for a member option. memberid
indicates for which member a value is requested (other parameters: see getOption
)
Returns the value for an item option. itemid
indicates for which item a value is requested (other parameters: see getOption
)
Deletes an option from the database
parameter | value |
---|---|
$name | Option name |
Deletes a blog option (see deleteOption
)
Deletes a category option (see deleteOption
)
Deletes a member option (see deleteOption
)
Deletes an item option (see deleteOption
)
Returns all values for a given blog option. The result is an associative array with a value for each existing blogid
Returns all values for a given category option. The result is an associative array with a value for each existing catid
Returns all values for a given member option. The result is an associative array with a value for each existing memberid
Returns all values for a given item option. The result is an associative array with a value for each existing itemid
Returns the top of the values for a given option. The result is an array where every element is an array with a value ('value') for each blogid ('id')
parameter | value |
---|---|
$name | Option name |
$amount | The amount of options you want |
$sort | Sort ascending ('asc') or descending ('desc') |
Returns the top of the values for a given option. The result is an array where every element is an array with a value ('value') for each memberid ('id') (parameters: see getBlogOptionTop
)
Returns the top of the values for a given option. The result is an array where every element is an array with a value ('value') for each categoryid ('id') (parameters: see getBlogOptionTop
)
Returns the top of the values for a given option. The result is an array where every element is an array with a value ('value') for each itemid ('id') (parameters: see getBlogOptionTop
)
init()
method instead.
Up to v2.0, accessing the nucleus tables was just a matter of performing an SQL query on one of the nucleus_
tables. Since it is possible to use a custom table name in Nucleus versions >2.0, some precautions are needed in plugin development:
nucleus_item
, use the global function sql_table('item')
to generate the prefixed tablename1
(true
) when supportsFeature('SqlTablePrefix')
is called on it. If it doesn't, you won't be able to load the plugin on Nucleus versions > 2.0 when a custom prefix has been set (as a precaution)Note that the sql_table
global function in not available in Nucleus versions up to v2.0. If you use this method and want your plugin to work on Nucleus versions <= 2.0, add the following snippet of code on top of your plugin class:
<?php
// plugin needs to work on Nucleus versions &=2.0 as well
if (!function_exists('sql_table'))
{
function sql_table($name) {
return 'nucleus_' . $name;
}
}
class NP_HelloWorld extends NucleusPlugin {
...
}
?>
If your plugin needs database tables of it's own, you should create then in the install
method and remove them in the unInstall
method.
Some pointers
nucleus_plug_plugname
to avoid conflicts with other plugins. Generate them through sql_table('plug_plugname')
to make it work with custom prefixesmysql_query()
sql_connect()
at the end of your function. It might also be good to do this from the constructor, to avoid reconnecting constantly. You could then save your link identifier in $this->db
and pass that along with every query.getTableList()
method to make sure your table gets backupped when using the backup function.As of Nucleus v2.5, plugins can create admin area pages that integrate with the Nucleus admin area. These pages can be accessed either from the plugin admin page, or the quickmenu on the left.
To provide an admin area, you'll need take these steps:
NP_PluginName
. Note that the name should be lowercase!<?php
// if your 'plugin' directory is not in the default location,
// edit this variable to point to your site directory
// (where config.php is)
$strRel = '../../../';
include($strRel . 'config.php');
if (!$member->isLoggedIn())
doError('You\'re not logged in.');
include($DIR_LIBS . 'PLUGINADMIN.php');
// create the admin area page
$oPluginAdmin = new PluginAdmin('PluginName');
$oPluginAdmin->start();
echo '<h2>Plugin Name</h2>';
echo '<p>Page contents here<p>';
$oPluginAdmin->end();
?>
QuickMenu
event and add this code in your plugin:
function event_QuickMenu(&$data) {
array_push(
$data['options'],
array(
'title' => 'Plugin Name',
'url' => $this->getAdminURL(),
'tooltip' => 'Tooltip text'
)
);
}
function hasAdminArea()
{
return 1;
}
$strRel
variable in the index.php
needs to be adapted manually if the plugins directory is not located in nucleus/plugins/
The purpose of the PluginAdmin
is to help you. Once created, you can use $oPluginAdmin->plugin
to access the instance of your plugin.
As of Nucleus v3.2 plugins can provide a helppage with an overview of the plugins' functionality, the available skinvars and templatevars, where to get more info,...
The helppage will be accessible from the plugin overview in the admin area.
To provide a helppage, you'll need take these steps:
<h3>Plugin overview</h3>
<p>The only purpose of this plugin is to show how the plugin helppages work</p>
<h3>Installation</h3>
<p>If you can read this you correctly installed the plugin :-)</p>
<h3>SkinVars</h3>
<p>Because this plugin is only a testcase it doesn't has any skinvars/templatevars but suppose it would have:
<ul><li><b><%HelpPageTestCase1%></b>: does something</li>
<li><b><%HelpPageTestCase1(foobar)%></b>: does something else</li></ul></p>
<h3>Support and Bug reports</h3>
<p>For additional support and/or bug reports please use this forum thread:
<a href="http://forum.nucleuscms.org/viewtopic.php?t=<TOPIC_ID_GOES_HERE>">
http://forum.nucleuscms.org/viewtopic.php?t=<TOPIC_ID_GOES_HERE></a></p>
<h3>Version History</h3>
<ul><li>Version 0.1: initial testcaseversion</li>
<li>Version 0.0: pre-initial version ;-)</li></ul>
function supportsFeature($what) {
switch($what) {
case 'HelpPage':
return 1;
default:
return 0;
}
}
Starting from 3.2, a new plugin interface is added to allow one to declare any dependency on other plugin(s). This is useful for any plugin that requires another plugin to function. It is particularly useful for a plugin to detect broken dependencies that prevent if from functioning properly.
Let start from a real world example:
NP_PageLinkList depends on NP_BlogWithOffset to function, so we want to make sure if a user install NP_PageLinkList whithout first install NP_BlogWithOffset. With this API, Nucleus offers a way for a plugin to detect any missing dependency before it is installed.
In this case, we want to code into NP_PageLinkList to mark that it requires NP_BlogWithOffset. When the plugin is installed, the core calls a
function in the plugin called getPluginDep()
. This function returns a list of plugin it requires, and the core will check against all installed plugins and
refuse to install the plugin if a dependency is missing.
All we have to do is added this function to NP_PageLinkList:
function getPluginDep() {
return array('NP_BlogWithOffset');
}
The plugin dependency check also prevents plugins from being uninstalled if other plugins have a dependancy on it.