WikkaBugs:Wikka

Bugs/Issues discovered in Wikka!

How do I report a bug?

Wikka has a dedicated issue tracker.

If you have something to report:
First check if your issue is already being discussed on this page:

If so: check if it has a link to a ticket:
- If so: follow that link and add your comment there
- If not: add your comment to the issue on this page
If not: please use the issue tracker to report your new bug or issue. Again, search first to make sure your issue has not been reported yet.

Read this first

workarounds for unusual problems and temporary fixes for known bugs are listed at WikkaWorkarounds

general help can be found on the Wikka documentation page

Bugs reported on the tracker Ticket:13

Missing language-support in the code formatter

1.1.6.0beta4: Simplified Chinese (or Unicode relative) in WikiEdit :

Indenting not working properly in handlers/page/edit.php

Ticket:85

Accept-Encoding: gzip;q=0, deflate

Ticket:88

Error on ./handlers/page/referrers_sites

Ticket:1

Purging should not remove the whole history of a page

Ticket:93

RSS feed action hangs or crashes browser if feed does not exist

Ticket:95

Install Note on Basic URL and CSS

Ticket:97

Purging of pages not always happening

Ticket:100

Ticket:783

Bugs still to be checked/migrated i just tested it on IE,firefox,opera;but only on IE it sometimes got blank page,nothing displaed,no code on it(so i think it's not coz the insert ads host,and my host don't gave ads).this not happened always,when you click the links,go to the new page,got a blank,then refresh it,it displayed.no this problem on firefox or opera.

but which is interesting,on your official site of Wikka,there is no this problem with IE blank.is there something wrong with the File permission?(exhausted with it),but when refresh the blank page,it displayed.

Details like the versions of your IE, your webserver and Mysql (and perhaps a link to the page) would be helpfull! NilsLindenberg

remote (or local) won't load Wikka

I just installed Wikka and it works fine on the localhost.
But if I want to access it from another machine, being it on the LAN or internet, I got an error message saying "connection refused when attempting to contact localhost."
my config setting is
"base_url" => "http://localhost/wikka/wikka.php?wakka=",
"rewrite_mode" => "0",
If I change the localhost to mydomain.com, I can access it from internet, but I can't load it on my localhost.

It's one or the other. Is there anything I did wrong?

Hi, this is a problem that depends on your server configuration and how it resolves virtual hosts. It is in no way a Wikka bug. You should contact your network administrator to address this issue -- DarTar

I don't think so. I tried MediaWiki and it works fine. I can serve my web pages and that's fine. My server is behind a cable modem and a router. All ports are forwarded correctly. But I really think that the "base_url" syntex caused this problem.

Since you say you can access your site from the Internet if you use "base_url" => "http://mydomain.com/wikka/wikka.php?wakka=", you could simply edit your hosts file on your local machine and map mydomain.com to 1.0.0.127 - that way you can access the site on your local machine the same way as from the Internet. For accessing it from other machines on your LAN you may need to add a similar mapping (to the hosting machine's local IP address) to access it from there. -- JavaWoman

The following is a solution copied from comments of WikkaInstallation that I think resolves this issue (have not tested it though) --GiorgosKontopoulos 16/03/2006

The following solution will allow Wikka to work for a site that can be reached by multiple domain names (for example, a server that has one address when accessed via an intranet and a different address when accessed from the Internet):
Edit wikka.php.

//After
$wakkaConfig = array_merge($wakkaDefaultConfig, $wakkaConfig);)
//add the following line:
$wakkaConfig[base_url] = "http://".$_SERVER["SERVER_NAME"].($_SERVER["SERVER_PORT"] != 80 ? ":".$_SERVER["SERVER_PORT"] : "").$wakkaConfig[base_url];

Then, edit wikka.config.php and set base_url to contain just the path of your Wikki instead of the full URL

"base_url" = "/wikka/",

I may be reinventing the wheel here. It would be good if Wikka actually had a config option to autodetect the domain or require it in base_url. --Vincent -- 65.242.114.226 (2006-02-06 18:52:54)

Wikka and WebDAV

I've found that the .htaccess file (i think) prevents me from accessing a wikka folder using MacOS X's in built webdav client. I imagine that if the Rewrite stuff was less catch-all it might not have this effect, letting me edit wikka templates with ease rather than the terminal... thanks tom

Now.. and I don't get this... THIS has fixed it.. and it doesn't even seem to make sense (my install is in a folder called Wikka)... but when I try and change it ... it stops working again... My .htaccess file looks like this...

RewriteEngine on
# RewriteCond %{REQUEST_FILENAME} -d
# RewriteRule ^(.*/[^\./]*[^/])$ $1/

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.+) - [PT,L]
RewriteCond %{REQUEST_URI} !/(Wikka/css|/Wikka/files|actions|dav|handlers|pages)

RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L]

..... I don't get this... but hey, if it works...

Wrong Links

I get Links like
http://localhost/~ckl/Wikka/wikkaHomePage
http://localhost/~ckl/Wikka/wikkaCategoryCategory
and so on, instead of
http://localhost/~ckl/Wikka/wikka/HomePage
http://localhost/~ckl/Wikka/wikka/CategoryCategory

Open wikka.config.php and check the value for base_url: it should be http://localhost/~ckl/Wikka/wikka/. BTW, you may also want to read ModrewriteInSubdirectoryWorkaround. Hope this helps -- DarTar

Thank you for the help.

If I use http://localhost/~ckl/Wikka/wikka/ the links are correct,

but the css file is not found and I get messages like Unknown method "page/HomePage.php". ModRewrite is off.

If I use http://localhost/~ckl/Wikka/wikka the links are not correct and if I click HomePage I get

Not Found The requested URL /home/ckl/public_html/Wikka/wikka.php was not found on this server.

Logout fails silently or takes long time on SourceForge hosted site

Here are the symptoms :
When you click on the logout button, it returns to UserSettings page but does nothing.
You can browse other pages, it keeps saying 'You are XXXX' even after logging out.
IMHO, I think it may be a problem with the SourceForge hosting space as I've tried logout/login on different Wikka sites already hosted by SourceForge -> same issue.
On my local LAMP, it works fine so I suggest there are some PHP, MOD_PHP, APACHE issues on SourceForge.
--PhilippeVincent 10 Aug 2005

it may not be a bug since i noticed there are some problems with mysql on sourceforge.

when a query takes too long, the server just cut the connection.

So, if the logout process takes a bit too long according to the short mysql latency, it fails over...silently.

--PhilippeVincent

.htaccess settings yields consistent error 403 on Apache

Original issue: running Apache 2.0.54, with the presence of .htaccess file I kept getting error 403. Originally I moved .htaccess and set the base page in the conf to using the long url. After looking around I realized that the fix, in some instances (see requirements below) is to set the option FollowSymLinks to on in your .htaccess file.

Problem: your Apache configuration files don't have FollowSymLinks on

Solution: use the .htaccess below IFF (if, and only if) you have the following options set in the configuration file for the directory: AllowOverride Options or AllowOverride All, because you're going to need to override the settings in your local .htaccess file.

### STOP REFERRER SPAM
SetEnvIfNoCase Referer ".*(adultsite|picturesplace|learnthebiz|pi-o|erotica|ghettoinc|port5|bulk-email|camgirls|paris-hilton|modelos|kredit|handyflirt24|versicherung|wwww|erotower|krank|x-1000|flirtnet|blowjob|agedwife|in-the-vip|boysfirsttime|milf|captain-stabbin|tranny|Kontakt|erotik|fetish|frauen|hardcore|fick|krankenversicherung|jinnan-cross|8thstreet|xxx|XXX|ficken|fuck).*" BadReferrer

order deny,allow
deny from env=BadReferrer

<IfModule mod_rewrite.c>
Options +FollowSymLinks
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.*/[^\./]*[^/])$ $1/
RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L]
</IfModule>

The + is optional, but I chose to put it in since I'm overriding default settings.
--KoG

I'm also get the same error 403. I tried KoG workaround but it gives error 500 (Internal Server Error). The only solution that works with me to delete .htaccess file. Is this implies security risks? I don't know till now. --Ikhnaton2

There is no security risk with removing .htaccess. In fact, only the Apache web server can do anything with it but Wikka can function just fine running on other webservers (even IIS :)). Also, there are hosting plans where Apache is used but the use of .htaccess is not allowed - which might result in it either being ignored, or possibly a 403 error. So, while a .htaccess file (with Apache) may make life with Wikka easier (some spam defense, and pretty URLs) it's safe to remove it.
That said, if adding Options +FollowSymLinks changes the 403 error into a 500 error, you might want to check the ServerErrorWorkaround page (and look at ModrewriteInSubdirectoryWorkaround as well). --JavaWoman

IIS7 is supposed to support something akin to htaccess. But yes, some apache installations don't allow for overriding either. I those cases you'll need to speak with your administrator, or find a different/better host. Of course, Wikka works fine without mod_rewrite. As for the other portion of .htaccess, it's for stopping spambots. Of course, if you set your Wikka ACLs so only registered users can post/comment (as necessary and appropriate to your purpose), you should be ok. If you find yourself hammered by Wiki-attacking bots, adjust your security as needed (or talk to JW - she's been dealing with spammers I think) --KoG

The .htaccess should probably be removed or renamed in the distribution. Once upgrading to 1.1.6.2 i wasn't able to use wikka untill i removed the htaccess file that it comes with.-BrendonB

Can't confirm that, as the 1.1.6.2Alpha, 1.1.6.2Beta, and the 1.1.6.2-released all worked without the .htaccess file being an issue on my system. --WazoO 11Jul06

Messages delayed

copied from #wikka
- well, some slight weirdness where i seem to get logged out without asking to
- and some other weirdness where i make a change, such as claiming ownership of a page, but then get a javascript notification several pages later
- cookie related problem? (firefox 1.0.1 on OSX).

Email forgotten password action

I tried with 2 different emails on this site (jsnx.com) to have a temporary password sent to me ('Forgot password?' etc.), and I never received anything. I have the same problem with other wikkas on several servers. Am I crazy, or does this action actually send something which... nobody ever receives? :-( --YanB

You are crazy. I just tested it... and it worked. *shrug* Does your email server do some sort of spam filtering?? -- JsnX

I must be crazy then! All the mail servers I use have some sort of spam filtering (who doesn't?), but this kind of 'reminder email' has always gone through these filters. I checked my spam box too. I tried with 2 different emails running on 2 different systems (IOW, I registered with 2 different emails)... And I never received anything with either one. Any idea? --YanB

JsnX, DarTar must suffer the same illness, then. I tried to retrieve my password, both as DarTar (with admin privs) and DarTar2 (ordinary user). They use different email addresses, none of them received anything from this server. Maybe a problem with the upgrade of this site to version n/a? Or a new security restriction on PHP mail() at JsnX's hoster ? BTW we need to modify the current password retrieval action: redirecting the user to HomePage after submitting his username makes no sense. We need to display a confirmation message or an error message, after the server has tried to send an email. -- DarTar

I just tested it - one account had an email addres that I'd forgotten was somehow filtered (though server logs show the mail did arrive on the server); email for the other account arrived. And after I changed that filtered email address for the other account, an new attempt got an email for that as well. Doesn't look lik a problem at this server or with 1.1.6.0 to me. --JavaWoman

DarTar, I just fiddled with the action and had it send emails to the DarTar and DarTar2 email addresses. Did the emails arrive? -- JsnX

JsnX, yep, I just received both -- DarTar

YanB the madman strikes again! After having seen the fix below I tried the action using four different emails, and still haven't received anything (it's been 2 hours). --YanB

Dear Mr. Madman, please try it again. I actually had made a couple of changes when I tested above with DarTar's account. I picked the change that I thought seemed the most reasonable unreasonable fix. Guess I was wrong. I restored the second change. So let's try again. -- JsnX

Negative... Tried with 2 different emails again, still nothing. (If only this was a joke.) --YanB

JsnX, I tried again to retrieve my password from one of my non-admin clones (like DarTar2) and I still receive no email -- DarTar

Not confirmed. On Alan I went to the site; I have my second non-admin account here as IamBack, which automatically logged me in via the cookie. I logged out, removed the cookie, and closed the browser. Opened the browser again and went to the site (not automatically logged in this time) and requested the "temporary" password. The email arrived just fine. I suspect the problem is actually with email servers rejecting some (incoming) mail as spam, possibly silently, i.e. without a bounce, so that the sending mail server won't know about it either. --JavaWoman

Using compression

Moved here from a comment so it won't get "lost". --JavaWoman
Wikka doesn't work with zlib.output.compression = On, it would be nice if it did.
-- 81-178-214-34.dsl.pipex.com (2005-01-06 22:31:13)

PHP5 + GESHI

Using PHP5 with the 1.1.6.0 release and the included GeSHI doesn't work. Once I updated GeSHI to the latest version, everything worked fine. --BrendonB

Please define "doesn't work" and give some details what system you're running with; it works just fine for me with Wiikka 1.1.6.0 out of the box running under Apache 2.0 + PHP5. (Good to hear teh latest version works, too, though. :)) --JavaWoman

Wiki Edit causes lockup

The new version of wikiedit here causes a lockup if I use either ctrl-B or click on the B link after highlighting text. I can go to earlier versions of wikka on my servers and it works fine. Back to wikka and it causes a lockup (no asterisks are inserted, no other formatting works either, so I have to close the window...which generates an MS window crash notification popup). I'm running XPPro with current updates for both XP & IE. -- GmBowen

$_REQUEST problem

If this does not fit in this bug section as such, my apologies... I'd like to hear some comments on this though..

I initially noticed this after having a problem with the {{files}} action. When trying to download a (previously succesfully uploaded) I received this result: Unknown method "page/files.xml?action=download.php"

Digging through the code and printing out some variables I noticed the $_REQUEST (and $_GET) variable still contained part of the query string. See the example code below. I inserted a quick workaround in wikka.php but I'm interested in figuring out how and where this is caused.

My setup:

Apache/1.3.28

php (module) 4.3.7

wikka 1.1.5.3

url: /wakka/wikka.php/FileActionExample/files.xml?action=download&file;=file.txt

<?php

print_r($_REQUEST);

/* print_r result
Array
(
[wakka] => FileActionExample/files.xml?action=download
[file] => file.txt
)
*/

//work-around $_REQUEST problem
if( preg_match( "/(^[^?]*?)\?([^=]*?)=(.*)/" ,$_REQUEST['wakka'],$matches) ){
list(,$_REQUEST['wakka'],,$_REQUEST[$matches[2]]) = $matches;
list(,$_GET['wakka'],,$_GET[$matches[2]]) = $matches;
unset($matches);
}

print_r($_REQUEST);

/*
print_r result after work-around
Array
(
[wakka] => FileActionExample/files.xml
[file] => file.txt
[action] => download
)
*/

?>

thanks, JoshJohn

Floating off-wiki link image

This problem has been cropping up off and on in wikka for me recently (only at this site as far as I can tell...so beta code maybe??). Anyways, I noticed it today on the BannerMaker page. The follow three screen captures were done after multiple reloads of the page (the images didn't move with every reload). The weird part to me is that the "spacing" between them stays the same, but the images move up and down the screen.

The screenshots no longer seem to exist --JavaWoman

http://gmbowen.educ.unb.ca/wikitest/bug.jpg http://gmbowen.educ.unb.ca/wikitest/bug2.jpg http://gmbowen.educ.unb.ca/wikitest/bug3.jpg

I've never seen anything like it and can't reproduce your screenshots - can you tell us exactly which browser/version/OS (all three!) you are using? To me it feels more like a browser problem than a Wikka problem... Also: given the spacing they look as if they belong to the "small print" line "Valid XHTML 1.0 Transitional? :: Valid CSS? :: Powered by Wikka Wakka Wiki 1.1.6.0?" in the footer - can you maek a screen shot that includes that line? --JavaWoman

Sure. Win 98, IE 6.0.2800.1106 (most recent updates of both as far as I know). I've closed and rebooted several times since leaving this note and it's still there (but farther up the page now, in the middle of the second code block, but with the same spacing). You're right that it's "from" that small print line....those images (and you cannot right-click and get properties on them....they're visible, but NOT there, if you get what I mean) are NOT on that line as a matter of fact and the spacing corresponds exactly. I've never seen it at any other site, but have noticed it a few times at wikka recently...but not always. It persistently (which means ALMOST always) shows up on the bannermaker page when I go there. -- GmBowen

Further questions: Does it depend on whether or not you are showing comments on the/a page? And which stylesheet are you using for viewing this site? Any difference when you choose a different stylesheet (TestSkin)? (BTW, that 'infinity' symbol is not an image, it's just a character.) --JavaWoman

No, showing comments or not has no effect. I just looked NOT showing comments and the symbols were halfway up the page in the code block. I'm using the default stylesheet as far as I know (I've not changed it)...and when I do switch to yours they're still there (on a different vertical part of the page, but it varied before anyways. Oh, right, that's a character. Well, what's weird is you can't highlight it either. It's like a ghost image. Weird. --GmBowen

TEST: Please try with my stylesheet again, to see if that makes any difference now (I tweaked it). --JavaWoman

Answer: Sorry to say, the floaters are still there in IE even using your stylesheet. (FYI....I tried using your stylesheet in Netscape 4.7 & it crashed the TestSkin page. I can go to other pages with your stylesheet in Netscape, but I get the WSOD on the TestSkin page and can't change to anything else. Later...closing & re-opening NS allowed me to re-set it to the wikka.css....and it "crashed" the page again. Obviously there are broader NS problems....wikka's homepage doesn't load at all using any skin in NS 4.7.) --GmBowen

Forget about NS 4.x - it doesn't really support stylesheets. The only solution for that would be detecting it and not giving it a stylesheet at all. I'd like to trace the problem with IE6 though ... even though I cannot reproduce it with my IE6 on Win2K. It may not be standards-compliant, but there's still an awful lot of people using it, even when FireFox is taking market share from it now. I have to think about another approach but I still suspect it's something to do with the (valid) stylesheet that trips up IE6. Thinking... --JavaWoman

Any chance it's a videocard memory issue? It's a new ATI card, but that the images jump around on re-loads is interesting to me. It's like the video driver is doing something as video memory fills in different ways. --GmBowen

Sounds unlikely to me - and they're not images, remember? Just text, but bits of text positioned by means of a stylesheet. Any chance of testing with a different machine, different video card, but same Browser+OS? Meanwhile, I'll sleep on it. :) --JavaWoman

Another idea just struck me: are you using some security software (like Norton security) or a proxy (like The Proxomitron or Privoxy) that sits between your browser and the Internet? That might "do" things to the page to cause a different display. I'm asking because I know The Proxomitron can cause display problems - and the problem seems to be unique to your machine/browser... Another thing to try would be to get Mozilla or Firefox and see if that shows the same problem on your machine. --JavaWoman

Ya, I'm using a firewall & avg antivirus software....but no proxy stuff. Firefox doesn't cause the same problem tho'. I've also noticed those images when I've gone to a couple of pages on my site as well (so it's not a wikka 1.1.5.3 problem)....so that's what's really weird...it consistently happens with some pages only. Even really simple ones without actions etc.

I'm out of ideas, Mike, except that it's probably something to do with the stylesheet and IE (more likely since you don't see it with FF) - plus something else... Try to find a pattern, is all I can suggest. Note down at which pages it happens. See what shakes out. --JavaWoman

Mike, was this ever resolved? --JavaWoman

Login Problem

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

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..

--GregorLindner

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

Actually it is really easy to do a whole-word search--just include the item in double quotes. This info can be found at the bottom of the text search page in the Tips section. To address your issue, I added a regular expression to the search function:

 if (preg_match('/[A-Z]/', $phrase)) $phrase = "\"".$phrase."\"";

If a capital letter is found in the search phrase, the search phrase will be automatically enclosed in double quotes for you. This seems to fix what you didn't like, but shouldn't cause too much unexpected behaviour for others. Let me know what you think. -- JsnX 27 Nov 2004

CategoryDevelopmentSuggestions

Wikka : WikkaBugs

Bugs/Issues discovered in Wikka!

How do I report a bug?

Read this first

No Registration Wikki

Valid Email Addresses

List parsing bug?

Missing language-support in the code formatter

1.1.6.0beta4: Simplified Chinese (or Unicode relative) in WikiEdit :

Indenting not working properly in handlers/page/edit.php

Accept-Encoding: gzip;q=0, deflate

Error on ./handlers/page/referrers_sites

Yet more formatter bugs

Admin email at installation

Encoding of GeSHi

MySQL issue