Revision history for InstallingPlugins
Additions:
{{image alt="Plugin path screenshot" title="Plugin folder" url="images/features/plugin_path.png" class="right"}}The release of [[WhatsNew1166 | 1.1.6.6]] introduces a preliminary plugin architecture that allows Wikka users to override core functionality with custom actions, headers, formatters, and templates. The advantages of such a setup are numerous:
To use the new plugin folders for your add-ons, you will have to create the ##/plugins## tree and add the corresponding paths in [[ConfigurationOptions | wikka.config.php]] file (automatically added in fresh installs since 1.1.6.6). Components will be loaded following the path order specified in the config file (so for instance a custom action called ##/plugins/actions/contact.php## will override the default ##actions/contact.php##). You can use a comma (##,##) a colon (##:##) or a semicolon (##;##) as a path separator in the config file. For example:
To use the new plugin folders for your add-ons, you will have to create the ##/plugins## tree and add the corresponding paths in [[ConfigurationOptions | wikka.config.php]] file (automatically added in fresh installs since 1.1.6.6). Components will be loaded following the path order specified in the config file (so for instance a custom action called ##/plugins/actions/contact.php## will override the default ##actions/contact.php##). You can use a comma (##,##) a colon (##:##) or a semicolon (##;##) as a path separator in the config file. For example:
Deletions:
To use the new plugin folders for your add-ons, you will have to create the ##/plugins## tree and add the corresponding paths in [[ConfigurationOptions | wikka.config.php]] file (automatically added in fresh 1.1.6.6 installs). Components will be loaded following the path order specified in the config file (so for instance a custom action called ##/plugins/actions/contact.php## will override the default ##actions/contact.php##). You can use a comma (##,##) a colon (##:##) or a semicolon (##;##) as a path separator in the config file. For example:
Additions:
>>==See also==
~-[[WikkaThemes | Installing themes]]
~-[[http://wikkawiki.org/CodeContributions | User-contributed plugins]]
>>{{since version="1.1.6.6" align="left"}}
~-[[WikkaThemes | Installing themes]]
~-[[http://wikkawiki.org/CodeContributions | User-contributed plugins]]
>>{{since version="1.1.6.6" align="left"}}
Deletions:
Additions:
===Plugins and ##mod_rewrite##===
If your wiki runs on an Apache server and is configured to use clean URLs via ModRewrite, you will need to disable redirection for files in the ##/plugins## tree. Just save the following file in the ##/plugins## folder:
%%(text;plugins/.htaccess)
<IfModule mod_rewrite.c>
# turn on rewrite engine
RewriteEngine off
</IfModule>
If your wiki runs on an Apache server and is configured to use clean URLs via ModRewrite, you will need to disable redirection for files in the ##/plugins## tree. Just save the following file in the ##/plugins## folder:
%%(text;plugins/.htaccess)
<IfModule mod_rewrite.c>
# turn on rewrite engine
RewriteEngine off
</IfModule>
Additions:
{{since version="1.1.6.6" align="left"}}
{{image alt="Plugin path screenshot" title="Plugin folder" url="images/features/plugin_path.png" class="right"}}The release of [[WhatsNew | 1.1.6.6]] introduces a preliminary plugin architecture that allows Wikka users to override core functionality with custom actions, headers, formatters, and templates. The advantages of such a setup are numerous:
~- Future Wikka upgrades are guaranteed not to change or modify anything in the ##/plugins## folders.
To use the new plugin folders for your add-ons, you will have to create the ##/plugins## tree and add the corresponding paths in [[ConfigurationOptions | wikka.config.php]] file (automatically added in fresh 1.1.6.6 installs). Components will be loaded following the path order specified in the config file (so for instance a custom action called ##/plugins/actions/contact.php## will override the default ##actions/contact.php##). You can use a comma (##,##) a colon (##:##) or a semicolon (##;##) as a path separator in the config file. For example:
%%(php)
'wikka_formatter_path' => 'plugins/formatters,formatters',
'wikka_template_path' => 'plugins/templates,templates',
'handler_path' => 'plugins/handlers,handlers',
'action_path' => 'plugins/actions,actions'
%%
Version 2.0 will herald an even more robust plugin architecture (backwards-compatible with the one in this release) that will include "hooks" that can be called from a user's custom component, eliminating the need to modify code in the Wikka core.
{{image alt="Plugin path screenshot" title="Plugin folder" url="images/features/plugin_path.png" class="right"}}The release of [[WhatsNew | 1.1.6.6]] introduces a preliminary plugin architecture that allows Wikka users to override core functionality with custom actions, headers, formatters, and templates. The advantages of such a setup are numerous:
~- Future Wikka upgrades are guaranteed not to change or modify anything in the ##/plugins## folders.
To use the new plugin folders for your add-ons, you will have to create the ##/plugins## tree and add the corresponding paths in [[ConfigurationOptions | wikka.config.php]] file (automatically added in fresh 1.1.6.6 installs). Components will be loaded following the path order specified in the config file (so for instance a custom action called ##/plugins/actions/contact.php## will override the default ##actions/contact.php##). You can use a comma (##,##) a colon (##:##) or a semicolon (##;##) as a path separator in the config file. For example:
%%(php)
'wikka_formatter_path' => 'plugins/formatters,formatters',
'wikka_template_path' => 'plugins/templates,templates',
'handler_path' => 'plugins/handlers,handlers',
'action_path' => 'plugins/actions,actions'
%%
Version 2.0 will herald an even more robust plugin architecture (backwards-compatible with the one in this release) that will include "hooks" that can be called from a user's custom component, eliminating the need to modify code in the Wikka core.
Deletions:
The release of [[WhatsNew | 1.1.6.6]] introduces a preliminary plugin architecture that allows Wikka users to override core functionality with custom actions, headers, formatters, and templates. The advantages of such a setup are numerous:
~- Future Wikka upgrades are guaranteed not to change or modify anything in the ##plugin## folders.
(stub)
Release 1.1.7 will herald an even more robust plugin architecture (backwards-compatible with the one in this release) that will include "hooks" that can be called from a user's custom component, eliminating the need to modify code in the Wikka core.
Revision [1928]
Edited on 2009-02-16 06:39:13 by DarTar [adding stub: we need to explain how to change the config settings to use plugins and give an example]Additions:
The release of [[WhatsNew | 1.1.6.6]] introduces a preliminary plugin architecture that allows Wikka users to override core functionality with custom actions, headers, formatters, and templates. The advantages of such a setup are numerous:
Deletions:
Revision [1927]
Edited on 2009-02-16 06:38:53 by DarTar [adding stub: we need to explain how to change the config settings to use plugins and give an example]Additions:
===What's next===
Revision [1926]
Edited on 2009-02-16 06:38:27 by DarTar [adding stub: we need to explain how to change the config settings to use plugins and give an example]Additions:
===How to use the plugin folder===
(stub)
(stub)
Additions:
The release of 1.1.6.6 introduces a preliminary plugin architecture that allows Wikka users to override core functionality with custom actions, headers, formatters, and templates. The advantages of such a setup are numerous:
~- A component that "misbehaves" or does not perform to your expectations can simply be removed.
~- Future Wikka upgrades are guaranteed not to change or modify anything in the ##plugin## folders.
~- Testing of a new action, handler, formatter, or template is greatly enhanced: There is no need to modify core functionality, and it's easy to revert back to the core if necessary.
Release 1.1.7 will herald an even more robust plugin architecture (backwards-compatible with the one in this release) that will include "hooks" that can be called from a user's custom component, eliminating the need to modify code in the Wikka core.
[[http://www.wikkacase.org | WikkaCase]] has been set up as a repository for Wikka plugins. While the use of ""WikkaCase"" is beyond the scope of this document, we will be updating the [[Wikka:WikkaCase | WikkaCase documentation]] as progress on the new architecture continues. Currently, SVN and bug tracker access is available for developers who want to start building plugin modules for Wikka. Please visit the [[Wikka:WikkaCaseDevHowTo | WikkaCase development]] page for details.
~- A component that "misbehaves" or does not perform to your expectations can simply be removed.
~- Future Wikka upgrades are guaranteed not to change or modify anything in the ##plugin## folders.
~- Testing of a new action, handler, formatter, or template is greatly enhanced: There is no need to modify core functionality, and it's easy to revert back to the core if necessary.
Release 1.1.7 will herald an even more robust plugin architecture (backwards-compatible with the one in this release) that will include "hooks" that can be called from a user's custom component, eliminating the need to modify code in the Wikka core.
[[http://www.wikkacase.org | WikkaCase]] has been set up as a repository for Wikka plugins. While the use of ""WikkaCase"" is beyond the scope of this document, we will be updating the [[Wikka:WikkaCase | WikkaCase documentation]] as progress on the new architecture continues. Currently, SVN and bug tracker access is available for developers who want to start building plugin modules for Wikka. Please visit the [[Wikka:WikkaCaseDevHowTo | WikkaCase development]] page for details.
