Revision [2550]

This is an old revision of WikkaBugs made by JsnX on 2004-11-27 17:25:12.

 

Bugs/Issues discovered in Wikka!


Related pages:
  • for issues related to Wikka layout refer to: WikkaCSS
 






Please post recently discovered bugs on the top of this page.

List parsing bug?

Have a look at the source of WikkaDevelopment, you will see that tabs and unordered lists for some reasons are not correctly parsed (actually after one edit, tabs were added at the beginning of each line). I'll try to figure out why this happens...
-- DarTar

Page creation bug

Wikinames with non-alpha characters are accepted when creating a page (see this page), but are not correctly parsed as links: 12Action! and create inconsistencies in automatically generated pages, like RecentChanges.
Page tags should be checked before page creation.
-- DarTar

I just hacked a little something together to fix this. Try it out now. -- JsnX 26 Nov 2004
Fine. I'd just add a short message saying what are 'valid' page names. -- DarTar

MySQL issue


MySQL 5+ isn't supported as it requires PHP to use the mysqli extension instead of plain old mysql. I hoped there would be a single file to change this, but there seems to be no database abstraction in this project at all.

-- DavidCarrington

I do not have access to a MySQL 5 server for testing. And judging by the feedback that I see here on Wikka, most other Wikka admins are using older versions of MySQL. However, I do like progress, so I looked at the documentation for the mysqli extension. I don't see any major issue here. It looks like the function calls are the same, they just have a different name. Instead of calling mysql_connect, you call mysqli_connect. Instead of calling mysql_query, you call mysqli_query. So on and so forth.

It seems that we would just have to do a simple version check and call "mysql" functions for older versions, and "mysqli" functions for newer versions.

Please correct me if I'm missing something. -- JsnX 26 Nov 2004


Login Problem

I have several users that have trouble staying logged in using ie 6.0.XX.

I have no problems with IE 6.0.xx. Perhaps they don't accept cookies? The login is stored in (one?) cookie. So if you don't allow them, the status as logged in simply wouldn't be stored.
--NilsLindenberg
PS: I tried it with the IE. If you block cookies, you can't login.

More info: I checked with two of the users, both have their "Privacy" set to "Medium" (tools/internet options). This seeme to be a default setting of ie, and perhaps the Wikka Cookies should be able to work with that.
I worked around the problem by setting their Ie to allow all cookies from my wiki host... Not ideal, i know..

I'm using a freshly installed copy of Windows XP SP2 with Privacy set to medium--and all other settings are at the defaults--and it works. There must be another cause in your environment beyond having Privacy set to medium. -- JsnX


User search - should be case-sensitive
I was going through user pages, and looked at the homepage by user DaN; clicking on the name does the TextSearch thing: http://wikka.jsnx.com/TextSearch?phrase=DaN which brings up a surprising number of pages, none of which have actually been touched by DaN, it seems (at least non of the ones I checked). Using the browser to search in some of the listed pages (and their revision history) I found hits on words like "dangerous" - and nothing else. This way, the user search feature isn't all that useful, I'm afraid. A whole-word search may be difficult, but could we at least make it (optionally) case-sensitive so that a search for a user name or page name doesn't bring up a host of spurious results?

(That homepage looks at least marginally like spam to me - has DaN done anything else but post a link to an obviously commercial site? Just wondering...)
-- JavaWoman


Problem with "History"??
I ran across this on another wikka implementation....
http://elvito.sv-city.de/wikka.php?wakka=RecentChanges
if you look at Sun, 22 Aug 2004 the second item down says
[ (20:46 CEST∞) [history∞] - TextSearch?phrase=ElVitoWakkaWiki∞ ⇒ ppp-82-135-6-82.mnet-online.de ] which seems kinda wrong. -- Mike (aka GmBowen)

Unicode rendering buglet
See my latest edit in the Sandbox labeled [Unicode bug?] - someone was trying to create a link in Unicode, and I tried a bit more: Unicode characters (Chinese, Korean) are rendered just fine when they occur in plain text; but in a forced link when they occur in the link text they are escaped.
(Just in case the (Korean) example disappears:
Hmmm - SandBox 안되려나 - Unicode rendered in plain text but not for link text (안되려나)? Looks like a bug to me.)
Same problem in comments. (See also SandBox.)
--JavaWoman

Email Addresses
Found several issues with how email addresses are validated / accepted / used; outlined on WikkaAndEmail - and I'm working on solutions. (Email is complicated and there's a whole bunch of standards (RFCs) involved.)

First part of the solutions now in WikkaEmailToolkit; while the toolkit is still incomplete, what's there now can be used as presented there (no dependencies on later components).
-- JavaWoman


I'm being picky here (again!). I've noticed that the double-click edit event is used on the BODY tag. One issue I've experienced is that while entering a comment, I couldn't double-click a word (to highlight and replace it) without triggering the edit screen. My suggestion is to put it on the DIV class="page" tag. -- Sam


Bugs I've found:



Thanks - Sam

I'm actually not sure if this is a Wikka Bug or not, but I'll put it out there. If the Character Set encoding in Internet Explorer 6 is set to Unicode (UTF-8) the Wikiedit Toolbar does not display and a JavaScript Runtime Error occurs on the page. (You have to doubleclick the little yellow exclamation point icon in the bottom left corner to see the actual error message.) If you right click in the page, select encoding, and change the encoding to Western European (ISO), then the Wikiedit Toolbar appears. If I configure the Default CharSet to be iso-8859-1 in my httpd.conf file, then everything works fine. If I set the default charset to be UTF-8, then I get the error. Is this normal behavior with UTF-8 encoding? -- RichardTerry


  if (event.altKey && !event.ctrlKey) Key=Key+4096;
  if ((event.ctrlKey) && !event.altKey) Key=Key+2048;



Problem withTextSearch

I did a re-install and the problem seems to have been corrected. Hmm.

--JamesMcl


CategoryDevelopment
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki