Magic was the code name for the (then) new data-driven admin panel in Tiki3. It has been pulled out and replaced by Preferences in 4.0


We are currently looking for someone to lead the development on this feature. This feature is currently orphaned and not being developed. Classic admin panels have been massively improved between version 2.x and 3.0

Who worked on this?

Advantages over previous system

The old tiki-admin.php was mostly hard-coded settings. Tiki-magic.php has several advantages

  • Easy to have settings in more than one place
    • sylvie: can you do it without duplicating the line?
    • marc: yes, surely we can improve this. But we must keep in mind that when we duplicate the line, we can easily have a different label, which makes a lot of sense sometimes (the context requires different label).
  • No more multiple "save" buttons per page, which was quite annoying.
  • Can have a view of all settings using tiki-magic.php?featurechain=1 or tiki-feature-load-postprocessor.php (not supposed to be used for this)
    • This can still be improved by having a show all possible options, only options when parent is activated, etc.
  • More future-proof
    • Easier to have enhancements available for all. Ex.: before, the "Retroaction message to confirm what was just changed" would work for some things, but not all.



tiki-magic.php gets the data from this new file. This format (.csv) was chosen for now to make it easier to populate. It could change to another format eventually.

The magic interface data will be reloaded when the file has been updated. This is done checking the timestamp of the file. You can also manually refresh.

Please make sure to save this file in Unix file format. If you edit it with something like Excel it must be converted from DOS text file format to Unix format. This can be done on the command line:

# dos2unix db/features.csv

Explanation for the "feature_id" column

A numeric ID to identify each feature.

Explanation for the "feature_name" column

A nice name, translatable via normal lang/xx/language.php files.

  • Q: Is the the label that will display? What is the convention to use? Iniital cap? Sentence structure? Complete sentences? Etc. - ricks99
  • A: I don't know what will be the final convention. For now, let's just copy the exact same labels as we had before, since they are translated. (marclaporte)

Explanation for the "parent_id" column

Uses the feature_id. Each entry should have a parent.

Explanation for the "status" column

This is a single choice status picker. Current choices are

  • experimental
    • Question: should all entries presently say "experimental" (because that is the only documented choice) or does an empty field have a meaning? (SEWilco)

In the future, we could have:

  • Risky (for security)
  • How about a "required"... for things like sender email that are empty on a new install but admins must/should complete? (ricks99)
    • marclaporte: Yes, Ricks99, great idea. We could have a panel with all the required and this could be last step of installer.
  • Perhaps some should be "optional" such as plugins or themes. (SEWilco)
  • etc

Explanation for the "setting_name" column

This is the variable as used by TikiWiki and set in lib/setup/prefs.php

  • (TODO) Further explanation is needed here.

Explanation for the "type" column

- Holds other a collection of anything.
- Holds a collection of settings only. (TODO: where are defined the collection???? maybe just using the order?)

- Is a piece of functionality which can be enabled and disabled, and may have configuration.
- Is a piece of core functionality of tikiwiki that may not be disabled, and may have configuration.
- Is a reference to a template which performs a function, and has no configuration. It is part of either a feature or system item. It is used for determining what should be highlighted in the top bar for that template.

- A true/false flag.
- A simple text value.
- A simple text value which is stored by-reference.
- A smaller numeric field for storing a value.
- An item which has a special-case input handler.

Explanation for the "template" column

sylvie: Is it the php file or the tpl? (tiki-phpinfo seems to show that it the php.. so perhaps the name in not well chosen
marclaporte: It works for tpl, I don't know and don't think it works for php yet (maybe never will)

Explanation for the "permission" column

For now, all features need tiki_p_admin permission. But in a future version of magic, we could have more flexible permissions.

Explanation for the "ordinal" column

This will determine in what order the setting will appear. It should be a numeric value. If no value is set, settings will appear in no particular order. Since no value is like using 0 (zero), a negative value can be used to move things to the top. Lesser used settings should have high numbers and thus, appear low on the page.

Explanation for the "depends_on" column

sylvie: the feature_id the feature(seems only needed for feature?????) is depending on. Can we put a list????

  • How fine-grained should this be? For example, every wiki list option depends on the Wiki feature being enabled. Or do you simply use the "depends_on" on the Wiki List container? (ricks99)

for links to$keyword and$keyword

  • Will this also accept full URLs (for things like the Time/Date help which links to the PHP docs? (ricks99)
  • This does not appear to be working for all options? I've added several help links in the the features.csv, but they do not appear in the UI (ricks99)

Explanation for the "tip" column

Summary of the item.

  • For plugin selection entries, tip appears on Plugin selection page next to checkbox.

Explanation for the "Notes" column

If there is anything special/bizarre which is worth noting

  • Does this appear in the end-user UI? (ricks99) marclaporte: no
    • Needs to appear in the UI — otherwise what good is it? (ricks99)
    • What is the difference between the tip and note column? How are the two meant to be used? (ricks99)

To do

  • Make tiki-magic optional so people can turn it off. I guess there should be an option (sigh) in the old admin panel to turn it back on.
  • Log all setting changes to sys
  • commit mlpvolt's work at the TikiFest
  • document the features.csv file
  • copy/paste all the labels from tiki-admin.php?page=features to db/features.csv as can be reviewed at tiki-magic.php?featurechain=1 or tiki-feature-load-postprocessor.php
  • Move all the settings to the best place(s)
  • Make it tableless and accessible as far as possible
  • Make it themeable (via CSS)
  • discussion on IRC

Bugs/missing stuff

  • Avoid extra click to see changes (in some but not all screens)
  • available_languages is a multi-select to restrict, not a drop-down
  • tiki-admin.php?page=cms Batch upload (CSV file) needs to be moved elsewhere
  • Release checks are made when you browse admin main page only
  • Force immediate check
  • tiki-admin.php?page=intertiki -> maybe this should stay the same

Feature requests

  • Have a third level of magic menu
  • Have a way to show/hide the new horizontal menu (maybe something which drags from left to right)
  • Retroaction message to confirm what was just changed and add to the syslog (user x changed feature y)
  • To work with lesser permissions (ex.: tiki_p_admin_wiki)
  • AJAXy search box to quickly find my feature
  • when AJAX is on display/hide children options when parent is checked on/off and save dynamically
  • Two modes for inactive features (greyed out vs hidden)
  • Need a way to hide children if the parent is disabled. For example, if I have disabled Wiki Comments, don't bother showing me its children: Comments default ordering, list displayed by default, number of comments per page.
    • ricks99
  • I'd like to propose a slight change to the way the options are formatted. IMHO, having the labels right-aligned is tough to read. I propose (more from ricks99):

    Type Format
    Flag Have the checkbox to the left of the label.
    Simple Have the label above the text field, with the field 100% width.
    Int Have the label to the left of the text field (size=3)
    Text Area Have the label above the text area, with the field 100% width.
    Enumeration Have the label to the left of the selector.


Nice to have

  • A field with configuration parameters for any plugin. These parameters would be converted as if given on plugin incantation, before the manually specified parameters are interpreted (thus manual definitions can override these). For example, the default image size for an IMAGE plugin could be controlled from this one place without having to edit all IMAGE plugin incantations scattered around Wiki pages. See Tracker item 2156

Need to think about it more

  • Reset to default feature (nyloth's idea)

Announcement on the mailing list

[Tikiwiki-devel] Massive changes to the admin panel in progress on trunk (future 3.0) during TikiFest Montreal
From: Marc Laporte - 2008-08-16 22:12

Here at the Montreal TikiFest (,
we are working on massive changes to the admin interface.

Christine ( aka NefariousC on IRC aka
princessxine on SVN/SF has done an a-m-a-z-i-n-g job over the last few
weeks, which was committed today.

The old admin panel is untouched. Once all the settings have been
transfered and have been thoroughly tested, we'll be in a position to
delete it (the old admin panel). We will have made it obsolete!

If you update from trunk, you can check out: tiki-magic.php It's a
data-driven (using data in db/features.csv), magical admin panel.

There is still a lot to do, but you will see that it does quite a lot.
It will be in very good shape by the end of the TikiFest on Tuesday.

In future versions, this will solve the problem about site settings
which need tiki_p_admin and administration features which require
tiki_p_admin_feature It's database-driven so we will show users the
settings in WYSIWYCA (What You See Is What You Can Access).

With this new panel, it'll be easier/cleaner to add new features. It
will also be easy to add the settings in many (all relevant!) places.
A setting about categories and wiki will appear in both places.

Some background info:

After the Admin Panel Revamp, if we still have some time/energy, we'll
attack the edit UI aspects: