The document discusses the introduction of Tiki Addons, highlighting the challenges and necessary features for creating configurable, ready-to-use profiles for Tiki. It outlines the Addons API aimed at integrating core functionalities while minimizing duplication, along with best practices for developing addons. The vision includes establishing a centralized Tiki addons directory and expanding user and developer engagement through potential addon categories and community-driven innovation.

1. INTRODUCING
TIKI ADDONS
Nelson Ko – Feb 26, 2015

2. Background
¨ It all started with Tiki Profiles
¨ We have a way to quickly install preferences and
Tiki objects – great!
¨ Some issues faced:
¤ Too much work to write profiles from scratch, but we
can now export profiles – great!
¤ Profiles useful for “demos” but so far not so good for
“ready to use” features – why?

3. “Ready to use” features
¨ Needs configurable preferences
¤ Variations of use cases (without forking profiles)
¨ Needs custom templates (and custom CSS), e.g.
¤ Pretty tracker templates
¤ List/CustomSearch plugin templates
¤ Activity stream/notification templates
¨ Needs versioning and dependency management
¤ Able to systematically install, upgrade, remove
¤ Able to specify what else is installed first

4. Demo
¨ Event calendar version 0.1
¨ Someone installs it
¨ Now added new field in the tracker, and added
preferences to make some fields optional, released
as version 0.2
¨ Let’s upgrade from version 0.1 to 0.2

5. Do Tiki addons support code?
¨ Views (thinking of changing name as it seems potentially confusing)
¤ Think of it as a wiki-plugin but it executes specifically
through the Addon wiki-plugin
¤ Pretty much the same except it has its own namespace
¤ Views can also execute as a module
¨ Libs
¤ Introduced through standard (relatively new) Tiki
custom.xml style dependency injection
¤ e.g. a custom AJAX service or lib used by views

6. What is the Addons API in Tiki?
¨ To make sure that things that affect Tiki directly are
part of Tiki itself (avoid Drupal problem)
¤ To reduce duplication
¤ To make it easier for other add-ons to use “core-type”
functionality without reinventing the wheel
¤ E.g. Organic Groups API: The concept of organic groups is
core functionality but each addon is different
¤ E.g. Navbar API: Every addon might need a nav bar, but
every nav bar is different
¤ E.g. File Gallery API: Every addon might need its own File
Galleries - makes sense to have standard way to use them

7. Best practices
¨ Addons should be more about profiles and
templates than they are about code
¨ Component features should be in Tiki core and not
addons
¨ A good addon should interface to Tiki in
predictable ways (limit breakage on refactor)
¤ Addon APIs
¤ Directly extending classes in systematic, limited way
¤ Make limited direct calls to legacy Tiki functions

8. Why GITHUB?
¨ Distributed responsibilities need distributed
development environments
¨ Easy to fork and merge back from various forks
¤ Encourage innovation through variants of each addon
But need (currently missing) Tiki Addons directory
¤ Centralized hub, easily searchable, feedback/rating
¨ But need git-svn (unless other solution exists) sync
¤ Calculated in community commit stats

9. Potential (App store concept)
¨ The vision is to have one day an “app-store” of
different “ready-to-use” features that can be
installed à Expand user base
¨ Expand developer/power-user community
¤ Casual developers/power-users do not ever need to
touch Tiki core code if they are doing just profile +
template based addons
¤ More serious coders are encouraged to contribute to
Tiki core (in the Addons API and also in the lib/core/…
e.g. lib/core/Services)

10. Possible Tiki addons
¨ Knowledge repositories
¨ CRM / ERP
¨ Shopping carts
¨ Project management apps
¨ Social networking apps
¨ Activity streams
¨ Organic Groups
¨ Search UI
¨ Integration with 3rd party apps
¤ some key open source software can be integrated within Tiki
but of course impossible to have too many in core

11. What’s missing
¨ Tiki Addons directory
¤ Easily searchable
¤ Feedback and rating
¤ Code itself can be on GITHUB but linked here
¨ More developer documentation
¤ Improve existing
¤ More examples
¤ More webinars

12. What’s missing
¨ Display installed addons to users by default
somewhere
¤ Link to the specified homepage for each addon?
¨ Addons installer needs to record preferences
changed by addons
¤ Intelligently warn conflicts
¨ Expand pref. name limit to beyond 40 characters
¨ Non-console admin panel way to install addons