History: TikiProfilesDev

This is an enhancement not yet implemented. More on that soon.

for more on the Tiki Setup Process go to InstallTiki !

A profile is a collection of Tiki configuration data, including

• which features are selected
• which groups are set up
• which permissions a group has

Profiles can be chosen at initial setup

• At the beginning of the webbased part of the installation process, the admin can choose what profile to start with
• examples could be "minimal", "standard news portal", "full fledged monster"
• There is a link "download more profiles" (like with themes or extensions in mozillafirebird)
• after choosing initial profile, the admin can finetune to her needs

Example: Profile "Tiki for a music band"

• uses features calendar, CMS, Wiki, Forum
• uses groups Band, Booking, Venues, Fans
• permissions so that Band sees more than Fans etc.
• a musicians magazine could provide a version of Tiki that loads with the "Music Band" profile by default. The whole thing just looks like designed ONLY for musicians.

Profiles are mergable

• Suppose I already have a running and configured Tiki, but I want to add all the functionality of profile "Band", then I can merge that into the current instance
• Wherever this is possible without conflicts, Groups and permissions are just automatically added
• Admin can choose what to do in conflicts

Profiles are dumpable

• Suppose some band is quite happy with their configuration after some tweaking.
• Then they just click "dump profile", set the appropiate checkboxes on which part of the configuration to dump (export) and contribute the resulting profile to tikiwiki.org, where others can download it.

Profiles mix well with Content Packs

• see ContentPacksDev for more information

Currently recruiting members!

UserPagedheltzel

• Bugs
• RFEs
• tech support
• patches

List of other products with similar/interesting/related features.
Here I would like to see some "editorial" content. How do our features compare to others?

This is where new features being developed and only in CVS are documented. When the CVS becomes RC/official release, the info in the CVS docs is transferred to update the official docs (FeatureXDoc).

Comments from Dennis

I was starting to look at how to create "sets" of defaults values for different purposes (mostly-wiki, slashdot-like, etc).
Currently the values in the tiki_preferences table are populated by tiki-setup.php, which gets included in almost all other pages. Logically, the default prefs only need to be set once, when the db is initialized. I would like to remove all the code that sets default values in tiki-setup.php and put the same logic in as inserts into tiki_preferences in the tiki.sql file that is used to create the tables. The tiki.sql currently populates a number of tables this way, including users_permissions.

Does anyone see any problem with this idea?
Any way it could bite us?