Revision [1292]
This is an old revision of WikkaBugs made by SdfdsfaSdasd on 2004-09-18 10:54:43.
Bugs/Issues discovered in Wikka!
Bugs I've found:- ACLs bug: when you change the read access to "!*" (stop all), the only way to revert this back to "*" is:
- Give rights to a new user (so ACL for read access says "ban all, but allow access for TempUserName")
- Save ACL
- Edit ACL, deleting TempUserName and the exclamation mark
- Something dodgy has been done to this site's header.php. The code to extract document titles from the downloaded version is MUCH different from what you are showing here. Take a look at the document titles on HtmlAreaEditing and GmBowen. That's code in there! What's going on?
- There are two related bugs in the productionised code. WikiName and WikiPage need to be created to "complete" the group of default pages. If you can't be bothered to create them, register them in WantedPages by default please.
- I think defaulting to "Public" ownership would be more beneficial than Nobody. Nobody allows anyone to gain ACL rights to main pages if the proper setup steps are not taken. This is a major security issue and should have been addressed when the "Public" role was created.
- I mean, I can't even figure out how to get the file uploader running! Let alone figure out whether it's been implemented! I can see the files.php page, but where does it get executed?? Oops apparently, it's {{files}}, I'm an idiot! But let's see some documentation for this! Btw, the default uploads directory is not created in installation (is this a security precaution?).
All in all, this project suffers from poor source control...I believe one of the major bad ideas of wikiengine sites is that they use their own wiki to display their project. It's a wrong idea from the ground-up as it allows for inefficient code management.
Hope I was being fair, not harsh.
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
- There is a bug in the googleform action: the call to the obsolete tag() function must be replaced with GetPageTag() -- DarTar
- When I want to write { with my keyboard, the javascript is supposing I was typing Ctrl+Shift+4, so it encloses the actual line by ===. The same ennoying happens for ~, # and [. [DotMG]
- Can you give me some more detail on this one. I'm not sure what you mean or how to replicate the bug. -- JsnX 5/27/04
- Is anyone else seeing this? -- JsnX 5/29/04
- I have a french azerty keyboard, and to type {, I combine keys Alt Gr and 4. But when I try this inside the box, I have my line enclosed with ===, as I typed Ctrl + Shift + 4, and the character { doesn' t appear as expected! It's because of Javascript.[DotMG]
- I'm not encountering any problems with my swedish keyboard. Can use the full range of Alt Gr symbols: @£$?{[]}\. -- JockeAndersson 6/1/04
- Mod_rewrite : take a look at FaviconDotIco and RobotsDotTxt
Resolved bugs
2) The WantedPages page uses the linking_to query-string. The character preceding this should be a "?" if URL re-writing is enabled, but a "&" if not. For example, if I use the default wikka.php?wikka=WantedPages?linking_to=TestMe, this will attempt to create a new page. This bug may be already addressed at Mod032bModRewrite, but frankly, I can't understand it.
- the new tab conversion in the formatters/wakka.php replaces not only four successive space characters with a tab, but any whitespace which a tab itself used to be one. replace the metachar "\s" in the square brackets with a real space like this:
$text = preg_replace("/\n[ ]{4}/", "\n\t", $text);
then program listings with levels indented four and more times will be rendered correctly again.
- Yup. That's originally how I had it, but then mucked it up for some reason. Resolved in 1.1.4.1. Thanks for pointing it out. -- JsnX
- Homepage is not CSS valid -- Fixed.
- Mod_rewrite : I'm waiting for 1.1.4, but This is a bug I found at 1.1.0 : every Rewrite directive in each .htaccess file should be enclosed in <IfModule mod_rewrite.c>, </IfModule>; because if you just add IfModule in ./.htaccess, no image, no js, no css will be downloaded because the server will send an http 500 error. So, what you are saying is that the .htaccess file in the root directory is okay, but I need to add the Ifmodule conditional to the other .htaccess files in the css, image, and wikiedit2 directories as follows? ...
Yes! (You can try to disable mod_rewrite by commenting the corresponding LoadModule in httpd.conf)
<IfModule mod_rewrite.c> RewriteEngine off </IfModule>
Version Wikka Wakka Wiki 1.0.4:
- External links 'eat' the closing bracket: (see http://www.cnn.com) [MarkHissinkMuller]
bug in redesigned acl-handling?
am i wrong or does the $wakka->hasaccess routine (v. 1.1.3) only check the user-rights against the present page, regardless if the parameter $tag is set or not? i haven't had a closer look, but as i understood, the check against $this->acls[$privilege."_acl"] only returns the right value, if $tag == $this->tag and else should be passed over to the loadacl-function as wakka did. -- DreckFehler
- Fixed in 1.1.3.1 and above. -- JsnX
formatters don't care about diff-tags
none of the formatters which are triggered by the %%double-percent tag%% observes the tags that are inserted by the diff-engine, although the main-formatter wakka.php delegates all rendering to these formatters. an example is shown here:http://wikka.jsnx.com/FeedbackAction/diff?a=828&b=792
just search for "pound" or "++" on that page.
in most cases this issue can be solved by a simple str_replace. an exception is the php-highlighter. see the link below for a solution.
but fixing that problem rises another! i'm unhappy with the "++" tag used by the diff-engine to mark deletions. the double-plus is also the increment operator of php (and other languages) and can't be distiguished from the diff-tags. this problem is addressed in the following sample code too:
http://mindwiki.de/wikka_bug_-_formatters_to_care_about_diff-engine/diff?a=387&b=384
that page might be an example what this bugfix is good for, but it also shows up the limits. naturally the sample-code contains those diff-tags which it is dealing with. that obviously screws up the diff-engine again. so take care not only to paste-n-copy the code snippets from the link above ;)
- Fixed in 1.1.3.3 and above. -- JsnX
CategoryDevelopment