Revision [1766]

This is an old revision of WikkaBugs made by JavaWoman on 2004-10-09 06:54:27.

 

Bugs/Issues discovered in Wikka!


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


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




Interwiki is broken

Interwiki links are broken if they are not CamelCased, like WikiPedia:Albert_Einstein will not work, but WikiPedia:CamelCase would. Wikipedia heavily relays on FreeLinks, which converts "Albert Einstein" to "Albert_Einstein". --DavidCollantes

There are in fact two causes for this:
  1. the evaluation order in Link() is wrong: it evaluates a WikiName before it evaluates a possible Interwiki link; since a WikiName is a substring of an an Interwiki link, the latter should be matched first;
  1. the RE used to match an Interwiki assumes only WikiNames after the colon; since an Interwiki link actually appends a string to a pre-defined part of a URL, we should allow anything that is allowed in a URL - not just WikiNames.
An extra complication is that the REs used are occuring in three different places - a nice case for using a central "repository" for REs in a set of define() statements rather than having them scattered all over the code!

Without addressing the last issue of the scattered REs, the following changes will fix this problem:
1. wikka.php -- Link() method - change near the start as follows:
<?php
        // is this an interwiki link?
        if (preg_match("/^([A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+)[:](\S*)$/", $tag, $matches))
        {
            $url = $this->GetInterWikiUrl($matches[1], $matches[2]);
        }
        // is this a wiki link?
        elseif (preg_match("/^[A-Za-z0-9]+$/", $tag))
        {
            if ($_SESSION["linktracking"] && $track) $this->TrackLinkTo($tag);
            $linkedPage = $this->LoadPage($tag);
            // return ($linkedPage ? "<a href=\"".$this->Href($method, $linkedPage['tag'])."\">".$text."</a>" : "<span class=\"missingpage\">".$text."</span><a href=\"".$this->Href("edit", $tag)."\" title=\"Create this page\">?</a>");
            return ($linkedPage ? "<a href=\"".$this->Href($method, $linkedPage['tag'])."\" title=\"$title\">".$text."</a>" : "<a href=\"".$this->Href("edit", $tag)."\" title=\"Create this page\"><span class=\"missingpage\">".$text."</span></a>");
        }
        elseif (preg_match("/^(http|https|ftp):\/\/([^\\s\"<>]+)$/", $tag))
        {
            $url = $tag; // this is a vaild external URL
        }
        // is this a full link? ie, does it contain alpha-numeric characters?
?>

2. formatters/wakka.php
2.1 // interwiki links! section - change line that does the matching as follows:
<?php
        else if (preg_match("/^[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]\S*$/s", $thing))

?>

2.2 preg_replace_callback() - change this (near the end):
<?php
    "\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]([A-Z,a-z,0-9,ÄÖÜ,ßäöü]*)\b|".
?>

into this:
<?php
    "\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]\S*\b|".
?>

Explanation: in general (apart from the changed evaluation order - correct in wakka.php but incorrect in wikka.php) we simply allow any character that is not whitespace: somewhat lenient but the allowable characters in a URL is quite a large set and partially dependent on in which part of the URL they occur; allowing simply non-whitespace is a reasonable shortcut, IMO

Note that fix 1. will already work for forced Interwiki links; the two parts of fix 2. are needed as well (both together) to make it work for Interwiki links simply inserted as text (as in David's example).
-- JavaWoman


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