Wiclear

You are here :

 Bugs

Thursday, 22. June 2006 18:37:26, by David Jobet

 

Feel free to enter here the bugs you just found.


Discussion

Steve (22/06/06): Sorry if I have sent too many bugs and requests, I am sure you have caught many of these already. I thought I would send everthing just incase, I hope this is useful to you. I really like the simple toolbar and look forward to having section editing and the contents list that I see you have working on your site. Once again thanks for your hard work. :-) Steve

David (22/06/06) : Did I say I'm simply amazed by all those reports ? That's very welcome ! I'm just impressed ! Thank you very much !

Given your comments I thought you had upgraded to 0.10 wich includes section editing and toc generation (have a look to your wiki preferences)

By the way, I have a request for comment : posting code in this page is great but I think we can "enhance" the process. There are many ways : forum, mail, etc... The problem is I have none. So if we want to keep a handy copy of all your contributions, I'll suggest you create a new page for each contribution. (you can create a page under page Contributions which already exists). What do you think ?

Another thing : I'll add you to the "Developper" group. This will give you read/write access to all pages.


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;?>">

David(22/06/06). Yep this is because I stopped maintaining those themes. I'll fix it.


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.

David (22/06/06) : Too bad. I mean what you did is great, but did you noticed the "Print" and "Source" link in the right side box ? This will be part of next release.


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';

David (22/06/06). Right : I'll fix it.

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.

David (22/06/06) : Yes I suppose I can incorporate most of those changes, but I'll prefer fix the call to addPluginCallback("simpleToolbarCallback") instead.


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.

David. Well In fact that depends on the configuration of WikiRenderer (you can invert the direction) but you're right I need to fix it.

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}&amp;lang=$user_lang&quot;&gt;No (take me back)&lt;/a&gt;&lt;/p&gt;&quot;; 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.