Wikka: Bugs/Issues discovered in Wikka!

Most recent edit on 2008-06-24 13:31:26 by NilsLindenberg [overlooked bug -> trac]

Additions:
Ticket:783∞

Deletions:
in version 1.1.6.2
using a code tag like this (A)

#include <iostream>
int main() {
 std::cout <<"Hello World\n";
 return 0;
and then one like this (B)
some rubish
in situation A
grab button will return you a file called test.cpp.txt (small issue here with the extra-extension)
solution: in file **handlers/page/grabcode.php**

(php;20)
defaults
define('DEFAULT_FILENAME', 'codeblock.txt'); # default name for code blocks
define('FILE_EXTENSION', '.txt'); # extension appended to code block name
should be changed to
%%(php;20)
defaults
define('DEFAULT_FILENAME', 'codeblock.txt'); # default name for code blocks
define('FILE_EXTENSION', ); # extension appended to code block name
in situation B
when you click grab you will get the same name for the file like in situation A (test.cpp.txt or test.cpp, if corrected) instead of what you would expect (some default name eg codeblock.txt)

Edited on 2008-06-24 10:15:58 by DarTar [removing outdated text and links]

Additions:

How do I report a bug?

Wikka has a dedicated issue tracker.

If you have something to report:

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

Deletions:

New Wikka Tracker available

We are happy to announce that Wikka has just opened a dedicated issue tracker. We are currently migrating open issues, bugs and feature requests from this site to the new server but this migration isn't complete yet.

Meanwhile, if you have something to report:

If not: please use the issue tracker to report your new bug or issue.

Thanks for your understanding.

Read this first:

check resolved bugs/issues (in released or to-be-released code) in WikkaBugsResolved first
for issues related to Wikka layout refer to WikkaCSS
for feature suggestions go to the SuggestionBox

Note:

For problems with foreach in PHP version 4.3.10:
See WikkaBugsResolved

Edited on 2008-06-24 02:10:43 by NilsLindenberg [removing trac references for fixed bugs]

Deletions:

Retrieving user-information (Session Leakage)

Multiple wikka installations on one host: Login security hole?

Ticket:81∞

Reuse of Username when multiple wikkas on single server

Ticket:81∞

Safari and WikiEdit

Ticket:83∞

Windows Paths With {{files}} Action

Ticket:89∞

GetEnv is not a good idea!

Ticket:98∞

Backlinks / LoadPagesLinkingTo()

Ticket:48∞

Category name matching

Ticket:233∞

Edited on 2008-01-28 00:16:00 by JavaWoman [Modified links pointing to docs server]

Additions:

general help can be found on the Wikka documentation page∞

Deletions:

general help can be found on the Wikka documentation page

Edited on 2007-12-12 11:23:03 by JavaWoman [prevent function references looking as page links]

Additions:

GetEnv is not a good idea!

Deletions:

GetEnv is not a good idea!

Edited on 2007-12-12 10:58:19 by JavaWoman [prevent Apache directives looking as page links]

Additions:
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 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]

Deletions:
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
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)

Edited on 2007-08-03 16:31:01 by JavaWoman

Additions:
%%(cpp;;test.cpp)

Deletions:
%%(cpp;test.cpp)

Edited on 2007-04-19 17:40:29 by DarTar [let's stop kidding-ACL changed]

Additions:

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

Extreme extreme slowness

Not being registered makes no difference. There are users reporting Wikka pages taking several minutes to load!
The guys on the Puppy Linux Forum (SimpleForumPro, a Perl script on the same host, runs real fast), have been analysing the problem, discussion here (look further down the page):
http://www.goosee.com/puppy/sforum/simpleforum_pro.cgi?fid=07&topic_id=1111215715&page=2∞
...anyone got any thought what the cause could be?

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 1.1.6.0? 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

Code tag % % ... % % problems

in version 1.1.6.2
using a code tag like this (A)

#include <iostream>
int main() {
 std::cout <<"Hello World\n";
 return 0;
}

and then one like this (B)

some rubish

in situation A
grab button will return you a file called test.cpp.txt (small issue here with the extra-extension)
solution: in file handlers/page/grabcode.php

// defaults
define('DEFAULT_FILENAME', 'codeblock.txt'); # default name for code blocks
define('FILE_EXTENSION', '.txt'); # extension appended to code block name

should be changed to

// defaults
define('DEFAULT_FILENAME', 'codeblock.txt'); # default name for code blocks
define('FILE_EXTENSION', ''); # extension appended to code block name

in situation B
when you click grab you will get the same name for the file like in situation A (test.cpp.txt or test.cpp, if corrected) instead of what you would expect (some default name eg codeblock.txt)
CategoryDevelopmentSuggestions

Deletions:

Edited on 2007-04-19 16:46:00 by 200.118.2.164

Additions:

Deletions:

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

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

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

Wrong Links

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

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

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

Extreme extreme slowness

Email forgotten password action

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 1.1.6.0? 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

$_REQUEST problem

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

thanks, JoshJohn

Floating off-wiki link image

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

(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

Code tag % % ... % % problems

in version 1.1.6.2
using a code tag like this (A)

#include <iostream>
int main() {
 std::cout <<"Hello World\n";
 return 0;
}

and then one like this (B)

some rubish

in situation A
grab button will return you a file called test.cpp.txt (small issue here with the extra-extension)
solution: in file handlers/page/grabcode.php

// defaults
define('DEFAULT_FILENAME', 'codeblock.txt'); # default name for code blocks
define('FILE_EXTENSION', '.txt'); # extension appended to code block name

should be changed to

// defaults
define('DEFAULT_FILENAME', 'codeblock.txt'); # default name for code blocks
define('FILE_EXTENSION', ''); # extension appended to code block name

Edited on 2007-04-19 15:58:26 by BrianKoontz [Restored]

Additions:

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

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

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

Wrong Links

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

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

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

Extreme extreme slowness

Email forgotten password action

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'

Wikka : WikkaBugs

How do I report a bug?

Read this first

New Wikka Tracker available

Note:

Spaces in uploaded files

history bug

usersettings.php

WantedPages problem

Retrieving user-information (Session Leakage)

Multiple wikka installations on one host: Login security hole?

Reuse of Username when multiple wikkas on single server

Safari and WikiEdit

Windows Paths With {{files}} Action

GetEnv is not a good idea!

Backlinks / LoadPagesLinkingTo()

Category name matching

GetEnv is not a good idea!

GetEnv is not a good idea!

remote (or local) won't load Wikka

Wikka and WebDAV

Wrong Links

Logout fails silently or takes long time on SourceForge hosted site

.htaccess settings yields consistent error 403 on Apache

Messages delayed

Extreme extreme slowness

Email forgotten password action

Using compression

PHP5 + GESHI

Wiki Edit causes lockup

$_REQUEST problem

Floating off-wiki link image

Login Problem

User search - should be case-sensitive

Code tag % % ... % % problems

remote (or local) won't load Wikka

Wikka and WebDAV

Wrong Links

Logout fails silently or takes long time on SourceForge hosted site

.htaccess settings yields consistent error 403 on Apache

Messages delayed

Extreme extreme slowness

Email forgotten password action

Using compression

PHP5 + GESHI

Wiki Edit causes lockup

$_REQUEST problem

Floating off-wiki link image

Login Problem

User search - should be case-sensitive

Code tag % % ... % % problems

remote (or local) won't load Wikka

Wikka and WebDAV

Wrong Links

Logout fails silently or takes long time on SourceForge hosted site

.htaccess settings yields consistent error 403 on Apache

Messages delayed

Extreme extreme slowness

Email forgotten password action