monobook for DokuWiki - Discussions

Back to main page "monobook for DokuWiki"

There's always room for improvement. If you're able to add any contributions to make monobook for DokuWiki better, please let me know or discuss your thoughts right here (preferred).

Rules and notes:

• Please use ==== Level 3 Headlines ==== to open a new “thread”/issue.
• Leave enough free lines to the other topics to keep the source readable.
• Take care if you add your topic below “Bugs”, “Additions and ideas” or “Other”.
• Make sure, you got the latest template version. Maybe your wish and/or problem is already added/fixed.
• Before you add something: check the roadmap if your feature is already planned/in development.
• I read the bug reports in here. So don't be afraid, I do not ignore the reported stuff (even if I may not got enough time to answer here)!
  — AndreasAndreas
  
  Horb a. N. / Karlsruhe, Germany 2011/05/02 05:25

If tag plugin is installed and tags are listed at the beginning of an article, then the TOC div is float at the top of the tags (Normally the TOC div should be at a top-horizontal level with the tags).

However, It's hard to say it's a bug of monobook or a bug of the tag plugin. It can be fixed by modifying style.css of tag plugin, replacing “clear: both;” in line 5 with “clear: left;”. —- caii 2010/07/05

Bureaucracy -plugin is not completely compatible with monobook template. So far I've had these problems:

Textarea spreads to width of the fieldset and the label is hidden when scrolling down the textarea.

When a field (number, textfield etc.) has non-valid value (e.g. letters in number field) the DW with monobook does not show the (!) messages at top of the page.
There is a way to get the constraint messages to show temporarily (not a workaround thou).

• Open a Bureaucracy form, for example Form A.
• Open another form, say Form B.
  • This form must have constraints.
  • Submit the form with non valid values, so the constraints prevents it.
    • Constraint messages DOESN'T appear (incorrect) on top of the page, but the non valid field labels become red (correct).
• Edit Form A to have syntax error and save it.
  • Syntax error message appears on top of the page.
• Open third form, Form C.
  • This form must have constraints.
  • When you submit the form, the constraint messages appears on top of the page and the non valid field labels become red.

— Ciove 2010/08/18

Update to monobook 2010-08-17 did not solve the problem with bureaucracy plugin. — Ciove 2010/08/23

If you previously used this tip to hide link icons, you may have noticed that there is now an indent infront of your links.

To fix this use this in your userstyle.css:

#content div.dokuwiki a.urlextern,
#content div.dokuwiki a.interwiki,
#content div.dokuwiki a.windows,
#content div.dokuwiki a.mail,
#content div.dokuwiki a.media {
  padding-left: 0;
  background: none !important;
}

— casperCasper
casper

2010/11/10 21:51

Currently the headlines default on my configuration to run a rule underneath the headline. While this is common typesetting model (to underline headings) such underlines should end about 1 pica after the text ends.

Instead the rule goes across the page and implies a break in the page content, when in fact the text above the rule is the subject header for the text that follows. How can I change the rule to go above the header instead of below? This will also make the placement of “edit” buttons be more sensible. btw, the edit buttons on my wiki are pulling weird sections of the text and then when I save, the original section is corrupt. but it is working here. I have recently upgraded to Anteater and the latest Monobook.

Things which are done… topics below may be deleted some day. See the sections above for actual talks.

To correct the visualization of arrows in the bottom of editor page, add this line to main.css¹⁾ /user/screen.css:

#size__ctl {
  float: right;
}

Fixed in the current development version, the next release (today or tomorrow) does not have this layout problem anymore. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/13 03:35

I found a solution to the fact that the breadcrumbs (both Tracking and Hierarchical) are printed along with the (body)content.

1st solution: hiding tracking breadcrumbs only

For removing only the tracking breadcrumbs, add the folling code to the user/print.css

div#catlinks, .bcsep, a.breadcrumbs{ /* tracking breadcrumbs*/
  display: none !important;
 }

I cannot figure out how to do the same thing for the hierarchical breadcrumbs, because they do not seem to have a uniform span class, nor does blocking the div class catlinks seem to do the work.

2nd solution: a workaround to block both types of breadcrumbs

When comparing the templates main.php with an older version I found the difference coming in the following line:

echo "\n          <div class=\"catlinks\"><p>\n            ";

This line can be located four times. All four can be altered to

echo "\n          <div class=\"catlinks\"><p class=\"catlinks2\">\n            ";

In the print.css now add catlinks2;

div#catlinks, p.catlinks2, .bcsep, a.breadcrumbs{ /* (hierarchical) breadcrump navi */
  display: none !important;
 }

Notes

Firstly, “catlinks2” is not a typo, but else I had to change a css file, which only would become more alterations.. It does not realy matter what you call it, as long as they're all the same, and not existing in any css file, in this case “sldkjfl” would have the same effect as “catlinks2” because they're not to be found in any css file..

Second, the first solution is far “cleaner”, the second one has to alter the main.php, which gives more work, especially when updating.

— Theo 2010/06/10 08:56

This was fixed with one of the last updates. Please upgrade to the current template version and you don't need any hacks. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2011/05/04 22:51

I've been testing out the subscription feature in Anteater a little bit and have noticed a bug. When I subscribe to a page the “Manage your subscriptions” button disappears and you can no longer access it via a button (obviously can still reach it if you remember the URL).

If I edit conf\tabs.php to be the following, then the button always shows up. I know I'm not supposed to edit that, but whenever I make the change to user\tabs.php the change never shows up.

//(un)subscribe tab
//ATTENTION: "ca-watch" is used as css id selector!
  if (!empty($conf["useacl"]) &&
      !empty($conf["subscribers"]) &&
      !empty($loginname)){  //$loginname was defined within main.php
      //if (empty($INFO["subscribed"]) && //$INFO comes from DokuWiki core
        //  actionOK("subscribe")){ //check if action is disabled
          $_monobook_tabs["ca-watch"]["href"] = wl(cleanID(getId()), array("do" => "subscribe"), false, "&");
          $_monobook_tabs["ca-watch"]["text"] = $lang["btn_subscribe"]; //language comes from DokuWiki core
      /*}elseif (actionOK("unsubscribe")){ //check if action is disabled
          $_monobook_tabs["ca-watch"]["href"] = wl(cleanID(getId()), array("do" => "unsubscribe"), false, "&");
          $_monobook_tabs["ca-watch"]["text"] = $lang["btn_unsubscribe"]; //language comes from DokuWiki core
      } */

I guess the “btn_unsubscribe” doesn't exist anymore? — mpete510mpete510

2010/11/12 22:55

This might be the same bug as 2079. — achAnika Henke
ach

London, UK 2010/11/13 12:35
I updated to the latest build of dokuwiki and reinstalled monobook and am still hitting the issue. — mpete510mpete510

2010/11/15 15:50
Any thoughts on this? — mpete510mpete510

2010/11/23 17:28
Anyone else experiencing this? — mpete510mpete510

2011/01/17 17:08
I do have this bug. Any other Ideas? — cupaschtercupaschter

Berlin 2011/02/19 16:21

I'll fix this in the next release (propably this WE) — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2011/02/23 15:03
Awesome. Thanks Andreas! — mpete510mpete510

2011/02/25 16:36

I fixed the bug (see commit for details), next release (tomorrow) will include this. Stay tuned. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2011/03/15 04:48

Thanks Andreas. I tested it this week on my test site and it works great. Upgraded my main wiki and works there as well. :) — mpete510mpete510

2011/04/02 14:36

First off let me just say thanks for taking over maintenance. This is a great template and its good to see it develop further.

I just want to report that the template isn't really working for me. I'm using version 2010-01-19 with “hotfixed-lemming”. The problem seems to come from the style sheet declarations in monobook/style.ini. Using the current version I get this error in my PHP logs:

syntax error, unexpected '/' in ../../lib/tpl/monobook/style.ini on line 26

Having a look it appears that for some reason having subdirectories in the style declarations causes these problems (in fact I reported something similar in the legacy version). Looking further I noticed that other templates avoided this by putting the '.css' files in the template folder itself rather than in a subdirectory. For example:

main.css = screen
screen.css = screen
print.css = print
rtl.css = rtl

Replacing the error causing lines and copying the .css files out to monobook/ fixed this problem for me and the template appeared like what it should. I don't know if this is caused by a Linux vs Windows thing but the bottom line is having the .css not in subdirectories solved this problem. It would be good if this could be sorted out as the new version is looking quite good. Thanks! – Marc 20/Jan/10

Hi Marc. Are you running a windows machine? If yes, I'm going to setup an Apache ASAP to test this… right now, I only tested it on Linux. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/20 12:39

Hi Marc, me again. Can you please provide your PHP-version and environment (Webserver, OS etc.)? Maybe we can find a syntax which works everywhere… — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/20 14:18

Hi Andreas. I'm currently running Linux (Ubuntu) using XAMPP for Linux version 1.7.2 as a webserver. The PHP version is 5.3.0. — Marc 21/Jan/10

The problem is: DokuWiki parses the style.ini and expects the following format:

path_to_file.css = media

As it seems, some Webserver/PHP/OS combinations do not parse INI-files with ”/” in the keys (wich is not exactly their fault. Only alphanumeric chars are allowed in ini-keynames, but I had no choice cause DokuWiki is not using a format like screen[] = “path_to_file.css” and I need a file structure to get things done without being messy). The fix you mentioned worked in the old version because it simply did not use the style.ini, and therefore it was no problem that it provides a format DokuWiki can't understand (additionally, only the last entry would be stored cause every ”screen = ” overwrites the value before… ”screen[]” would be the syntax to submit an array). If I know which OS/Webserver/PHP combinations are making trouble, I can provide a workaround. I think of something like an “If you getting errors [yadda yadda…]: 1. deactivate compress. 2. Delete style.ini”. I would simply add a check for style.ini existence to the main.php → If is not there, the template loads the CSS-Files manually.
To cut a long story short: Please provide version information, we can solve this problem…. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/20 15:09

Hi Marc. The problem is PHP Bug #49692. I added a workaround in the current development version (will be included in the next release → today or tomorrow) for manual CSS loading, the only thing a user has to do if he is affected to trigger this workaround is to delete monobook's style.ini. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/20 15:09

Hi Marc. Please update to the latest version 2010-01-20 and delete monobook's style.ini to get the workaround doing it's job in your environment. Please note that this may not be necessary anymore after upgrading PHP in the future. You can simply test if you still need the workaround if you put the style.ini back into place. If everything works, you PHP is no more affected by Bug #49692 — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/20 19:04

I will give this a go. I'll also do an update for XAMPP (Linux) which has PHP 5.3.1 and see how things go. Thanks for the fast reply! — Marc 21/Jan/10

Okay, I can confirm that your workaround works perfectly. Deleting style.ini did indeed bring in the new look. Waiting for download to complete to upgrade XAMPP.

On upgrading to PHP 5.3.1 the problem with '/' in style.ini is now fixed and the template it almost working fine. I still didn't get any CSS but looking at the code it seems that there may be (possibly) unneeded quotation marks in the declarations

static/3rd/monobook/main.css = "screen"

Removing them fixes the problem:

static/3rd/monobook/main.css = screen

The new template is looking good. Keep up the great work!

— Marc 21/Jan/10

Thanks for reporting this. I will remove the quotation marks in the next release (I did not know that some environments are having trouble with them). — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/21 12:41

• Table in site_notice have no border
• The tabs Export: ODT, Subscribe revision, Edit this page, …, are show like external links if Use fully canonical URLs are set to TRUE in the wiki configuration

— mluigi 2010/01/12 09:59

Fixed in the current development version, the next release (today or tomorrow) does not have these layout problems anymore . Reason was: the CSS class “dokuwiki” was (not) applied (solution → I moved the sitenotice deeper into the page structure) and the CSS for external links addressed all links, not only “dokuwiki” CSS class members — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/13 03:29

Some system messages are displayed twice. Add for example 'do=check' to your URL. Then there should be some information displayed: Once in the header and once in the footer. This applies to general system error messages as well. Casper @ 2010/01/13 13:50

Thank you for your report, but this should be already fixed in version 2010-01-13 released today – or do you mean something else? — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/13 15:22

Yes fixed in version 2010-01-13 Casper

I noticed also two more things that don't work in IE7 (in FF they work):

• in the admin area, no images where displayed. Just the links to ACL etc are shown
• all tabs looks the same (the active tab should have no border line at the bottom), you can't figure out which one is active.

Casper @ 2010/01/13 13:50

IE8 works, IE7 as you described not. I'm trying to figure out what to do against this behaviour… does anyone have hints/tips? — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/13 15:22

for the tab thing: only hint I can give is, that it works with monobook legacy. Maybe you can copy a working style sheet from the old version? Casper @ 2010/01/13 17:54

Working on it… I hope I can figure it out. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/16 16:35

Tab problem fixed in the latest development version, will be included in the next release. Reason was my own style which was more specific than the IE7fixes.css by the MediaWiki monobook. Therefore my one ruled the cascade… — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/16 19:50

Admin area problem fixed in the latest development version, will be included in the next release. Drawing a border around every <li>-Element does the job (maybe this triggers the IE-internal “hasLayout”…). Therefore I added a 1px border using the background color to hide it. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/16 20:33

Thanks a lot Casper

First: Sorry for my english, it’s not even the best.
Now my problem: I’ve installed the monobook template because of the function “closed wiki”. But since installing, the buttons “select headline”, “special chars”, “fontsize” and “fontcolour” doesn’t act anymore. The other buttons can be used without any problems.
An user in the DokuWiki User Forum told me to announce my problem at this place. He guess it is a bug.
Thanks for helping me and solving the problem.
— KayCee 2010/08/25

Hi Kaycee. This bug should be fixed in monobook version 2010-08-17. Simply update and emtpy your browser cache afterwards (Firefox: reloading your Wiki with CTRL + F5 should be enough) and the problem should be gone. If not: which browser do you use? — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/08/26 18:28

Thank you very much for your advice. The update solved my problem. — KayCee 2010/08/26 19:02

Hi. I've just downloaded monobook version 2010-01-12 (the current as of the time of writing this) and installed to check an issue that was reported at the IRC channel. After getting login rights at another wiki using the template, I can confirm user ck01 from the IRC channel on the following issue: DokuWiki message area is repeated twice in each page. In other words, the nice background and icons section used for example to update_check is displayed twice: once at the beginning of each page's content and another one at the end. Behaviour is more patent when using ?do=check action.

Steps to reproduce:

1. Enter to a DokuWiki page (check action must be enabled).
2. Append ?do=check to the URL
3. Hit <ENTER>

Observable Behaviour:

Page content goes like this:

Notification area
Page content
Notification area
Footer

Intended Behaviour:

Page content should go like this:

Notification area
Page content
Footer

Problem may be related to repeated invocation of html_msgarea() in the template's main.php; that function is responsible for loading the available messages and displaying them. The function itself is called at lines 383 (above page content) and 429 (below page content). – — Luis 2010/01/12 23:23

First of all: thank you for your detailed report. It is not a bug, it is was a feature . I thought the user takes notice of messages easier when doing this – but if this is confusing people → mission failed … You're right: if there is more than one message triggered by DokuWiki (e.g. when doing “check”), it looks strange. I will remove this right now… in the next release (this night or tomorrow), the second call of html_msgarea() will be gone. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/13 02:05

You're welcome. The behaviour was reported as such via the IRC channel and I considered it a consequence of leftover code or maybe a weirdness element, since I couldn't find it advertised as a feature and turned out to be cumbersome for certain notifications (such ?do=check, or backend upgrade not setting the messages file up-to-date, which will result in a tower of messages…). I concur with you in that nowadays people have to be hammered down with messages for them to even take notice. As a probable compromise if you still want to “make note twice” (which is not a bad idea), I think a properly stylized anchor link with a message like ” Check pending system messages above!” could better do the trick. Thanks for your understanding. — Luis 2010/01/13 15:40

I thought about your suggestion (→ adding something like ” Check pending system messages above!”)… it would not be hard to implement, a check like

if(!empty($MSG)) { yadda yadda...; }

would do the trick. But monobook still would be the only template around showing such a behavior… maybe users don't take notice of messages anymore when switching from monobook to another template cause of this. Therefore I decided not to (re-)implement something like a whatever-looking 2nd way of notification. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/16 16:08

When running against W3C Validator it returns errors. To fix, first edit static/3rd/monobook/main.css and change the line

#catlinks {

to

.catlinks {

Then, in main.php change

echo "\n          <div id=\"catlinks\"><p class=\"catlinks\">\n            ";

to

echo "\n          <div class=\"catlinks\"><p>\n            ";

Page should now parse as valid XHTML on http://validator.w3.org/

Thanks for reporting this. Replacement was also needed in IE60Fixes.css. The newest version (release → today or tomorrow) includes this fix. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/05/28 21:21

Hy if i try Uploud Files in the wiki with the Mediamanager and i klick on the upload link in the editor ore on the menue i become following error message

Warning: include(DOKU_TPLINCmain.php) [function.include]: failed to open stream: No such file or directory in /var/www/vhosts/domainname/httpdocs/wiki/lib/tpl/monobook/mediamanager.php on line 30

Warning: include() [function.include]: Failed opening 'DOKU_TPLINCmain.php' for inclusion (include_path='.:') in /var/www/vhosts/domainname/httpdocs/wiki/lib/tpl/monobook/mediamanager.php on line 30 

Any suggestion why it will not work? With the default templade it will work correct. kind regards Fabian Rolle.

Sorry, I cannot reproduce this. Even if there is a bug, I need more information (System? Installed the common way or maybe via debian package manager?). DOKU_TPLINC is a constant set by the DokuWiki core. Please check your basedir settings and deactivate all 3rd party plugins to check if one of them is triggering the error. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/03/29 11:09

Monobook handles some pages as special, e.g. “discussion page”, “pages under the wiki namespace” and “media manager”. If a namespace starts with “wiki.”, the page is handled as special page (these pages got another background). This behaviour should only be if the namespace is “wiki:”. — Casper 2010/03/02 11:02

Fixed in the current development version (release: today or tomorrow), replaced the used regex. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/05/28 22:31

Whenever a header is named “Content” I'm seeing weird style sheet behavior and indentation.

Reason: All the content in located within a <div id=“content”> like it is realized in the “original” monobook for MediaWiki. If you create a headline named “content”, it gets the same ID and therefore some id=content-only CSS-rules. The only way I could prevent this is searching and replacing the headline's ID on every page load or through renaming the ID and editing the original monobook for MediaWiki monobook style sheets. But the first one would break some DW functions (e.g. link#headline), the last one would make most existing 3rd-party CSS hacks and userstylesheets for monobook work no more. Therefore I have to say: won't fix until I don't find a solution without ugly side effects. But thank you for reporting this. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/23 15:01

I noticed a bug or error: when trying to print a table in the new monobook template, only raw text will be printed without the lines or the coloured cells (using ^ ). I cannot find an solution to this, because for as far as I can see, the tables are not suppressed by the print.css or commonPrint.css..

Addition: it does not make any difference when using the plugin tablewidth or not. — Klaus 2010/03/16

Finally found a way to solve this; copy the following into your user/print.css

table.inline {
  font-size: 80%;
  background-color: #ffffff;
  border-spacing: 0px;
  border-collapse: collapse;
}
table.inline th {
  padding: 3px;
  border: 1px solid #000000;
  border-bottom: 1px solid #000000;
}
table.inline td {
  padding: 3px;
  border: 1px solid #000000;
}
.leftalign {
  text-align: left;
}
.centeralign {
  text-align: center;
}
.rightalign {
  text-align: right;
}
> 

Works just fine for me!
Theo – 12/05/10

I included these improvements with some small changes in the current development version (release: today or tomorrow). Thanks, Theo! — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/05/28 22:42

Can't edit pages as the text area jumps around. Works fine with the DokuWiki 'default' template. Here is the bug report/fix for the 'default' template. Not sure where to change it in monobook. Switching to Compatibility Mode in IE8 fixes it.

Thanks for reporting this, I'll test it for myself today and try if this reproducible for me… — Andreas 2010/01/30 12:01

Workaround: When you disable the editors line break the problem went away - for me at least. — Casper 2010/03/02 08:50

This is not a monobook but an IE8 bug. I implemented a workaround in the newest version of monobook (release: today or tomorrow). I also wrote a blog posting about it (may be interesting for webdevelopers). But I cant' get completely rid of it right now, even with the known workaround (maybe some DW Javascript triggers the bug in some cases). Does anyone have a suggestion? — Andreas 2010/05/29 11:18

I added a workaround in version 2010-06-02 till there is a better solution: header(“X-UA-Compatible: IE=EmulateIE7”); (will be send for “edit” action only).

The two login fields username and password have the same size. Unfortunatelly they are not ordered parallel. Tested in IE7/8 and FF 3.6 — Casper 2010/06/26 23:35

next realease will fix this — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/06/27 21:12

There is no edit link in navigation frame as in legacy version. Has it been removed on purpose or am I missing something? Ciove/2010/07/06 12:13

I think it's on purpose. You can change the navigation via http://your-dokuwiki-installation/wiki/navigation — Casper 2010/07/06 13:25

Ok, thx, no big deal. Ciove/2010/07/08 15:02

If editing any page, the pull down menu of “Select Headline”, “Smileys” and “Special Chars” buttons didn't show up. - 13.07.2010 moonhawk

I will second this one. I am seeing the same behavior, but it works fine in the default template. July 28, 2010 Restlessmind

Add me too. (php -v : 5.2.14 with Suhosin-Patch 0.9.7 (cli) ) July 30, 2010 ihsan

I'll try to reproduce this ASAP — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/08/12 04:31

I just installed the template, buttons are all there but this three won't work - they do work with other templates - 2010-08-12 chrohl

I fixed the bug (z-index issue). Please update to the latest version. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/08/17 23:32

No change here. ihsan. 2010/08/19

Have you cleaned your browser's cache? And try to add purge=true to the DokuWiki url one time.

Tried all but nothing changed. I've installed a new wiki to test. Everyting seems ok. ihsan 2010/08/25
I've figured out that my problem is due to the frootysearch plugin ihsan 2010/08/27

Is there a way to hide the “breadcrumbs” in the mediamanager popup window? — Casper 2010/06/05 03:25

I found myself a working solution:

user.js

(function(){
	// from: http://code.google.com/p/domready/
	// domready - The smallest subset possible from jQuery to support dom Ready event. 
	// A big thanks to John Resig and the jQuery team (http://www.jquery.com/) for the parent library and the real hard work to make sense of the browser idiosyncrasies we have today. 
 
    var DomReady = window.DomReady = {};
 
	// Everything that has to do with properly supporting our document ready event. Brought over from the most awesome jQuery. 
 
    var userAgent = navigator.userAgent.toLowerCase();
 
    // Figure out what browser is being used
    var browser = {
    	version: (userAgent.match( /.+(?:rv|it|ra|ie)[\/: ]([\d.]+)/ ) || [])[1],
    	safari: /webkit/.test(userAgent),
    	opera: /opera/.test(userAgent),
    	msie: (/msie/.test(userAgent)) && (!/opera/.test( userAgent )),
    	mozilla: (/mozilla/.test(userAgent)) && (!/(compatible|webkit)/.test(userAgent))
    };    
 
	var readyBound = false;	
	var isReady = false;
	var readyList = [];
 
	// Handle when the DOM is ready
	function domReady() {
		// Make sure that the DOM is not already loaded
		if(!isReady) {
			// Remember that the DOM is ready
			isReady = true;
 
	        if(readyList) {
	            for(var fn = 0; fn < readyList.length; fn++) {
	                readyList[fn].call(window, []);
	            }
 
	            readyList = [];
	        }
		}
	};
 
	// From Simon Willison. A safe way to fire onload w/o screwing up everyone else.
	function addLoadEvent(func) {
	  var oldonload = window.onload;
	  if (typeof window.onload != 'function') {
	    window.onload = func;
	  } else {
	    window.onload = function() {
	      if (oldonload) {
	        oldonload();
	      }
	      func();
	    }
	  }
	};
 
	// does the heavy work of working through the browsers idiosyncracies (let's call them that) to hook onload.
	function bindReady() {
		if(readyBound) {
		    return;
	    }
 
		readyBound = true;
 
		// Mozilla, Opera (see further below for it) and webkit nightlies currently support this event
		if (document.addEventListener && !browser.opera) {
			// Use the handy event callback
			document.addEventListener("DOMContentLoaded", domReady, false);
		}
 
		// If IE is used and is not in a frame
		// Continually check to see if the document is ready
		if (browser.msie && window == top) (function(){
			if (isReady) return;
			try {
				// If IE is used, use the trick by Diego Perini
				// http://javascript.nwbox.com/IEContentLoaded/
				document.documentElement.doScroll("left");
			} catch(error) {
				setTimeout(arguments.callee, 0);
				return;
			}
			// and execute any waiting functions
		    domReady();
		})();
 
		if(browser.opera) {
			document.addEventListener( "DOMContentLoaded", function () {
				if (isReady) return;
				for (var i = 0; i < document.styleSheets.length; i++)
					if (document.styleSheets[i].disabled) {
						setTimeout( arguments.callee, 0 );
						return;
					}
				// and execute any waiting functions
	            domReady();
			}, false);
		}
 
		if(browser.safari) {
		    var numStyles;
			(function(){
				if (isReady) return;
				if (document.readyState != "loaded" && document.readyState != "complete") {
					setTimeout( arguments.callee, 0 );
					return;
				}
				if (numStyles === undefined) {
	                var links = document.getElementsByTagName("link");
	                for (var i=0; i < links.length; i++) {
	                	if(links[i].getAttribute('rel') == 'stylesheet') {
	                	    numStyles++;
	                	}
	                }
	                var styles = document.getElementsByTagName("style");
	                numStyles += styles.length;
				}
				if (document.styleSheets.length != numStyles) {
					setTimeout( arguments.callee, 0 );
					return;
				}
 
				// and execute any waiting functions
				domReady();
			})();
		}
 
		// A fallback to window.onload, that will always work
	    addLoadEvent(domReady);
	};
 
	// This is the public function that people can use to hook up ready.
	DomReady.ready = function(fn, args) {
		// Attach the listeners
		bindReady();
 
		// If the DOM is already ready
		if (isReady) {
			// Execute the function immediately
			fn.call(window, []);
	    } else {
			// Add the function to the wait list
	        readyList.push( function() { return fn.call(window, []); } );
	    }
	};
})();
 
(function () {
	function hideBreadcrumbs() {
		if (location.href.match(/^https?:\/\/.*\/lib\/exe\/mediamanager.php/i)) {
		        var divs = document.getElementsByTagName("div");
		        for (var i = 0; i < divs.length; i++) {
                		if (divs[i].className == 'catlinks') {
					divs[i].style.display = 'none';
				}
		        }
		}		
	}
	DomReady.ready(function(){hideBreadcrumbs();});
})();

Put this in your lib/tpl/monobook/user/user.js file and make sure to check the 'loaduserjs' box in the template settings.

I am pretty sure, that there are more efficient ways to do this - so feel free to post your suggestions.

— Casper 2010/06/10 17:06

My problem was indeed different
The solution you brought seems to work perfectly for me, both on IE8 as FF.
Thank you
Grtz Theo

Please update to template version 2011-05-04. breadcrumbs are now hidden within the mediamanager without any hacks. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2011/05/04 22:51

To have an Export PDF tab, in the conf/tabs.php²⁾ /user/tabs.php, after the section ODT plugin: export tab

//PDF plugin: export tab
if (file_exists(DOKU_PLUGIN."html2pdf/action.php") &&
    !plugin_isdisabled("html2pdf")){
    $_monobook_tabs["tab-export-pdf"]["text"] = $lang["monobook_tab_exportpdf"];
    $_monobook_tabs["tab-export-pdf"]["href"] = wl(cleanID(getID()), array("do" => "export_pdf"), false, "&");
}

— mluigi 2010/01/12 09:48

Added this to the current development version, the next release (today or tomorrow) will include this. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/01/13 03:35

Kann mir jemand einen Tipp geben, wie ich in der Toolbox vor “Links auf diese Seite” “Recent Changes” einbauen kann? Dafür wäre ich sehr dankbar. Viele Grüße von zfldm.05/05/2010

Please can you help me to insert “Recent Changes” in the existing toolbox? Thank you! zfldm.05/05/2010

This should work, it should be put into the boxes.php file in the conf folder.
For instance, after this (for me at line 45)

if (tpl_getConf("monobook_toolbox_default")){
   //define default, predefined toolbox
   $_monobook_boxes["p-tb"]["xhtml"] =  "        <ul>\n"
   // added recent changes page to toobox
   ."          <li><a href=\"".DOKU_BASE."doku.php?do=recent"."\" rel=\"nofollow\">".hsc($lang["monobook_changes"])."</a></li>\n"
   ."          <li id=\"tb-whatlinkshere\"><a href=\"".wl(cleanID(getID()), array("do" => "backlink"))."\" rel=\"nofollow\">".hsc($lang["monobook_toolbxdef_whatlinkshere"])."</a></li>\n"
   //we might use tpl_actionlink("backlink", "", "", hsc($lang["monobook_toolbxdef_whatlinkshere"]), true), but it would be the only toolbox link where this is possible... therefor I don't use it to be consistent
   ."          <li id=\"tb-upload\"><a href=\"".DOKU_BASE."lib/exe/mediamanager.php?ns=".getNS(getID())."\" rel=\"nofollow\">".hsc($lang["monobook_toolbxdef_upload"])."</a></li>\n"
   ."          <li id=\"tb-special\"><a href=\"".wl("", array("do" => "index"))."\" rel=\"nofollow\">".hsc($lang["monobook_toolbxdef_siteindex"])."</a></li>\n";

Note that you could put this in any sequence you prefer.
Hope it'll help
Theo

Thank you!!! zfldm 10/05/2010

Link to Recent changes is now included in the default toolbox since release 2010-05-29

I used to have the translations list, just like Wikipedia itself, underneath the toolbox. I found a solution for this, though it requires some work..

First, in the main.php I added the following to line 770, right under the 'show boxes' part, but before the '</div> <!– end of the left (by default at least) column –>'

echo "\n <div id=\"p-tb'\" class=\"portlet\">\n";
      if (file_exists(DOKU_PLUGIN."translation/syntax.php") &&
          !plugin_isdisabled("translation")){
		  echo "<h5>\n";
		  echo "".hsc($lang["translations"])."\n";
		  echo "</h5>\n";
          echo "\n      <div class=\"dokuwiki\">\n";
          $translation = &plugin_load("syntax", "translation");
          echo  "      ".$translation->_showTranslations()
               ."\n      </div>\n";
      }
echo  "</div>\n";
?>

Then, if you prefer to remove the translate piece at the top of the wiki pagine, change or remove the following on line 547 (between 'collumn-content' and 'bodycontent'..

      <?php
      //take care about Andreas Gohr's translation plugin,
      //see http://www.dokuwiki.org/plugin:translation
/*      if (file_exists(DOKU_PLUGIN."translation/syntax.php") &&
          !plugin_isdisabled("translation")){
          echo "\n      <div class=\"dokuwiki\">\n";
          $translation = &plugin_load("syntax", "translation");
          echo  "      ".$translation->_showTranslations()
               ."\n      </div>\n";
      }
*/
      ?>

Lastly, change helper.php of the translation plugin, replace the lines 127 till 133 with:

        $out  = '<div class="pBody">';  //changed class from plugin_translation into pBody -- Theo - 19/04/2010
        $out .= '<span>'.$this->getLang('');  // lang removed, originally $out .= '<span>'.$this->getLang('translations'); -- Theo - 19/04/2010
        if($this->getConf('about')){
            $out .= '<sup>'.html_wikilink($this->getConf('about'),'?').'</sup>';
        }
        $out .= '</span> '; // : removed, originally $out .= ':</span> '; -- Theo - 19/04/2010

Perhaps someone can use this, I for myself prefer this way, also because the space it saves on the top of the wiki

Grtz, Theo

I'm gonna think about a solution to realize listing the translations this way in future versions. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/06/02 02:15

Every version >= 2010-06-29 displays the language links within the sidebar, without the need to modify the plugin or the template. — AndreasAndreas

Horb a. N. / Karlsruhe, Germany 2010/08/20 23:32