Trying to come close to the look and functionality of Mediawiki/Monobook creates challenges that don't arise with making a completely original theme. First, when CSS wasn't enough, it was necessary to change several of Tiki's templates to relocate page-function links into other areas of the screen. It was also necessary to try to understand the approach of the Monobook authors. I'll be the first to admit that, while the Tikipedia theme is a reasonably close Monobook lookalike, no way have I mastered CSS/DOM as the Monobook authors have, and I take full responsibility for my own work's shortcomings compared to the elegance of the original. wink


I'm still finding things to correct or add, but need to draw the line somewhere. What remains is mostly deciding what to do with the page-bar type tabs that are still down below the page-top line. For the first release, maybe they'll have to stay there, or this thing will take even longer to finish up. I'm working on the packaging now and will clean up the CSS file and zip things together shortly.


The page-top tabs have been one of the most difficult things to get right. The goal was to get the links up into tabs wherever it was reasonable, and to do it with as little modification of the default Tiki files as possible. Here's an example of what makes this hard.

The CSS selectors have to be identified, down to the link in the tab, but these are inconsistent from one Tiki section to another. Apart from the body class, all these paths start out the same way:

body|body.tiki_wiki|tiki_directory|tiki_galleries_|tiki_trackers| tiki_file_galleries|tiki_calendar div#tiki-main div#tiki-mid

But then at the tabs, differences arise:

div.tabt2 span.tabbut a.tablink

div.tabt2 div#page-bar div.button2 a.linkbut

View Tracker
File Galleries
div.tabt2 span.button2 a.linkbut

View Tracker Item (body.tiki_trackers, but div#page-bar in different vertical position compared to View Tracker)
div span.button2 a.linkbut

div#page-bar span.tabmark a

Admin Trackers
div.tabs span.tabmark a

This typifies the problem with "CSS sprawl" in Tiki, and probably the overall need for code refactoring already recognized by developers.

Combine this with the fact that the same CSS produces something different for each of the top three or four browsers and the result is a lot of fiddling to be done. I went through this once dealing with each page more or less separately and leaving the CSS file a mess, but decided to go back and try a more unified approach that will also clean up the file.

The significant properties are border and padding. These were originally applied in different ways to the tag divs, spans, and links, so I want to group the relevant selectors for property assignment.


These plugins have generally been based on earlier ones, and incorporate code found elsewhere in Tiki. When I got the MAKETOCBOX plugin to work, I thought "what a scavenger I am," grabbing a bit of javascript from the menu separator. I'm still learning enough PHP to write a plugin from scratch, but I've gotten fairly good at looking at other code and adapting it, adding to it, or reusing parts. One goal I have is to learn better how to understand every detail of the plugins and how to come up with them from scratch. Wiki plugins, being very small bits of code, seem like a good way to get more into PHP, etc.