Feel free to enter here the bugs you just found.
Unescaped html entities when wikirenderer outputs errors on content edit page
Steve (12/07/06) :I noticed when editing the steve ideas page that in firefox it gives the following error "XML Parsing Error: not well-formed". I tracked the problem down to the wikirenderer errors list not having it's html entities escaped. To fix, edit content.lib.php and change
foreach ($wikiRenderer->errors as $lineNumber=>$line) { $blob .= '<li>'.tr("Line").' '.$lineNumber.' : '.$line.'</li>'; } $blob .= '</ul>';
to
foreach ($wikiRenderer->errors as $lineNumber=>$line) { $blob .= '<li>'.tr("Line").' '.$lineNumber.' : '.htmlentities($line).'</li>'; } $blob .= '</ul>';
David (13/07/06) : done
String Handling
Daniel (08/07/2006) Such a good wiki, but the speed could be vastly improved by not using X.blob .= "string"; all the time. PHP is slow already, making it reallocate memory every time you add to a string makes it quite a bit slower. You could use blob[] = "dfsdf" and then do a implode() at the end. or even just use echo's and trap the output with the output buffer commands.
David (09/07/2006), Thanks for the advice. I already tried to optimize SQL queries but did not start optimizing PHP. In fact, as a beginner in PHP, I do not know the tricks to do it. I'll try to make a global pass soon. The purpose of next release is also to brings in a cache so that pages get generated only once in a while (dev has not begun yet). But I'd prefer to have high performance even when the cache is disabled.
David (10/07/2006), I made some search on PHP optimization techniques and found nearly nothing. However I found this which tends to show that using blob[] = "dfsdf"; then implode() is slower than X.blob .= "string"; Still searching for profiling/optimizing techniques... Any hints ?
Steve (12/07/2006) : This makes for some good reading on speeding up/optimizing php. Cache has the most effect and they seem to recommend pear cache or pear cache_lite. I haven't looked at these pear modules yet but I am sure they could be integrated into wiclear. The only thing I would say about having a cache is that it can be enabled/disabled and that you can choose the location of the folder to store the cache files (On the server I currently use the writeable area is outside of the web root).
David (13/07/06) : Yes, I know this howto, and adding a cache is the purpose of 0.11. However if one choose not to use the cache then I should try hard to make Wiclear as fast as possible. However I won't do it at all cost. Namely, I won't sacrify readibility against speed. In my mind, maintenance is very important, so optimizations must be done in a readable way.
Daniel (13/07/06) : Ok, I'm surprised, I took that code and tried tons of variations on string length i.e. not using a single character and repitions and added a few different methods. The array method was considerably slower than appending, but using the output buffers was nearly twice as fast in almost every case. With a small number of appends ( < 6), it doesn't really matter how long the strings are, the append method was 10 - 20% faster. But in every other case (and I tried MANY) the output buffers beat them all. Like this:
ob_start(); echo "strings"; echo "more strings"; $result = ob_get_contents(); ob_end_clean();
And you can start them recursively without problems. I made two functions for clarity StartCapture() and EndCapture() that execute those lines of code.
David (14/07/06) : Yes, the article I gave the reference above said the same thing : output buffers are way more efficient than string appending or the array method. I like it too because it is still readable and in my mind it is not a short term optimisation. I mean sometime in a particular version of a compiler/interpreter you find a hack that gives you some speed increase, and with next version of compiler/interpreter, it has been rendered useless by a fix/enhancement. In the meantime you have changed your code and often it is far less readable/understandable for nothing ! Output buffers seems like a very good answer : both readable and still a long term optimization. I'll try to make a global pass with them before going on with caching. Thanks !
David (24/07/06) : I tried to play with output buffers inside user template functions, but in the end it did nothing performance wise. I made tests only when viewing pages, not when editing them for example. The reason for this is I do not pass a lot of time appending strings outside form generation (which are used when editing). So output buffers had little effect. I tried various optimizations without performance gain. In the end, I totally stopped trying to do this and started implemented a cache (based on PEAR's Cache_Lite). And it is now in production here. Hope it will be good.
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)
Steve (23/06/06) : I've had a look and section editing and toc don't appear to be working, I can make the section editing work by changeing an if (if ($wikiRenderer->config->doEditBySection)) statement in WiclearWikiRenderer.conf.php to 'true', by the same didn't work for toc. I also found
var $doGenerateToc = false; var $doEditBySection = false;
and set them to true, but that didn't do anything.
David (23/06/06) : Those variables are 'configured' from preferences in prepend.inc.php. Have a look to it and to your config.ini file. This is strange. Is it a stock 0.10 version or has it been modified ?
Steve (23/06/06) : My sincer apologies, the options where right under my nose in the admin panel. All works great. Could I make a sugestion, the contents list might be better suited to an ordered/unordered list, rather than as heading elements. This would keep the symantec structure of the page. I would be happy to code this for you should you want.
David (22/06/06) 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 ?
Steve (23/06/06) I have been working on something my boss mentioned and that lead on to other bits (really been bored at work and thought I would experiment), I'll put these in the contribution section and if you like any of it feel free to use it or maybe you would have idea of how to better do it, plugins maybe. steve ideas
David (22/06/06) 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.
Steve 11/07/06 Hi David. I've been a way on some seminar/conferences for work, but before I left I started work on a new diff comparison for wiclear. I haven't written it myself, but I have nearly adapted it for use with wiclear and designed a couple of different rendering/templates for the output. I shall finish it a bit later this evening and upload it as a page attachment in the steve ideas page.
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.
David(09/07/06) : done
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.
Steve (23/06/06) : Sorry didn't notice those,It was only some css I already had for my custom template, so no worries. The "Source" link could be good for copying bits of pages around quickly!
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.
David(09/07/06) : done
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.
David(09/07/06) : done
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.
David(09/07/06) : done
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...
Steve (23/06/06) Thats excellent, so much more flexible, cheers.
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>";
David(09/07/06) : done
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.
Bug du bouton "force line break"
Marc(21/06/06): Mmmh, comme je ne pense pas pouvoir être assez comprehensible en anglais, je m'explique en francais. Voila, il y a un petit bug dans la barre d'édition du contenu. L'utilisation du bouton "force line break" insére 2, et non pas 3 symboles %.
David(27/6/06): Effectivement. Je jetterai un oeil, ça ne doit pas être méchant à fixer ! Sinon, tu peux aussi cliquer sur le petit drapeau français en haut de la page, et tu tomberas sur la page de rapport de bug en français !
David(09/07/06) : done
W3C Validation of edit page form
Steve (28/06/06) : Hello, Hope all is well. I validated the edit form page with w3c validator to check some of my alterations and if failed on two points.
Warning Line 608 column 510: reference to non-existent ID "fminor_major". ...ecked="checked" tabindex="9" /><label for="fminor_major">Major change</label
and (this one only on your site. I added the id on my version, as mentioned above in bit about textareas, ids and simple toolbar)
Warning Line 608 column 295: reference to non-existent ID "fcommit_msg". ... class="field" id="commit_msg"><label for="fcommit_msg">Commit message</label
To fix I added the ability to specify an id to the addCheckBox function in form.class.php
/** * brief add a checkbox * * param name name of control * param checked is checkbox initially checked * param id of checkbox */ function addCheckBox($name, $checked = false, $id = "") { $ext = ""; if ($checked) { $ext = 'checked="checked" '; } $this->addInputRaw("checkbox", $name, "", "", $id, $ext, ""); }
Then add the id to checkbox in the contentEdit() (content.php)
$form->addCheckbox("minor_major", $minor_major == major_value, "fminor_major"); // added ', "fminor_major" '
This then also means you can click the mouse on the label text to tick the checkbox.
David(09/07/06) : done
Other problem raised by W3C Validator
Steve (28/06/06) : The Validator also throw a couple of other errors on your edit page, it seems to be some of the title's in the parent node select box.
Error Line 383 column 1011: non SGML character number 144. ...chments</option><option value="92">��Ỡmục thứ nhì</opti
I won't list all three as you can validate the page yourself and get the full description, plus I don't think they cut and paste very well!
David(09/07/06) : done
Confirmation of delete page/node history
Steve (28/06/06) : I am just going to add some code to get the user to confirm they want to delete the history in the steve ideas page. It's basically the same code as for the delete page, I thought it may say you time.
David(09/07/06) : done