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.
I setup Wiclear using MySql 5.0 and the history page failed to display full history (just listed current page). I tracked it down to the SQL query in wiki.class.php
(...snip)
function getHistory($content_id)
{
$content_id = $this->con->escapeString($content_id);
$query = <<<SQL
SELECT wc_history.id, wc_history.title, wc_history.alternate_title, wc_history.content, wc_history.commit_msg, wc_history.minor_major, wc_history.ip, wc_history.timestamp,
wc_lang.id, wc_lang.code, wc_lang.description, wc_lang.flag,
wc_content_hierarchy.parent_content_fk,
wc_content_lang.related_content_fk,
wc_user.id, wc_user.login, wc_user.firstname, wc_user.lastname, wc_user.email
FROM wc_history
JOIN wc_content on wc_content.id=wc_history.content_fk
JOIN wc_lang on wc_lang.id=wc_content.lang_fk
JOIN wc_user on wc_user.id=wc_history.user_fk
JOIN wc_content_hierarchy on wc_content_hierarchy.content_fk=wc_content_lang.related_content_fk
JOIN wc_content_lang on wc_content_lang.content_fk=wc_history.content_fk
WHERE wc_history.content_fk='$content_id'
ORDER BY wc_history.timestamp DESC;
SQL;
(snip...)
This sql returned the error
Unknown column 'wc_content_lang.related_content_fk' in 'on clause'
To fix it I swap these two lines
JOIN wc_content_hierarchy on wc_content_hierarchy.content_fk=wc_content_lang.related_content_fk
JOIN wc_content_lang on wc_content_lang.content_fk=wc_history.content_fk
To
JOIN wc_content_lang on wc_content_lang.content_fk=wc_history.content_fk JOIN wc_content_hierarchy on wc_content_hierarchy.content_fk=wc_content_lang.related_content_fk
MySql 5 now seems to join tables in order and you cannot reference a table that has not yet be joined.
The same needs to be done to
- function getHistoryVersion($history_id)
- function getHistoryByDate($node_id, $timestamp)
David : wow, I must say I'm definitly impressed ! That's the first time I get a bug report that precise. Thanks very much, if everybody could do the same...
Anyway, this already has been fixed on the dev version. There is also the comment sql query for comment feed and another query I don't remember which happened to have the same problem. I did not know this was linked to MySql 5 though. I discovered it because here on free.fr I happened to choke on the same bug : they must have upgraded to MySql 5...
Version 0.9.tgz download
- the admin panel says 0.9-beta1
- the file "VERSION" as states 0.9-beta1
This also seems to be in the download for 0.9-beta3.tgz
David : Yep, error from mine, I'll fix it in next 0.10 release
Excellent program by the way. It is fast and easy to use, it works the way I expect it too (and I've used a few that don't). Thanks for all your time and effort.
David : Thanks very much, I mean it. I seldom receive thanks and it's always nive to have some.
Steve : Well you deserve it, I have tried loads of wikis and this one is more what we need than mediawiki and phpwiki. It's easy to keep the site structured with the parent node/sub node feature. The template system is nice to use and easy to customize. I've spent the day intergrating Wiclear in to my departments intranet, I've even managed to tie Wiclear to our authentication DB/System, so the user is automatically loged into the wiki if allreay logged into our intranet db. So thank you, I think my department is going to find your software very useful for mantaining documentation, etc. Got another bug for you, but you may have already caught it.
The sql script to create the contents table (contents.sql), specifies the contents colomn as "blob" rather than "text", which causes your search feature to only search page title and not the contents.
Currently
CREATE TABLE wc_content ( id int(6) NOT NULL auto_increment, title char(100) NOT NULL, alternate_title char(100), content blob, //this bit minor_major int(1), commit_msg varchar(200), timestamp int(8), ip char(15), creation_time int(8),
user_fk int(6), lang_fk int(6),
PRIMARY KEY (id), INDEX (title) );
should be
CREATE TABLE wc_content ( id int(6) NOT NULL auto_increment, title char(100) NOT NULL, alternate_title char(100), content text, //this bit minor_major int(1), commit_msg varchar(200), timestamp int(8), ip char(15), creation_time int(8),
user_fk int(6), lang_fk int(6),
PRIMARY KEY (id), INDEX (title) );
David : you have sharped eyes !
David : now another thing that is bugging me : searching do works for me : not only in title but also in content. I had a slovene user who reported a similar problem with UTF-8 characters not being matched in the content. Do you have an idea about what would be the best solution with MySql/UTF-8 ?
Steve: I have changed the BLOB field in history, content and comment tables to LONGTEXT. There seems to have been no problems doing this, as the pages I had added to test wiclear still worked perfectly. I would say it is safe to do, I have read a couple of mysql documents that talked about converting binary to text or varchar.
Steve: The search works perfectly for me once BLOBs are turned into LONGTEXTs.
Steve: Is Wiclear supposed to use UTF-8 encoding by default, mine installed using latin-1. I went through the tables and converted them all to UTF-8 (And the individual columns/fields, as then hold their on setting and had stayed latin1) and my content is still ok. If you want Wiclear install the tables using UTF-8 then you sql script need - ENGINE=MyISAM DEFAULT CHARSET=utf8; add to the create statement. (this sql statement was create with MySql Administrator's backup tool)
CREATE TABLE `wc_content` ( `id` int(6) NOT NULL auto_increment, `title` char(100) NOT NULL, `alternate_title` char(100) default NULL, `content` longtext, `minor_major` int(1) default NULL, `commit_msg` varchar(200) default NULL, `timestamp` int(8) default NULL, `ip` char(15) default NULL, `creation_time` int(8) default NULL, `user_fk` int(6) default NULL, `lang_fk` int(6) default NULL, PRIMARY KEY (`id`), KEY `title` (`title`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
Steve: UTF-8 is not something I have done much work with, but the xhtml page needs to set it's encoding to UTf-8 i.e. <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> and in header (as you have done) . This should get the browser to send form data in UTF-8 format and display data in that format. Could the slovene user have had a mismatch between db charset and what charset the browser sent the data in. i.e. (DB UTF-8 and Form data non-UTF-8) or (DB non-UTF-8 and Form data UTF-8)
Steve: I just been having a closer look at your code, I didn't realize you had an ini option to set the charset encoding for the html page. I set wc_charset = utf-8 and am going to have an experiment now that the database will hold utf-8. I'll let you know if I have problems the the search.
Steve: I entered some test data i.e Äê??? and I can search for any of these characters and I get the correct search results. I'm not sure that this is a good test, but it worked in Firefox 1.5 and IE 7. Maybe the other user didn't have the database in UTF-8 (I had to change charset on each field/colomn).
Steve: I went and had a quick look on the web and found a MySQL article on UTF-8 and PHP. http://dev.mysql.com/tech-resources/articles/4.1/unicode.html This talks about checking the encoding of text and then converting it UTF-8 if it's needed. This might be the solution you need, but you may have to force that Wiclear to use UTF-8 as it's storage encoding and no other.
Also, not sure if you know, MySQL has a "full text search" feature, which might be usefull. I used this in my last job to build an index of fault reports and allow bolean logic searching. Deffinetly one of MySqls better features. http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html
David : yes, but last time I looked I think I remember it was possible to use only with text field, so I cannot use it right now. And I don't know if that's standard SQL (I'd like to use other backends as well : Sqlite, Postgres)
Steve : Yes it only works with text, but then if you your not using blob for content (longtext) then this would search the core fields. It isn't standard sql, but you could check that the user is using MySql first and have alternative method for others. It might be something to add at a later date.
Steve : I hope some of this may be of use.
Now a feature request/idea, rather than a bug.
To get Wiclear to use a prefix on the session variables like it does with the database tables?
i.e. SESSION 'wiclear_user_id'
I have a few programs sharing the same session on our intranet (well one I've written and phpOpenTracker). The both use prefixes, so as not to accidentally overwrite each others variables. I've caught out by things like this before and thought it might be a good idea for Wiclear.
David : good idea, I'll try to add this also for cookies...
Once again thanks and hope you have a good weekend. Steve
David : thanks very much to you and a nice week end !
