Some Major DokuWiki Adjustments

If you have eight hours to cut down a tree,
it is best to spend six hours sharpening your axe
and then two hours cutting down the tree.
Anonymous, on the benefits of having good tools

Note: As usual with Modifications and Code on this Website: There is absolutely no warranty for any problems, data loss or whatever else happens to you if you try to use it.

I have done a few modifications of my DokuWiki and made a few postings about it (e.g., Ferret, DokuWiki Adjustments). Recently, there were some major changes that lead to the following additional adaptations, which might be useful for some (Doku-)Wiki users.

There were two reasons involved for the changes:

1. I split my Wiki in a private and a career (science) Wiki. I had them separated at the beginning a few years ago, then joined them due to an overlap of private interests and career topics, but I have recently noticed that I can hold them apart more easily. Also, using the science Wiki in public was difficult due to the amount of private NSFW content with which is was interlaced. Now, both Wikis are separate, the navigation is easier and I no longer have this problem.
2. I am beginning to transfer my literature notes from Circus Ponies Notebook to DokuWiki. I have thought for some time about it. I love Circus Ponies Notebook and without it, I couldn’t have done my PhD thesis. It is the best program for creating outlines and planning an article or a book, but for long term storage it becomes too sluggish over time, and it is too proprietary. Half a second reaction time might not be that long, but for an Application it is too long. I am used to wait a split second when using the browser, so it does not disturb me there. Furthermore, DokuWiki is too proprietary. Given Apple’s recent development I want to keep my options open in the future. I’ll probably never stop using Apple products (which would mean loose brilliant applications like Scrivener and yes, Circus Ponies Notebook), but having a Plan B is second nature to me. I am not sure whether using DokuWiki this way works better in the long run, so I would not recommend anyone to quit using Circus Ponies Notebook for dealing with literature. It’s a trial and I will see whether it works or not … in about a year.

Regarding DokuWiki, I still think that it is the best Wiki Software if you want to use text files for data saving. And I need text files and I am not a fan of SQL, so MediaWiki (Wikipedia’s Wiki) is not an option. Some of my friends have tried to use DokuWiki for their personal organization of creativity, but few remained with it. I think because it actually requires modification, and if you cannot change PHP code, you will have a hard time using it. Given that you use the Wiki extremely often and invest a lot of time and effort in it, you must like working with it. And given that some functions are missing or do not work like you would like them to be, you will have to adapt it. Unless one spends more time changing the tool than actually using it, that’s all right.
Also check the plugins, they make DokWiki worthwhile.
Good plugins are: cloud, code, gallery, xbr, orphanswanted, pagelist, tag, and wrap.

Now, what were the changes?

New DokuWiki Version installed

DokuWiki has changed a little and I have now installed the current version. I never touch a running system and I would not want to update from an earlier version, but starting two new Wikis and bleeding my old Wiki dry made this a no-brainer. In usage, there were some tiny improvements (like with bullet point lists). Now, if the author would only include an option for natural linebreaks, I’d be happy. 😉

New Monobook Template

There is a really good template called monobook that makes DokuWiki look like Wikipedia. Easily configurable with quick navigation tabs above the article and a navigation bar on the left side. I still use Ferret — it is the sole reason that working with a Wiki is anything close to efficient — and it works perfectly with it. If you use it, check the user directory in the template/monobook directory. Especially the boxes.php, the tabs.php, and the screen.css.

Included a Back Arrow

One thing I really hate is that, after editing an article, using the browser’s back button often brings you back to the edit field. I haven’t found out yet how to avoid that (it’s a security issue to jump over previous pages), so I have changed the templates (Ferret) I use to include a back arrow on the top of the page. It’s really simple:

[[:start|{{:back.gif }}]]====== Literature ======

A nice effect: given that I use headers the arrow is displayed within the first header which looks kinda nice (note: I have the xbr Plugin installed):

While it would be possible to write PHP code that analyzes the address of the page currently edited and make a back arrow with a link that goes to the page one level above (simply be dropping the last “:pagename”), this way worked fine for me, if needed, I change the destination manually (it would take me more than 2 minutes to write this code, so I haven’t done it yet).

Included a Top Arrow

I changed some code to have an up arrow anywhere where an “edit” is displayed. The code still has some bugs but works most of the time (no, I’m not a computer scientist, I’m a psychologist, my science must only work most of the time, not each and every time ;-)).
It is possible via:

<a href=”javascript:window.scrollTo(0, 0)”><img src=”SOURCE/top.gif”></a>

in /inc/html.php, or you can change (and adapt, see the SOURCE part):

function html_secedit_button($matches){
global $ID;
global $INFO;

$section = $matches[2];
$name = $matches[1];

//dwdw strtolower($str)
if (strtolower($matches[1]) != strtolower($ID)) {
//echo “here: “.$matches[1].”<br>”;
//echo “upper: “.$ID.”<br>”;

$secedit  = ”;
$secedit .= ‘<div>’;
$secedit .= html_btn(‘secedit’,$ID,”,
array(‘do’      => ‘edit’,
‘lines’   => “$section”,
‘rev’ => $INFO[‘lastmod’]),
‘post’, $name);
$secedit .= ‘<a href=”javascript:window.scrollTo(0, 0)”><img src=”SOURCE/top.gif”></a></div>’;
return $secedit;

} //dwdw
}

to prevent that an up-button appears immediately after the title. But it’s buggy and the page must have the same name as the first title.

Changed the toolbar.php

Changed the icon and the code in the inc/toolbar.php to allow me to quickly cite code written in Objective C, using the Code Plugin (by Matthias Watermann). The toolbar commands can be easily changed:

array(
‘type’   => ‘format’,
‘title’  => $lang[‘qb_code’],
‘icon’   => ‘mono.png’,
‘key’    => ‘c’,
‘open’   => “<code ObjC>”,
‘close’  => “</code>”,
),

I also made the same modifications for code that allows me a <nowiki>…</nowiki>. I use some commands more often than others and if you’re willing to edit the toolbar.php, you can save a lot of typing.

Note: When you edit DokuWiki’s files, sometimes you have to open the local.php in the conf-directory afterwards, change anything (e.g., add a space in a comment) and then save the file to see the effect. Deleting the cache (of DokuWiki) sometimes also helps. (I’m not going to tell you about making backups of all your data first!)

Installed and changed the WRAP Plugin

A very helpful plugin to highlight certain parts of the page is WRAP. I changed the code to include a title by default and use it to remind me how to deal with the changes, e.g., in the literature-directory. You have to edit the action.php in the plugin’s directory (wrap) and include the title code in the ‘open’ command:

‘open’   => ‘<WRAP center round info 60%>//**__TITLE__**//\n\n’,

Changed the Headlines

I already used colors to differentiate between the different levels, but now I “excluded” the top level (page name). You can easily do this by editing the screen.css in the monobook/user folder of the monobook template

p {
margin-left: 1em;
}

h1, h2, h3, h4, h5, h6 {
color: black;
background: none;
font-weight: bold;
margin: 0;
margin-top: 1em;
padding-top: 0;
padding-bottom: 0;
padding-left: 0.5em;
}
h1, h2, h3, h4, h5, h6 {
border-bottom: none;

font-size: 1em;
}
h1 { font-weight: bold; font-size:130%; border-bottom: 1px solid #aaa; border-top: 1px solid #aaa; background-color: Honeydew; }
h2 { background-color: PaleGreen; }
h3 { background-color: LightBlue; }
h4 { background-color: LightGoldenrodYellow; }
h5 { background-color: LightPink; }
h6 { background-color: BurlyWood; }

and changing “Top level for table of contents” in the DokuWiki config to “2”.

Changed the Workflow for Adding Information

I had already done this for my private Wiki. I add an Idea with Ferret by typing the title, click “create new” and type the idea. Even quick than using a program like Word. Adding information, especially literature, but also community information (people, conferences, journals, tools) to my science wiki was not so easy. Until now. Now I have changed Ferret so that I can create new files the respective directories (literature, people, conferences, journals, tools) and use tags in combination with pagelist to have them integrated automatically in my Wiki. I simply enter the short name (e.g., author_year for an article), click on the radiobutton that decides where the file will be created (e.g., literature), and press “create new”.

Each of these topics has, for example, a page for the “complete list”. For Literature for example:

[[:literature|{{:back.gif }}]]
====== Literature List ======

{{topic>literature}}

====== eof ======

Pagelist (via {{topic>}}) searches all entries that are tagged with “literature”. Given that my template for Literature includes this per default, all files in the literature directory will appear here. But this is also possible for specific subtopics. And the great thing about tags is that you can combine them. For example, wanting to see a list of Literature that deals with electronic guidebooks in museums, I simply use a page that displays all files tagged with “mobile media” and “museum”:

[[:literature|{{:back.gif }}]]
====== Literature: Museum Guides ======

{{topic>literature +mobile_media +museum}}

~~NOCACHE~~
====== eof ======

This enables me to concentrate on entering and retrieving information, DokuWiki will make it available automatically. Given that I use similar tags for literature, people, conferences, journals, and tools, I use the same overview lists in all areas (the tags literature, people, conferences, journals, tools differentiate between the sections; i.e., the examples above only display literature, but no tools, because the tools entries do not include the literature tag).

Created Templates for Literature, People, Conferences, Journals, and Tools

Given the strong focus on ease of information entry and availability when needed, I created templates for my literature (available in Ferret). For example, an article template looks like this:

[[:literature|{{:back.gif }}]]
====== Template – Article ======

[[#Abstract]] | [[#Theory]] | [[#Research Question(s)]] | [[#Method]] ([[#Design]], [[#Participants]], [[#Instruments]], [[#Procedure]]) | [[#Results]] | [[#Discussion]] | [[#Conclusion]]

* **Citation:** xxxx
* **Source:** PDF
* **Key-Points**
* xxxx
* **Strengths**
* xxxx
* **Weaknesses**
* xxxx

—-

===== Abstract =====

===== Theory =====

===== Research Question(s) =====

===== Method =====

==== Design ====

==== Participants ====

==== Instruments ====

==== Procedure ====

===== Results =====

===== Discussion =====

===== Conclusion =====

~~NOTOC~~

{{tag>literature article}}
====== eof ======

or like this in the templates.htm of Ferret:

if(pagetype == “article”) {
tagline = “[[:literature|{{:back.gif }}]]\n====== ” + titelnameheader + ” ======\n\n[[#Abstract]] | [[#Theory]] | [[#Research Question(s)]] | [[#Method]] ([[#Design]], [[#Participants]], [[#Instruments]], [[#Procedure]]) | [[#Results]] | [[#Discussion]] | [[#Conclusion]]\n\n  * **Citation:** xxxx\n  * **Source:** PDF\n  * **Key-Points**\n    * xxxx\n  * **Strengths**\n    * xxxx\n  * **Weaknesses**\n    * xxxx\n\n—- \n\n===== Abstract =====\n\n===== Theory =====\n\n===== Research Question(s) =====\n\n===== Method =====\n\n==== Design ====\n\n==== Participants ====\n\n==== Instruments ====\n\n==== Procedure ====\n\n===== Results =====\n\n===== Discussion =====\n\n===== Conclusion =====\n\n\n~~NOTOC~~\n\n{{tag>literature article}}\n====== eof ======”;
};

which is chosen via

<b>Lit:</b> <a href=”javascript:transfertitel(‘article’,document.Jswdata.Seitentitel.value)”>Article</a>

Videos are not loaded on default

I also took one aspect of Circus Ponies Notebook and integrated it in my Wiki: Using JavaScript to expand cells. In the Lecture template this prevents the loading of the video when I open the page.

I have to press “Display Video” Link to see the video (and to allow Firefox to load it).

Given that I rarely want the see the video when I open the page but rather my notes, and that each loading of a video causes a spike in the CPU load and takes time (split-second), this is very comfortable. Unfortunately, the code is not mine, so I cannot show it here. Simply export a page to HTML in Circus Ponies Notebook and have a look at the JavaScript Code.

“Converter” from Circus Ponies Notebook to DokuWiki

I’ve entered a few hundred pages in my Circus Ponies Notebook file. I’m not going to re-enter them in DokuWiki. So I wrote a simple PHP script where I paste the content of a page (each cell must be expanded by pressing expand all) in a textarea and press a button that changes the content into a bullet point list. Basic, trivial, but it works for now. I keep the hierarchical information (mostly, line breaks in a cell are a problem) and can quickly move my content into the DokuWiki. CPN’s HTML export is not an option, it’s confusingly written and will not work fine with DokuWiki, even when included in <html>-tags. I include the file for Ferret here, but keep in mind that it was a very quick and semi-dirty solution (and read the Ferret posting to understand how it works).

cpn_import.htm.zip

It also has a decrease on level function (working in the textarea of the file, not in the Wiki textarea) that removes one level of the bullet point list (for example, book chapters might be the top level in CPN but would make more sense to use chapter headings in Dokuwiki for them instead of a first level bullet point). But it’s a work in progress, future ideas are a “remove empty lines” (make sense in CPN but not in DokuWiki bullet point lists) and an increase bullet point level (easy but takes more than 2 minutes). The transfer button only works if the textarea in the Wiki is empty (and, consequently, you are in edit mode).

That’s everything for now. But like I said, it’s a work is progress, worthwhile, but it will take a while. 😉

More about this topic

• DokuWiki Adjustments
• Ferret (Frame and JavaScript Enhanced Wiki)

Update

Important Note for all Mac Users: I wanted to open PDF Documents in Firefox, unfortunately, although I have installed Acrobat Professional it was not possible. At least not without a Plugin. After installing the Firefox PDF Plugin for Mac OS X 1.1.3 it works like a charm and really facilitates work with PDF-files in DokuWiki. One of the next steps is adding another Frame where the PDF file is on the left side and the page where the PDF-file is located is on the right side. This way I can easily make notes to documents directly in my Wiki. 🙂