Loading...
 

Addon Configuration JSON Files

This page is out of date and kept for reference only. See Addons Cleanup


tikiaddon.json

This is the main configuration file for the addon. The following is an example from the Hello World addon.

{
	"name": "Hello World",
	"package": "tikiorg/helloworld",
	"version": "0.1",
	"url": "http://dev.tiki.org/TikiAddonHelloWorld",
	"smarty": true,
	"tiki": ["14"],
	"depends": [
	],
	"api": {
	}
}

Each of the parameters are explained below:

name

A human readable name for the addon

package

The full package name in the format vendorname/packagename

version

A version in semantic format, i.e. integers separated by periods. Versions 0.x indicate pre-release versions (i.e. the addon is still not ready for production use). Minor patch releases can be for e.g. 1.0.1, or 1.0.2. Minor releases with change/enhancement in features can be 1.1, 1.2, etc. Major releases go from 1.x to 2.x.

url

This is the url to the documentation. It can simply be the main page provided by Github for your repository.

smarty

true or false. If true, will instantiate a Smarty object (i.e. template engine) for the addon. This Smarty object can be used to render templates from within the code of the Addon. Setting this to false if it's not needed can reduce the memory footprint of your app. Note that Tiki plugins (as opposed to Addon code) that render your addon's templates can still render using Tiki's Smarty object even if this is set to false.

tiki

This is an array of *major*versions of Tiki that the addon is meant to be run on (in JSON, arrays are represented by square brackets with comma delimited values). Integer (i.e. non decimal) values are used as the purpose is merely to indicate major Tiki versions.

depends

This is an array of dependencies to indicate what other addons (and versions) this addon is dependent on.

When creating complex apps, it might make sense to divide up functionality into separate addons instead of making one really large addon. So it is possible to specify dependencies on your own addons, or even addons developed by other developers (though it's recommended to be in communication with them to coordinate releases and roadmaps).

Each dependency in the array is specified as a JSON object with two properties:
package: The full package name in vendorname/packagename format.
version: A semantic version (certain wildcards are supported).

For example,

"depends": [
		{"package":"vendorone/packageone", "version":"1.2.*"},
		{"package":"vendortwo/packagetwo", "version":"1+.*"}
	]

The version that is specified for each dependency supports the following wildcards. Specifying * (an asterisk) instead of an integer means any integer (note while it will not theoretically match periods, it will match any sub-versions of that. For example, 1.* will match 1.0.1 or 1.1.1. Specifying an integer followed by a + (plus sign) or - (minus sign) matches any integer that is high or equal (or lesser or equal) as the case may be. For example, 1.2+ matches 1.2, 1.2.1, 1.3, 1.5 and so on.

api

This is an array of api configurations needed in order to use any of the Tiki Addon APIs. For example, the following is a configuration from the tikiorg/organicgrp addon that specifies configurations for the Addon Group API and the Addon Navbar API. More information about the configurations required by each API can be found its documentation.

"api": {
		"group": {
			"tracker": "trk_og",
			"public_catroot": "cat_public_grp",
			"private_catroot": "cat_private_grp",
			"managementpage": "tikiorg_organicgrp_managegrp",
			"homepage": "tikiorg_organicgrp_grouphomepage"
		},
		"navbar": {
			"tpl": "tikiorg-groupnavloader.tpl"
		}
	}


upgrade.json

This file specifies from which earlier versions a user can upgrade to the version of the addon that is in the package. It also specifies what the installer will do when upgrading from these earlier versions.

The upgrade.json file contains JSON objects, one for each earlier version (or version pattern) which a user can upgrade from. These objects specify what the installer should do in each case. For example, the following example indicates that it is possible to upgrade from any 0.1.x version or any 0.2.x version, but that the installer should do different things in each of these 2 cases. The wildcards allowed in specifying the version patterns are the same as the ones for specifying version dependencies in tikiaddon.json.

{
	"0.1.*": {
		"remove": [
			{"type":"wiki_page", "ref":"page_about", "profile":"02_content"}
		],
		"forget": ["02_content"],
		"reapply": []
	}
	"0.2.*": {
		"remove": [
		],
		"forget": [],
		"reapply": []
	}
}

There are three directives for each of the version patterns specified. These are "remove", "forget" and "reapply". These all take JSON arrays.

remove

This specifies what objects the installer should remove when upgrading from one version to another. You can only remove objects that previous versions of your addon created. Each object to be removed needs to be specified with three properties:

  • type: Type of object
  • ref: The profile reference for the object (in the profile that created the object)
  • profile: The name of the profile (i.e. .yml file) that created the object

forget/reapply

Just like standalone Tiki Profiles (i.e. profiles that are not part of an Addon], profiles that are installed that create any objects cannot be executed again unless they are "forgotten". This is a built-in safeguard to prevent overwriting of objects that were previously created by the same profile. By specifying the names of the profiles that are to be forgotten, the profiles if they are in the package can be reapplied again.

Specifying the profiles under "reapply" instead of "forget" pretty much has the same effect. The only difference between "reapply" and "forget" is that with "forget" a profile is forgotten even if it does not anymore exist in the package. This could be useful to clear out profiles from versions from the past that are no longer relevant anymore, if the objects that they created are definitely removed. If the objects still remain and are referenced from the addon, then using "reapply" is definitely the safer option.

uninstall.json

This file specifies what the remover does when removing an Addon, similar to the upgrade case. The main difference between the uninstall case, in contrast to the upgrade case, is that only the items to be removed need to be specified. The profiles that have been previously installed for all versions of the Addon are automatically forgotten when an Addon is removed.

Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.

Accessibility (WAI & 508)
Accounting
Administration
Ajax
Articles & Submissions
Backlinks
Banner
Batch
BigBlueButton audio/video/chat/screensharing
Blog
Bookmark
Browser Compatibility
Calendar
Category
Chat
Comment
Communication Center
Consistency
Contacts Address book
Contact us
Content template
Contribution
Cookie
Copyright
Credits
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs
DogFood
Draw
Dynamic Content
Preferences
Dynamic Variable
External Authentication
FAQ
Featured links
Feeds (RSS)
File Gallery
Forum
Friendship Network (Community)
Group
Help
History
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
jQuery
Kaltura video management
Karma
Live Support
Logs (system & action)
Lost edit protection
Mail-in
Map
Menu
Meta Tag
Missing features
Visual Mapping
Mobile
Mods
Modules
MultiTiki
MyTiki
Newsletter
Notepad
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Packages
Payment
PDF
Performance Speed / Load / Compression / Cache
Permission
Poll
Profiles
Quiz
Rating
Realname
Report
Revision Approval
Scheduler
Score
Search engine optimization (SEO)
Search
Security
Semantic links
Share
Shopping Cart
Shoutbox
Site Identity
Slideshow
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Spellcheck
Spreadsheet
Staging and Approval
Stats
Survey
Syntax Highlighter (Codemirror)
Tablesorter
Tags
Task
Tell a Friend, alert + Social Bookmarking
Terms and Conditions
Theme
TikiTests
Timesheet
Token Access
Toolbar (Quicktags)
Tours
Trackers
TRIM
User Administration
User Files
User Menu
Watch
Webmail and Groupmail
WebServices
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives
WYSIWTSN
WYSIWYCA
WYSIWYG
XMLRPC
XMPP




Useful Tools