See also: Creating New Preferences, Adding a preference to an admin panel and Default Preferences to be changed
What
Dynamic preferences is a new feature of Tiki4, part of the Workspace project which
- Makes it possible to create custom admin panels
- Makes it possible to have a Perspective admin interface (where each preference can be overridden per perspective
- Makes management of current admin panels (tiki-admin.php) easier.
Benefits
About
Code name: "lesser magic"
Started in lesser-magic branch and later added to trunk for release in Tiki 4.0 Work is started to migrate all the 1000+ preferences from the old system to the new and is, with a few exceptions, completed in Tiki5.
Magic didn't succeed. It was probably too ambitious because it was trying to make all preferences dynamic (that's good), but to also automagically generate all admin panels (very hard because of exceptions)
For Workspaces / Perspectives, we need a way to set preferences in a workspace which are different than the global. We also want a way to provide workspace admins to set some of the prefs. But of course, not all 1000+ prefs! Only the ones that are relevant (turn wiki on/off, change theme, etc.)
So we need a dynamic admin panel per workspace. What is configurable by the workspace admin should be defined in the profile
Normal admin panels (tiki-admin.php) will remain so UX can have full control of how things are positioned, and to hide/show features depending on another setting. However, for the settings that are defined, the html can be generated dynamically (like a Smarty plugin)
How to hide options with dependencies
moving to Adding a preference to an admin panel
Templates
moved to Adding a preference to an admin panel
Field types
moved to: Creating New Preferences
An example. It's a list definition:
moved to Creating New Preferences
Perspectives
moving to Creating New Preferences
To do
- A button to rebuild index (useful after an upgrade)
- Tiki8: test pref levels with current profiles
- If a profiles uses a pref, it could mean that it should be a basic pref.
- Make prefs names as part of the index too (like feature_wiki)
- Make some prefs that can run profiles in the background or otherwise
- later (tricky and potentially dangerous)
- option to clear cache upon modif of this pref
- Things like log_tpl only take effect after clearing cache so admin thinks nothing happened.
- Alternatively, have a link to delete cache in the confirmation message
-
adding levels to each pref "Basic" "Advanced" and adding a drop-down toggle Basic, Regular and "Advanced" for tiki-admin.php Done in Tiki8
-
All prefs to be evaluated and a good chunk should become advanced Done in Tiki8
-
tabs with no options ideally don't appear. (if hard to do, just leave it) done
-
if an option is not of the default value, it should be shown in basic view, even if it's advanced. Done in Tiki8
- in search results while in basic mode, advanced prefs can appear but should stand out (somehow)
- In the future, get community ratings to preferences from Connect
-
add new param for prefs: ex.: urladmin=tiki-admin_trackers.php so when a feature is activated, we can easily find how to admin/use done
- "My changes" admin panel: Show me diff than default. From here, link to http://profiles.tiki.org/Save+current+configuration+as+a+profile
- If search results are filtered by tag, have a note to say so and a link (search again throughout all prefs)
Cleanup
- Convert remaining data from lib/setup/prefs.php to lib/prefs/
- Review all templates/admin/*.tpl files and make sure there aren't leftovers of the old system (as of 2010-08-20, there are some)
Wishlist
-
Add a way that we can give custom feedback (ex.: "You activated forums, now click here to assign permissions to forums" or "You activated forums, now click here to create a forum.") This was tricky to do and this info can be useful not just after activating so we added contextual links in Tiki8.
- Update this documentation to indicate all potential attributes of prefs (ex.: keywords is missing)
- Add a pref for demo mode
- When a Tiki would be in demo mode, a certain number of prefs would not be accessible. So we can give users tiki_p_admin...
- Test on Fresh installs, that no unwanted changes appears. Ex.: (?????)
- as of 2010-01-06: feature_wiki_mandatory_category, wikiHomePage, email_due, pass_due, users_prefs_display_timezone, etc
- no pref modifications should be leftover in tiki-admin_include_*.php files
- bookmark prefs in a "my admin panel"
Custom admin panels
Goal 1: provide tiki_p_admin but hide some of the prefs.
Also, it should be possible to force configs in db/local.php (ex.: BBB prefs) so they invisible or visible but not changeable
Why?
- Hosting company may want to offer all-in-one hosting, but restrict usage of
- experimental features
- feature that can be used to gain server access (which is OK for most setups, but not cool for a WikiFarm)
- Consulting company wants to make simpler admin panels for a customer
- Using Tiki as an application builder (framework)
How?
each feature could have a property "advanced", "regular" (default) and "basic". But this is tricky because it depends on the use case.
So perhaps this could serve as a basic list, and provide a way to have overrides. List could be manages in db/local.php
level = basic + preferences feature_category_transition.
Done: System Configuration
Goal 2: make a simpler/easier admin panel for new admins
Each feature could have a property "advanced" "regular" (default) and "basic". But this is tricky because it depends on the use case.
Lists could be shared in wiki pages, and thus made specific to use cases.
-
Risks
- admin panels will not always react well to disappearing perms
- empty tabs
- illogical sequences
Tagging and categorizing prefs
Moving to Creating New Preferences
Changes to the admin panels
- Should add SEO and merge in tiki-admin.php?page=sefurl and tiki-admin.php?page=metatags
- OSM maps and GoogleMaps in tiki-admin.php?page=maps
Improve pref report script
http://dev.tiki.org/How+to+improve+the+release+process#Script_to_test_preferences
Alias