Where are we?
Started to implement in CVS. Here are the steps (as I see them):
- Change tiki.sql and tiki_1.7to1.8.sql to initialize all the rows in tiki_preferences
- Remove initialization code from tiki-setup.php, preferences.php, etc. This is really only for performance reasons.
- Change dev docs to have new records for tiki_preferences put into the .sql files instead of tiki-setup
- Create / document dump scripts
- Create some sample configs
Where do we want to be?
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
TikiTeam
Currently recruiting members!
UserPagedheltzel
Trackers
- Bugs
- RFEs
- tech support
- patches
Competition and standards
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?
CVS Doc section
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).
Discussion
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?
;){kind=link}
;){kind=link}