Feel free to enter here the bugs you just found.
Diff algorithm
Very simple, needs a lot of improvement as it is far from only showing minimal differences.
Default, Blue and Dokuwiki_blog template 'lang' set to 'fr'
Steve (22/06/06) I noticed in the default, blue and dokuwiki_blog templates that the language is hardcoded to French
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
Where as in the dokuwiki template you have it dynamically set
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<?php echo $user_lang;?>" lang="<?php echo $user_lang;?>">
Print css style sheet for dokuwiki
Steve (22/06/06): I have just put together a simple style sheet to format the page when you print it. I thought I would share it, as it may save you some work.
In template.php change the css links to:
<link rel="stylesheet" type="text/css" href="<?php echo $app_path;?>themes/dokuwiki/layout.css" media="screen"/> <link rel="stylesheet" type="text/css" href="<?php echo $app_path;?>themes/dokuwiki/style.css" media="all"/> <link rel="stylesheet" type="text/css" href="<?php echo $app_path;?>themes/dokuwiki/form.css" media="all"/> <link rel="stylesheet" type="text/css" href="<?php echo $app_path;?>themes/dokuwiki/print.css" media="print"/>
I this basically changes the usage of style.css and form.css so that they are applied all the type rather than just when rendering to the screen. I then added print.css which is just used when printing.
Create new file print.css
/*Hide elements when printing */ #sidebar, #topbar, #bottombar, #linkbar, #trackbacks, #comment_link, #comments, .noprint {display:none}
/*Copyied from layout.css changed padding */ #parentnodes ul{ list-style-type: none; margin: 0; padding:0.1em; } /*Copyied from layout.css changes float:left to display:inline */ #parentnodes ul li{ display:inline; margin-left: 0.5em; margin-top: 0.5em; } /* Remove pic, just incase browser tries to render it when printing */ #logobar{ background: #72b7ec ; }
/* Display wiki title and make bigger*/ #logobar p{ margin: 1em 0; padding: 0; text-indent: 0; font-size: 1.5em; }
I have given this a quick test and it seems to work OK so far, but I have really only tried it with 'print preview' in IE 6 and Firefox 1.5. Print style sheets should work well with all fairly recent browsers.
Hope this is useful.
Small error with simple_toolbar.js and setting height and width
Steve (22/06/06): I noticed some errors in the firefox javascript debugger to do with setting height and width. I tracked them down to simple_toolbar.js.
img.style.width = '18'; img.style.height = '18';
should be
img.style.width = '18px'; //or em or %, I assumed you where using px img.style.height = '18px';
Editing and the simpletoolbar
Steve (22/06/06): I really like the new simpletoolbar, very neat.
We the styling I am using for my template I needed to have id attributes for all form elements. This also makes it usefull for manipulating with javascript.
With the last version of Wiclear I hacked the code to give the textarea's id attributes. I have just done the same with this new version and wondered if maybe you would concider making this part of the distribution.
I modified form.class.php to add the id attribute to a textarea
function addTextArea($name, $rows, $cols, $value="", $id=null) { // tabIndex $ext = 'tabindex="'.$this->getAndIncTabIndex().'" '; //sdw add support for setting id of textarea. if($id != null){ $ext .= " id="$id" "; }
$this->blob .= '<textarea name="'.$name.'" rows="'.$rows.'" cols="'.$cols.'" '.$ext.'>'.$value.'</textarea>'."n"; }
I then added ids to the 'content' and 'commit_msg' textareas, following your convention of 'f'+element name
$form->addTextarea("content", 20, 20, $content, "fcontent"); $form->addTextarea("commit_msg", 20, 3, $commit_msg, "fcommit_msg");
The only issue to this is that it breaks your simple toolbar plugin, so I changed hooks.inc.php and commented out
$pluginManager->addPluginCallback("simpleToolbarCallback");
and then edited simple_toolbar.js
function initSimpleToolbar() { //Check browser supports DOM getElementById if(!document.getElementById) return false; //sdw change if(!document.getElementById('fcontent')) return false; var textarea = document.getElementById('fcontent');
I thought you could also set your toolbar script to add a toolbar to any textarea that had a class of 'simpletoolbar' or similar by using document.getElementsByTagName('textarea') and looping through array and testing for the correct class (you can add multiple class to an element i.e. class="title simpletoolbar otherclass"
var textareas = document.getElementsByTagName('textarea'); for (var i=0; i < textareas.length; i++){ //process only textareas with a class of 'simpletoolbar' if(new RegExp('\bsimpletoolbar\b').test(textareasi.className)){ var elementToAddToolBarTo = textareasi; } }
Hope all that makes sense and it makes life much easier with each form element having a constant id.
Simple toolbar heading/title levels round the wrong way
Steve (22/06/06): When you select H1 it only inserts ! instead of !!!, looked at the javascript and the values !, !!, !!! should be !!!,!!,! in the wikiSyntaxes array.
content delete confirmation
Steve (21/06/06): I thought I would share a modification I have made. I needed the ability to get the user to confirm that they where deleting a page. I had a couple of unhappy people when they accidently clicked 'delete'! I am also adding the same thing to making a page the root. I hope this is the right way do this.
in content.lib.php I added
$contentBoxHandle["delete"] = "contentDelete";
changed
$userActionHandle["delete"] = "onContentDelete";
to
$userActionHandle["deleteconfirmed"] = "onContentDelete";
and added the function
function contentDelete(){ global $user; global $user_lang; global $wiki; global $node; global $wikirender; $html = '<h1>Confirm delete</h1>'; //$html .= "<p>{$confirm}</p>"; $html .= '<p>This will permentally delete the page and history from the wiki, you will not be able to undo this action.</p>'; $html .= "<p>Please confirm you wish to delete '{$node->title}'</p>"; $html .= "<p><a href="?title={$node->title}REDIRECT TO: http://wiclear.free.fr/index.php?title=amp%3Bmode%3Ddeleteconfirmed&from=Bugs
amp;lang=$user_lang">Yes (delete)</a> | <a href="?title={$node->title}&lang=$user_lang">No (take me back)</a></p>"; return $html; }
David(21/06/06) : very usefull and perfect. I'll add it in 0.11. (or perhaps 0.10.1 because 0.10.0 has a lot of rough edges (installation, update, no database, no configuration files : I released it too quickly without proper test)
David(21/06/06): By the way, you seem to have upgraded to 0.10. Did you have a look to variables.lib.php ? You can now hack it to add easily a prefix to session variable. If needed it is also possible to add a new "ini" configuration variable to do it at startup...
David(22/06/06) : Steve by the way, in order to give you proper copyright notice for this patch, can you either send me an email or register ?
Steve (22/06/06): Hi, I've registered under the login 'cvibe'.
A correction to the above, the following line should be removed (left over from me testing the code!)
$html .= "<p>{$confirm}</p>";
session workaround bug
Steve (21/06/06): I think I found a bug in util::sessionWorkaround, this first thing it does is "return;". When I ran the install with this in, it tells me my session directory is not writeable. Once I remove it says my session directory is writeable and gives me a green tick. Just to confirm my php session directory is writeable.
David(21/06/06): Yep, found it yesterday too and fixed it by doing instead :
return $path;
This sessionWorkaround thing was a workaround added in 0.9 to overcome problems with particular hosting configuration. I disabled it "quickly" in 0.10 because it was rendered useless by my provider. But if by any bad luck someone encounter a session problem, he can try to fix it by commenting the return.