Revision history for WikkaBugs


Revision [23416]

Last edited on 2016-05-20 07:38:48 by JeyRey [Replaces old-style internal links with new pipe-split links.]
Additions:
~-general help can be found on the [[Docs:WikkaDocumentation | Wikka documentation page]]
Deletions:
~-general help can be found on the [[Docs:WikkaDocumentation Wikka documentation page]]


Revision [20755]

Edited on 2009-08-17 09:46:45 by JeyRey [over 5 year old resolved issue removed]
Deletions:
===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?


Revision [20061]

Edited 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)
%%(cpp;;test.cpp)
#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)


Revision [20059]

Edited on 2008-06-24 10:15:58 by DarTar [removing outdated text and links]
Additions:
""<div style="padding:5px; background-color:#FEE; border:1px solid #EDD"><h5>How do I report a bug?</h5><p>Wikka has a dedicated <a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a>.</p>
<p>If you have something to report:<br/>
<li>If not: please use the <strong><a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a></strong> to report your <strong>new</strong> bug or issue. Again, <a href="http://wush.net/trac/wikka/search?ticket=on">search first</a> to make sure your issue has not been reported yet.</li></ul>
</div>""
<<==Read this first==
<<::c::
Deletions:
""<div style="padding:5px; background-color:#FEE; border:1px solid #EDD"><h5>New Wikka Tracker available</h5><p>We are happy to announce that Wikka has just opened a dedicated <a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a>. We are currently migrating open issues, bugs and feature requests from this site to the new server but this migration isn't complete yet.</p>
<p>Meanwhile, if you have something to report:<br/>
<li>If not: please use the <strong><a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a></strong> to report your <strong>new</strong> bug or issue.</li></ul>
<p>Thanks for your understanding.</p></div>""
<<**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>>::c::


Revision [20049]

Edited on 2008-06-24 02:10:43 by NilsLindenberg [removing trac references for fixed bugs]
Deletions:
===Spaces in uploaded files===
[[Ticket:46]]
===history bug===
[[Ticket:75]]
===usersettings.php===
[[Ticket:76]]
===WantedPages problem===
[[Ticket:49]]
===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]]


Revision [19431]

Edited on 2008-01-28 00:16:00 by JavaWoman [Modified links pointing to docs server]
Additions:
~-general help can be found on the [[Docs:WikkaDocumentation Wikka documentation page]]
Deletions:
~-general help can be found on the [[WikkaDocumentation Wikka documentation page]]


Revision [17820]

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!====


Revision [17813]

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)


Revision [17322]

Edited on 2007-08-03 16:31:01 by JavaWoman [prevent Apache directives looking as page links]
Additions:
%%(cpp;;test.cpp)
Deletions:
%%(cpp;test.cpp)


Revision [16466]

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.
%%(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
%%(php)
"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.
%%(apache)
### 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 {{wikkaversion}}? 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)
<?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 "**dan**gerous" - 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)
%%(cpp;test.cpp)
#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)
CategoryDevelopmentSuggestions
Deletions:
~


Revision [16465]

Edited on 2007-04-19 16:46:00 by 200.118.2.164 [let's stop kidding-ACL changed]
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===
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.
%%(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
%%(php)
"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.
%%(apache)
### 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 {{wikkaversion}}? 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)
<?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 "**dan**gerous" - 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)
%%(cpp;test.cpp)
#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)
CategoryDevelopmentSuggestions


Revision [16464]

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===
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.
%%(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
%%(php)
"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.
%%(apache)
### 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 {{wikkaversion}}? 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)
<?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 "**dan**gerous" - 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)
%%(cpp;test.cpp)
#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)
CategoryDevelopmentSuggestions
Deletions:
~


Revision [16463]

Edited on 2007-04-19 14:54:53 by 195.254.148.73 [Restored]
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===
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.
%%(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
%%(php)
"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.
%%(apache)
### 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 {{wikkaversion}}? 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)
<?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 "**dan**gerous" - 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)
%%(cpp;test.cpp)
#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)
CategoryDevelopmentSuggestions


Revision [16461]

Edited on 2007-04-19 13:59:53 by DarTar [reverting deletions]
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.
%%(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
%%(php)
"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.
%%(apache)
### 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 {{wikkaversion}}? 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)
<?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 "**dan**gerous" - 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)
%%(cpp;test.cpp)
#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)
CategoryDevelopmentSuggestions
Deletions:
~


Revision [16457]

Edited on 2007-04-19 13:45:44 by 61.144.122.45 [reverting deletions]
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===
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.
%%(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
%%(php)
"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.
%%(apache)
### 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 {{wikkaversion}}? 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)
<?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 "**dan**gerous" - 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)
%%(cpp;test.cpp)
#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)
CategoryDevelopmentSuggestions


Revision [16451]

Edited on 2007-04-19 13:28:53 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===
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.
%%(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
%%(php)
"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.
%%(apache)
### 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 {{wikkaversion}}? 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)
<?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 "**dan**gerous" - 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)
%%(cpp;test.cpp)
#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)
CategoryDevelopmentSuggestions
Deletions:
~


Revision [16439]

Edited on 2007-04-19 09:15:45 by 58.224.231.152 [Restored]
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===
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.
%%(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
%%(php)
"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.
%%(apache)
### 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 {{wikkaversion}}? 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)
<?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 "**dan**gerous" - 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)
%%(cpp;test.cpp)
#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)
CategoryDevelopmentSuggestions


Revision [16433]

Edited on 2007-04-19 09:13:50 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===
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.
%%(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
%%(php)
"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.
%%(apache)
### 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 {{wikkaversion}}? 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)
<?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 "**dan**gerous" - 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)
%%(cpp;test.cpp)
#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)
CategoryDevelopmentSuggestions
Deletions:
~


Revision [16407]

Edited on 2007-04-19 08:30:25 by 201.21.152.136 [Restored]
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===
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.
%%(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
%%(php)
"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.
%%(apache)
### 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 {{wikkaversion}}? 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)
<?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 "**dan**gerous" - 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)
%%(cpp;test.cpp)
#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)
CategoryDevelopmentSuggestions


Revision [15492]

Edited on 2006-10-12 10:27:50 by AlinElena [Restored]
Deletions:
%%(php;#20)


Revision [15491]

Edited on 2006-10-12 10:26:56 by AlinElena [Restored]
Additions:
%%(php;20)
%%(php;#20)
Deletions:
%%(php,#20)
%%(php,20)


Revision [15490]

Edited on 2006-10-12 10:26:28 by AlinElena [Restored]
Additions:
%%(php,20)


Revision [15489]

Edited on 2006-10-12 10:25:06 by AlinElena [Restored]
Additions:
===Code tag % % ... % % problems===
in version 1.1.6.2
using a code tag like this (A)
and then one like this (B)
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)
Deletions:
===Code tag %% %% problems===
using a code tag like this
and then one like this


Revision [15488]

Edited on 2006-10-12 10:13:43 by AlinElena [Restored]
Additions:
===Code tag %% %% problems===
using a code tag like this
%%(cpp;test.cpp)
#include <iostream>
int main() {
std::cout <<"Hello World\n";
return 0;
and then one like this
some rubish


Revision [15343]

Edited on 2006-09-18 19:38:52 by GrantYoung [Restored]
Deletions:
===1.1.6.2 issue with editor area===
We're experiencing a problem with the editor area appearing as a very small text box (not scaling to fill the screen) when using:
- Firefox (1.0.6 and possibly others on Windows)
- Camino (1.0.1 Mac OS X)


Revision [15342]

Edited on 2006-09-18 19:38:11 by GrantYoung [Restored]
Additions:
===1.1.6.2 issue with editor area===
We're experiencing a problem with the editor area appearing as a very small text box (not scaling to fill the screen) when using:
- Firefox (1.0.6 and possibly others on Windows)
- Camino (1.0.1 Mac OS X)


Revision [14795]

Edited on 2006-07-11 23:22:46 by WazoO [Restored]
Additions:
~~~~~&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


Revision [14793]

Edited on 2006-07-11 14:36:40 by 67.155.108.10 [Restored]
Additions:
~~~~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


Revision [14632]

Edited on 2006-06-18 14:12:22 by NilsLindenberg [moved issues to trac, deletion of tickets which are closed]
Additions:
[[Ticket:231]]
[[Ticket:232]]
[[Ticket:233]]
Deletions:
===UserSettings for Doubleclick Editing doesn't work===
[[Ticket:3]]
===PasswordForgotten / emailpassword problem with Konqueror (Form-Action missing)===
[[Ticket:41]]
===Wikiedit: Problem with some date strings===
[[Ticket:74]]
===Accesskey on comments===
[[Ticket:77]]
===Email deletion after registration===
[[Ticket:47]]
===Expanded Text Search fails===
[[Ticket:17]]
===passwords containing $ aren't working===
[[Ticket:5]]
===Bug in Textsearch (expanded)===
[[Ticket:9]]
===Formatter-bug in the comments===
[[Ticket:84]]
===Advanced search results reveal confidential info===
[[Ticket:86]]
===Recent[ly]Comment[ed|s] actions should check for permission===
[[Ticket:87]]
===Wikiedit: Link to the Formatting-rules (using IIS and not using mod-rewrite)===
[[Ticket:91]]
===mod_rewrite issue in WikiEdit===
[[Ticket:91]]
===Login/Logout problem in Windows IIS===
[[Ticket:92]]
===Installer array_merge()===
[[Ticket:94]]
===View Code Handler issue===
[[Ticket:96]]
===Tags in the edit notes===
[[Ticket:99]]
[[Ticket:3]]
===Code display problem===
[[Ticket:109]]
----
===Comments in formatted PHP code===
[[Ticket:110]]
If you edit the ACL on a page, click "Store ACLs", then edit the ACL and click "Cancel", it still reads "Access control lists updated.", even though the changes were canceled. This is due to the "Cancel" button causing the browser to navigate backwards, and a javascript popup. --BarkerJr
Yes, I know the category system needs to be revamped, but I figured I'd report this anyway. If you have a category name that is a substring of another category name, pages referencing the second category will also appear in the first. In other words...I have a category named '""CategoryBookOne"", and another named ""CategoryBookOneJournal"". Pages that reference ""CategoryBookOneJournal"" also show up in the list of pages for ""CategoryBookOne"", which is not the behavior I expected or wanted.
-- TammyCravit
~&I cannot reproduce this on this server, nor on my own development system - at least not with the [[WikkaBetaFeatures beta and alpha]] versions of the category action. Possibly dependent on the version of PHP used where older versions may use a slightly different database query to find pages referring to a category. Tammy, if you're reading this: which version of PHP are you using? (We should test with the 'lower-PHP version of the query!) --JavaWoman
First, this may applied to my ISP only. When I installed, I have to use
the ?wakka= options. However, I have to add a / to the end of the
default Basic URL before append ?wakka= to it. So I think it maybe
helpful to modify the instruction to '... so it should include
the "/?wakka=" parameter...'
~&ArpY: Maybe this is caused by a config error. Please have a look at your config - is there a slash at the end of the base_url?
~~&IMO the installer should take care that there is a slash if the user doesn't enter it --JavaWoman
Um, I don't know how to describe this really. Put ""{{include page="Category Documentation"}}"" (//without the space!//)on the SandBox page....I can't figure out why it gives that output as Sandbox doesn't own anything.
~&Looks like the weirdness is caused by the ""{{Category}}"" action which assumes the "current page" represents the category - and find pages "belonging to" a category by finding a mention of that page name. Good sign our category system does need an [[CategorySystemOverhaul overhaul]]! --JavaWoman
~&Include pulls in a page that itself has the category action on it; the "official" version of this action assumes that the page it occurs on **is** a category. The "//experimental//" category action that is now active on this site no longer makes this assumption but recognizes that SandBox isn't a category page and defaults to the top category. See Sandbox for a an example (at this moment). --JavaWoman
~~&I can see that it now works, but what do you mean that it "recognizes that Sandbox isn't an action".....do you mean target page? --GmBowen
~~~&Oops, sorry (corrected now) - I meant the new category action sees whether the page it's "sitting" on is a category page or not - if not it defaults to showing the list for the top-level category. --JavaWoman (aka IamBack)


Revision [13498]

Edited on 2006-03-16 22:32:55 by GiorgosKontopoulos [+ possible solution to "remote (or local) won't load Wikka"]
Additions:
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)


Revision [12580]

Edited on 2006-01-10 15:45:05 by NilsLindenberg [moved bugs to tracker]
Additions:
[[Ticket:108]]
[[Ticket:109]]
----
[[Ticket:110]]
Deletions:
The following combination of conditions triggers the problem:
~-multi-line comment (for instance a multi-line /*........*/ block in php)
~-empty lines within such a comment
~-line numbering turned on
When viewed in Mozilla or Firefox (at least - possibly others), the empty lines **overlap** the preceding lines, as can be seen by the line numbers.
Looking at the generated code, an empty line within a multi-line comment (with line numbers) results in this code: %%(html4strict)<li><div class="de1"><span class="coMULTI"></span></div></li>%%---while an empty line elsewhere results in %%(html4strict)<li><div class="de1"> </div></li>%%---Note the ## ## in the latter case (which gives the div actual content) while the empty multi-comment line has nothing but an **empty** span, and no actual content.
This seems to be a combination of a **GeSHi** bug (there should at least a ## ## be generated as content) combined with a **gecko** oddity (or bug?) that will render a number for an ordered list item but not give it a normal line height if the list item is empty.
**Workaround:** add some whitespace to the empty lines - a single tab works (a space probably will as well).
--JavaWoman
GeSHi has a habit of adding a trailing line if the PHP code contains a comment using ""//"" or ""#"".
For example %%(php) echo "hello world"; // How do you do?%% This does not happen if ""/* */"" is used for comments. For example %%(php) echo "hello world"; /* How do you do? */%%
-- FreekDijkstra
~&Sounds also like a GeSHi problem rather than a Wikka bug. If anyone is installing (or has installed) GeSHi 1.0.6 I'd appreciate feedback on whether this cosmetic problem is solved as well. --JavaWoman
There is another issue with double-click editing: while registered users can edit their preferences to use double-click editing or not, it is always on for non-registered (or not logged-in) users. The result is that on pages that can be edited only by registered users, a double-click results in an unfriendly error message. Especially on a site that is mostly read-only for visitors this is a bad situation. The solution is to make this admin-configurable.
Add to wikka.config.php:
%%(php) "doubleclickedit" => "Y", # set to "N" to disable double-click editing%%
and change the proposed line for the show handler above to:
%%(php;2)<div class="page" <?php echo (((!$user && $this->config['doubleclickedit'] == "Y") || ($user['doubleclickedit'] == 'Y')) && $this->GetMethod
() == "show") ? "ondblclick=\"document.location='".$this->href("edit")."';\" " : "" ?>>
%%--- --JavaWoman
~&In that case, wouldn't you want new profiles to have dblclick turned off by default ? (TroelsKnakNielsen)


Revision [12554]

Edited on 2006-01-06 12:42:41 by DarTar [page cleanup - moving migrated issues to top]
Additions:
[[Ticket:104]]
Deletions:
DarTar and I have recently created some test pages, testing page names related to how Wikka evaluates 'valid' page names: ,My,Page and ÄhnLich (yes, they both exist, even if they don't show up as such in this sentence!). Now look at where they show up on PageIndex... surely there shouldn't be **two** '#' indices??
~&I think that this is due to the encoding of the MySQL tables. I can't see how that would be fixed with a small touch on the code. If this is the matter then I hope that it also rings the i18n bell too. //Translation to Greek is my bussiness ;)// --GeorgePetsagourakis
~~&Yes, my i18n bells were already loudly ringing... but you bring up a good point with MySQL. I hadn't thought about a real cause yet, just wanted to record what I saw before I got distracted again ;-). Sort order is a whole subject of its own within i18n .... --JavaWoman


Revision [12550]

Edited on 2006-01-06 10:54:15 by DarTarTar [page cleanup - moving migrated issues to top]
Additions:
[[Ticket:48]]
[[Ticket:100]]
Deletions:
//reported by |Sam| on #wikka, writeup by me --JavaWoman//
Purging of pages doesn't always seem to happen. |Sam| had the page_purge_time set to 1 (which should purge page versions older than one day) but didn't see them being actually purge. Purging is done in the Maintenance() method in ##wikka.php## executed by the main Run() method. However, there is an extra condition here: %%(php)if(!($this->GetMicroTime()%3)) $this->Maintenance();%% I suspect this may cause the Maintenance() method not being executed. The intention of this (undocumented) condition isn't clear to me - should it really be there? --JavaWoman
~&That's correct. I'm not the author of this code, but the intention is clear to me. It's designed to be a performance improvement. Rather than call the Maintenance function for every single page view(!), it adds some randomness based on the remainder of GetMicroTime() divided by 3. For a busy site this could make a significant drop in MySQL queries. I have done some brief testing of this code and found that on average the Maintenance function was called about every four page views. For any site that has even moderate traffic, the Maintenance function will be triggered sufficiently. To answer your question, yes, this condition should be there. However, maybe there should be a configuration option that admins could tweak if they are obsessed and need certainty that pages get purged. -- JsnX
~~&Another way is to follow what (I think) PHP does for session cleanup. Set a threshold and test if a random number (between 0 and 1, inclusive of 0) is less than that threshold. If so, then do cleanup. Otherwise don't. The threshold is then a percentage chance that cleanup will happen on a particular request instead of hoping that the time falls just right. --JameSmith
===User name matching===
(related to the //Category name matching// item below)
While [[RegisterActionTest testing]] the beta RegisterAction, I realized that using a username like **""DarTartar""** results in a //"Sorry, username already exists"// error. Looks like a problem in the RE used by the ##""LoadUser()""## function. I'll take a look at it ASAP.
-- DarTar
I just discovered that the ##""{{backlinks}}""## action may list pages that don't "exist" any more, in the sense that they (apparently) still are in the database but without any active version (seemingly as a result of a rename action. I added an example on [[JavaWoman my own page]] where you can see a supposed backlink from ReleaseNotes (which was replaced by WikkaReleaseNotes).
~&The cause is apparently in the ""LoadPagesLinkingTo()"" method which is used by ##""{{backlinks}}""## action. It currently is implemented like this:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' order by tag"); }
%% I think replacing this by:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' and latest = 'Y' order by tag"); }
%% might do the trick to avoid deceased pages - but please test!
~&--JavaWoman
~~&It wont do, since the link-table has no latest col ;). But shouldn't the delete-handler delete these links from the table anyway? --NilsLindenberg
~~~&Indeed it is the delete handler that is at fault here by not deleting all records from the links table that refer to the (to be) deleted page. This is simple enough to fix (by extending the query a little to match both the "from_tag" and "to_tag" columns) but for a future version to be released with such a fix there should also be an (admin-only) utility to clear left-behind records from the links table that //should// have been deleted before. --JavaWoman


Revision [12549]

Edited on 2006-01-06 09:56:54 by DarTar [page cleanup: moving migrated items to top]
Additions:
===Tags in the edit notes===
[[Ticket:99]]
Deletions:
When in edit mode using IIS if you click the help button the program doesn't take you to the FormattingRules page, but tries to go to the ""FormattingRules"" Directory, which does not exist.
~& It assumes that you're using mod_rewrite and goes to the "pretty" url (wikka.jsnx.com/""FormattingRules"" instead of wikka.jsnx.com/wikka.php?wakka=""FormattingRules"") - this needs to either be editable (or is it somewhere in the WikiEdit files and I just haven't found it?) or check with the wikka.config.php to make sure it's using the correct base_url. --MovieLady
===tags in the edit notes===
I made a edit note: "removed a <?php (to much)" and got "removed a". Perhaps replacing <> would be the better option? --NilsLindenberg
~&Funny - I just stumbled over the same problem - only in the RecentChanges newsfeed: the <?php causes imbalanced tags there, and thus a syntax error: until that post has "aged" off of the feed, it can't be loaded any more! The [[http://feedvalidator.org/check?url=http%3a%2f%2fwikka.jsnx.com%2fRecentChanges%2frecentchanges.xml validation result]] clearly shows what the problem is. So yes, edit notes should be fed threough htmlspecialchars[_ent]() everywhere they're presented, and that includes the RSS feed! --JavaWoman
~~&And the WikiPing, too :) --NilsLindenberg
~&Oh is **that** what you removed Nils. I couldn't figure out using history what you did. Where did you take it from? And why? Did I have one more <?php than was necessary? In which code block? --GmBowen
~~&It was at the beginning of mail.php: %%(php) <?php <?php%%. I guess you overlooked it when you copied your new version to the page. Happened to me in another case, too. --NilsLindenberg
~&Actually, the problem is not just with tags; any XML "special character" is going to cause an XML error. All will need to be escaped to ensure the RSS feeds and pings are valid XML. (We are having a problem again...) --JavaWoman
~~&Fixed now: Code changes in wikka.php (GetPingParams()), actions/recentchanges.php, handlers/page/recentchanges.xml.php, handlers/page/recentchanges.xml.mm.php, handlers/page/revisions.php and handlers/page/revisions.xml.php. Installed on this server as "beta test" so we can watch behavior. --JavaWoman


Revision [12548]

Edited on 2006-01-06 09:49:29 by DarTar [page cleanup: moving migrated items to top]
Additions:
[[Ticket:96]]
[[Ticket:97]]
[[Ticket:98]]
Deletions:
The view code handler does not display any message if the page does not exist. [[http://wikka.jsnx.com/NonExistantPage/showcode Example]] -- Rick
~& Technically, it isn't a bug: Wikka tries to display original data concerning the page. As it doesn't exists, Wikka displays nothing. It isn't a bug but a non-existent feature of Wikka, so I would put this comment in SuggestionBox instead of here. JavaWoman? DarTar? What do you think of it? -- PivWan
~~&Actually, I suggested Rick reported it here since I **do** consider it a bug. It is a **page** handler so the handler should look for a page; I think it should return //something// at least. IMO the best solution would be to generate a warning like "Page does not exist" when the page isn't found, or use the "do you want to create it?" we use when accessing a non-exstant page. --JavaWoman
~~~& Okay, hadn't the whole story. So, it's a bug :) -- PivWan
Gathered from error reports in different places (including comments on WikkaInstallation, #wikka and IM) - neither new, but worth repeating and putting together, I think:
~-In at least some cases the "detected" base path misses a closing slash (resulting in links that don't work); the installer should check if the derived path has a final slash, and if not, add one, before presenting that to the user.
~-If PHP (and thus Wikka) cannot connect to MySQL the installer just "hangs" after the first screen and printing "Testing configuration"; this seems to be (at least partly) the result of having error messages from the MySQL statements suppressed with a @, which would be OK if the error message were handled afterwards - but this doesn't happen. Other mysql_xxx() calls in the installer also have the @ suppressing error messages. That should either be removed, or all error messages should be picked up and handled by the installer, at the very least by showing the message to the user. ---
~This is especially a problem for users new at MySQL or new even at PHP+MySQL for whom it won't be obvious where to start troubleshooting when the installer simply hangs.
At ./wikka.php, you will see a line %%(php)<?php if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";?>%%
In the most cases, a website is hosted in a machine as a VirtualHost, this means that a number of websites share the same environment variables. If someone knows where your site is hosted, he can put his site at the same server, and use a script containing %%(php)<?php putenv('WAKKA_CONFIG=/home/hacker/config.php');?>%%. And all wikka sites on the same server will use his configuration file. The rest actions to take to hack your site will be as easy as eating sandwich.
Php doc says that an environment variable is altered only during the life of the script, but with my dev Easyphp's on windows, that is false. (I think a "new" environment variable keep its value, even on Linux).
I wanted to make a unique Wikka interface used by 3 sites on the same server. The best secure solution I found is to alter ./wikka.php like this :
%%(php)<?php
if (file_exists("wakka.config.php")) rename("wakka.config.php", "wikka.config.php");
#if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";
if (!$configfile && isset($GLOBALS['wikka_config'])) $configfile = $GLOBALS['wikka_config'];
if (!$configfile) $configfile = "wikka.config.php";
if (file_exists($configfile)) include($configfile);
and put the 2 files sitenumber2.php and .htaccess below at the root of the server number 2:
__sitenumber2.php:__
%%(php)<?php
$GLOBALS['wikka_config'] = "/path/to/altered_config.php";
chdir("/path/to/basewikka");
include('wikka.php');
?>%%
__.htaccess:__
%%<IfModule mod_rewrite.c>
RewriteRule ^(css|images|wikiedit2)/(.*)$ /path/to/basewikka/$1/$2 [L]
RewriteRule ^(.*)$ sitenumber2.php?wakka=$1 [QSA,L]
</IfModule>%%
--DotMG
~&I've now written up my thoughts about a [[WikkaSecureConfig more secure way to handle Wikka's configuration]] (which should also provide also more flexibility). --JavaWoman


Revision [12547]

Edited on 2006-01-06 09:03:05 by DarTar [page cleanup - moving migrated issues to top]
Additions:
===== {{done}} Bugs reported on the tracker =====
===== {{todo}} Bugs still to be checked/migrated =====
Deletions:
==== Bugs reported on the tracker {{done}} ====
==== Bugs still to be checked/migrated {{todo}} ====


Revision [12546]

Edited on 2006-01-06 09:01:57 by DarTar [page cleanup - moving migrated issues to top]
Additions:
<li>If so: check if it has a link to a ticket:<ul>
[[Ticket:95]]
Deletions:
<li>If so: check if it has a link to a tracker ID:<ul>
//reported by velkr0 on #wikka, analysis and writeup by me -- JavaWoman//
**Problem**: When the rss action is included in a page with a feed URL that happens not to exist (or not exist any more), the page "hangs"; once in this state, editing the page also isn't possible: the hang continues until the browser times out or is closed.
The obvious cause is that neither the ""{{rss}}"" action nor the underlying onyx-rss class checks for //existence// of the resource the feed URL refers to. The problem is already hard to detect when you are first including a feed in a page and maybe make a typo in the feed URL. But if your Wikka provides a page with one or more feeds, and a feed suddenly disappears (or is down momentarily) the result will be very annoying for your visitors.
**Solution**: Either the onyx-rss class or the rss action should check for the availability of the feed (for instance with a HEAD request) before actually trying to retrieve it. Since the class provides caching, the best option would be to handle it in the class (by subclassing the necessary method(s)). If a version of the feed still exists in the cache that version could be displayed (probably this happens automatically anyway), otherwise an error message should be generated instead of the feed output. --JavaWoman
Another problem with Onyx-RSS was just reported by |Sam| on #wikka: in spite of cacheing it seems quite slow, taking something like 2.5 seconds for rendering after retrieving a feed (compared to a normal page rendering time of 0.06 seconds). We should look at the efficiency (or not) of this class - maybe it's time to move to another one that's being actively maintained. --JavaWoman


Revision [12545]

Edited on 2006-01-06 08:35:37 by 83.119.39.77 [page cleanup - moving migrated issues to top]
Additions:
==== Bugs reported on the tracker {{done}} ====
[[Ticket:94]]
==== Bugs still to be checked/migrated {{todo}} ====
Deletions:
==== Bugs reported on the tracker ====
==== Bugs still to be checked/migrated====
//Mentioned in passing on #wikka by a user having actually other problems installing Wikka.//
Remember the array_merge() problem in wikka.php under PHP5? Solved in 1.1.6.0.
Guess what: the same problem still exists - but in the installer itself (##/setup/install.php## - line 7): the second argument is (again) not initialized so users get a warning stating "Argument #2 is not an array in /var/www/html/Wikka/setup/install.php on line 7".
We'd better solve it in the installer as well. --JavaWoman


Revision [12544]

Edited on 2006-01-06 08:30:02 by 83.119.39.77 [page cleanup - moving migrated issues to top]
Additions:
===Purging should not remove the whole history of a page===
[[Ticket:93]]
Deletions:
===Alzheimers for Wikka?===
This is not a bug specifically - it is really a potential implentation weakness, but if a user specifies a page purge time in wikka.config: "pages_purge_time" => "100" and if that page is not edited for a while, then when that page is edited, the last copy will be deleted, leaving no archived copies at all. I think purge pages should delete old pages, but there should always be a minimum number of old copies preserved, otherwise the wiki becomes highly vulnerable to a content deletion attack. Would it be better to remove this feature, or modify it? --IanAndolina
~&Instead of removing or modifying it (the configuration parameter, rather) we could refine it by introducing an extra parameter name something like "pages_keep" to set a maximum number of pages to be kept regardless (maximum, since it could be less if there are not that many versions in the first place). Setting one or the other to 0 could disable purging altogether. --JavaWoman
~~&Sounds good to me - can you think of an elegant way to modify the SQL query to only delete pages older than X that are also more than Xth on a list of revisions. I'm sure I can come up with something ugly ;) --IanAndolina
~~~&I'm good enough at SQL that I need the manual for that. ;-) As far as I can determine, you need two statements (semi pseudo code): 1) a ##select count(*) from pages where ...## to determine the current number of records; and 2) ##delete from pages where ... order by [timestamp] limit [$count - $pages_keep]##. You can't do a subquery in delete (yet) so the count must be a separate step (but it should be very fast). --JavaWoman


Revision [12543]

Edited on 2006-01-06 08:17:37 by DarTar [page cleanup - moving migrated issues to top]
Additions:
See CharsetNotSupportedWorkaround
[[Ticket:90]]
[[Ticket:91]]
===Login/Logout problem in Windows IIS===
[[Ticket:92]]
Deletions:
from [[http://arek.c-consulting.co.id/ivan/wikka/wikka.php?wakka=WikiEditHack IvanLaninWiki]]: (see there for his solution)
//I don't use rewrite_mode since I'm using IIS as server, and I also put value for base_url for my wikka. Then I notice, by accident, that the Help button on WikiEdit? does not point to the right page (FormattingRules).//
===Wikka in Windows IIS===
When Wikka is installed in IIS5.0 occurs an error when using cookies and using the header(Location:)
http://br.php.net/manual/pt_BR/function.setcookie.php#51195
This error implies in not log in or out, because the page redirects before the cookie i created.
The problem can be solved using javascript to redirect the page, just change the following line in the code of Redirect function on wikka.php:
%%(php)header("Location: ".$url);%%
by this:
if (substr_count($_SERVER["SERVER_SOFTWARE"],"IIS") > 0) {
~& echo '<SCRIPT>window.location.href = "'.$url.'";</SCRIPT>';
} else {
~& header("Location: ".$url);
-- MarceloArmonas (sorry, i don't write in english)
My default installation of Wikka 1.1.6.0 did display the error
htmlentities(): charset `646' not supported, assuming iso-8859-1 in /home/www/WWW/files/research/air/wiki/3rdparty/plugins/geshi/geshi.php
on the FormattingRules page. I was able to fix this by adding the "set_encoding" line in the GeSHi_Highlight() function in wikka.php:
$geshi =& new GeSHi($sourcecode, $language, $this->config['geshi_languages_path']); # existing code
$geshi->set_encoding('UTF-8'); # set encoding (new line)%%
~&This is actually not a Wikka bug, but a problem in GeSHi itself - which only appears in rare cases. See CharsetNotSupportedWorkaround for more information. I think the latest GeSHi version (1.0.6) has addressed this problem. If you'd like to try this, make sure you remove the workaround code in Wikka when installing the new GeSHi version. --JavaWoman
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
~~&I'm running MySQL 5 fine with the mysql_* functions. When you compile PHP, it's your choice to compile the mysql_* or mysqli_* functions. I chose to compile it with mysql_*, which is working fine for me. --BarkerJr


Revision [12542]

Edited on 2006-01-05 22:24:47 by DarTar [page cleanup - moving migrated issues to top]
Additions:
[[Ticket:89]]
[[Ticket:34]]
===Login Problem===
===User search - should be case-sensitive===
Deletions:
//reported in IRC while I was asleep, sorry - JW does have to sleep sometimes//
(Potential) User extremely frustrated when at installation he's entering a real and valid email address and the Installer rejects it with "Email appears incorrect". This is caused by the extremely brain-dead Javascript in the installer that accepts **nothing but lowercase letters** to appear before the '@'. To be anywhere like realistic it should be corrected to accept numbers, dots, hyphens and underscores as well.
--JavaWoman //(hoping the reporter shows up again so I can help him with a workaround)//
~& Gosh, this is //really// annoying. JW, any news from your general-purpose [[WikkaEmailToolkit email validation]] functions ;-) -- DarTar
~~&The basic problem is that the installer does not use any system routines but instead JavaScript for validation. And the RE it uses for email validation is really, really braindead. Yes, very annoying as I've not seen the user back in #wikka either - we may have lost a user. I could have given a workaround if only I'd not been sleeping. --- Email library is not quite ready but getting close (needs some restructuring, basically); it will be a class, with several abstract methods so the installer should be able to use it as well (provided it can find the class file). And I'm learning some good tricks working on the sessions module (which might also be useful for Wikka). But the installer needs a major overhaul in any case. Sigh... --JavaWoman
(partly) [[Ticket:3]]
Looking at **formatters/wikka.php** to find the cause of the two bugs listed below (found one), I notice to my horror that a **lot** of the regular expressions used there are actually incorrect. They allow such things as using a comma to indent a line (in addition to a tab, or ~, at the start of a line: **demo** in the SandBox, and in the list **below**!), or a comma in a WikiName (even at the start) or in an InterWiki link. That can't have been the intention - it's simply a matter of incorrect RE syntax. I'd become sort of "sensitized" to this phenomenon looking at DarTar's RE on ValidPageNames earlier today - now I see where he found an example (see my comment on that page on his RE!).
''See also [[,My,Page]] - yup, that's a real page now. ;-)''
~&Rather than simply fixing all the REs (and other REs all over the place...) I'd like to propose a more fundamental solution:
~&-create a "library" of RE building blocks to be used in the Wikka core (for an example of what I mean with building blocks see my propopsal for an alternative RE on ValidPageNames); simply create a separate file with define()s for these building blocks, and include them at the start of the main wikka.php file;
~&-gather all RE used in the Wikka core here (extensions/plugins could have their own set of defines - as long as they don't have conflicting names);
~&-now use **only** these building blocks when using REs anywhere in the Wikka core.
~&This should make it much easier to create both //correct//, and //consistent// regular expressions; any (near)duplicates will be much easier to discover, and fix.
~&Probably best to leave this to just **after** the coming release, so we have a stable code base again. I volunteer to undertake this work. (Unlike some people, I happen to like REs.) :)
==Login Problem==
==User search - should be case-sensitive==
On a Windows/IIS installation, including the ""{{files}}"" action causes errors similar to the following:
Warning: mkdir(uploads\SandBox): Permission denied in D:\sitepath\wwwroot\wikka\actions\files.php on line 12
Warning: opendir(uploads\SandBox): failed to open dir: Invalid argument in D:\sitepath\wwwroot\wikka\actions\files.php on line 156
Warning: readdir(): supplied argument is not a valid Directory resource in D:\sitepath\wwwroot\wikka\actions\files.php on line 157
Warning: closedir(): supplied argument is not a valid Directory resource in D:\sitepath\wwwroot\wikka\actions\files.php on line 200
This is caused by the assumption of "/" as the directory seperator instead of Window's "\". Using the DIRECTORY_SEPARATOR variable corrects this is.
In actions/files.php change:
$upload_path = $this->config['upload_path'].'/'.$this->GetPageTag();
%% into
$upload_path = $this->config['upload_path'].DIRECTORY_SEPARATOR.$this->GetPageTag();
and also:
$destfile = $upload_path.'/'.$strippedname;
%% into
$destfile = $upload_path.DIRECTORY_SEPARATOR.$strippedname;
Warning: This has only been tested so far under Windows. -- QualousHere


Revision [12541]

Edited on 2006-01-05 18:37:35 by DarTar [page cleanup - moving migrated issues to top]
Additions:
[[Ticket:1]]
Deletions:
Line 46 :
- Code generates a double </a> for links.
- & in URL should be replaced by &
=> %%(php) print("<td valign=\"top\">" . (($site != "unknown") ? "<a href=\"http://".$this->htmlspecialchars_ent($site)."\">".$this->htmlspecialchars_ent($site)."</a>" : $site) . /*"</a> ".*/($IsAdmin ? "[<a href=\"".$this->href("delete_referrer", "", "spam_site=").$this->htmlspecialchars_ent($site)."&redirect=".$this->GetMethod()."\">Blacklist</a>]" : "")."</td>");%%
Note: You cannot see this error by validating directly a page because W3C is not registered and it will not have the same output as you, in other words, code on line 46 won't be executed. But you can save the page on your hard disk and validate it.


Revision [12540]

Edited on 2006-01-05 18:30:13 by DarTar [page cleanup - moving migrated issues to top]
Additions:
[[Ticket:88]]
Deletions:
**Not really bug, but should be corrected for respect & compliance to RFC2616**
If a browser sends the header
Accept-Encoding: gzip;q=0, deflate
Which should be interpreted as : "I don't support gzip encoding, but I prefer deflate", Wikka will understand "The browser supports gzip-encoding", as it just searches for the text gzip in $_SERVER['HTTP_ACCEPT_ENCODING']. An example I use to treat it correctly is :
%%(php) function ParseHeaderLine($hl, $token=null)
{
$ar_hl = explode(',', $hl);
foreach ($ar_hl as $dotmg_idx => $val)
{
if (preg_match('/^\s*(.*?);\s*q\s*=\s*([0-9\.]*)/i', $val, $match))
{
$res[strtolower($match[1])] = doubleval($match[2]);
}
else
{
$res[strtolower($val)] = 1;
}
}
if ($token) return(isset($res[$token]) && ($res[$token] > 0)); #if $token is set, we return true or false
return ($res); # else we return the header parsed.
}%%
and
%%(php) if ($this->ParseHeaderLine($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ...%%
Note : This function might be useful to deal also with Accept-Language, when Wikka will be made effectively multilingual.


Revision [12539]

Edited on 2006-01-05 18:25:45 by DarTar [page cleanup - moving migrated issues to top]
Additions:
[[Ticket:87]]
Deletions:
Comments are being previewed even if users do not have access. A simple check needs to be added. -- JsnX
if ($this->HasAccess("comment"))
~& Recent Comments: Here is an implementation of the above suggestion. NickDamoulakis
if ($comments = $this->LoadRecentComments())
{
$curday = "";
$allComments = 0; // This tracks the total number of comments found
$accessibleComments = 0; // and this one only those that we can look at
foreach ($comments as $comment)
{
$allComments++;
if ($this->HasAccess($comment))
{
$accessibleComments++;
// day header
list($day, $time) = explode(" ", $comment["time"]);
if ($day != $curday)
{
$dateformatted = date("D, d M Y", strtotime($day));
if ($curday) print("<br />\n");
print("<strong>$dateformatted:</strong><br />\n");
$curday = $day;
}
$timeformatted = date("H:i T", strtotime($comment["time"]));
$comment_preview = str_replace("<br />", "", $comment["comment"]);
$comment_preview = substr($comment_preview, 0, 125);
if (strlen($comment["comment"]) > 120) $comment_preview = $comment_preview.".... ";
// print entry
print(" ($timeformatted) <a href=\"".$this->href("", $comment["page_tag"], "show_comments=1")."#comment_".$comment["id"]."\">".$comment["page_tag"]."</a> . . . . ".$this->Format($comment["user"])."<br />\n <em>$comment_preview</em><br />\n");
}
}
// If we are only showing a portion of the comments, tell the user so.
if ($accessibleComments != $allComments)
{
Echo "<br><hr>You are only shown comments that you have access to.";
}
else
{
print("<em>No recent comments.</em>");
~& Recently Commented: Here is an implementation of the above suggestion. NickDamoulakis
if ($comments = $this->LoadRecentlyCommented())
{
$curday = "";
$allComments = 0; // This tracks the total number of comments found
$accessibleComments = 0; // and this one only those that we can look at
foreach ($comments as $comment)
{
$allComments++;
if ($this->HasAccess($comment))
{
$accessibleComments++;
// day header
list($day, $time) = explode(" ", $comment["time"]);
if ($day != $curday)
{
$dateformatted = date("D, d M Y", strtotime($day));
if ($curday) print("<br />\n");
print("<strong>$dateformatted:</strong><br />\n");
$curday = $day;
}
$timeformatted = date("H:i T", strtotime($comment["time"]));
$max_preview_length = 122;
$comment_preview = str_replace("<br />", "", $comment["comment"]);
if (strlen($comment_preview) > $max_preview_length) {
$comment_spillover_link = "<a href=\"".$this->href("", $comment["page_tag"], "show_comments=1")."#comment_".$comment["id"]."\" title=\"View comment\">[.... ]</a>";
$comment_preview = substr($comment_preview, 0, $max_preview_length).$comment_spillover_link;
}
$commentlink = "<a href=\"".$this->href("", $comment["page_tag"], "show_comments=1")."#comment_".$comment["id"]."\" title=\"View comment\">".$comment["page_tag"]."</a>";
$comment_by = $comment["user"];
if (!$this->LoadUser($comment_by)) $comment_by .= " (unregistered user)";
// print entry
print(" $commentlink, comment by $comment_by: <br />\n <em>$comment_preview</em><br />\n");
}
}
// If we are only showing a portion of the comments, tell the user so.
if ($accessibleComments != $allComments)
{
Echo "<br><hr>You are only shown comments that you have access to.";
}
else
{
print("<em>There are no recently commented pages.</em>");


Revision [12538]

Edited on 2006-01-05 18:10:19 by DarTar [page cleanup - moving migrated issues to top]
Additions:
[[Ticket:86]]
Deletions:
Results should be hidden or not shown if the user doesn't have read access to page IMHO. --PolVazo
~& In actions/textsearch.php you can fix it by changing the following;
~& %%(php)
if ($phrase = $_REQUEST["phrase"])
$phrase = stripslashes($phrase);
$results = $this->FullTextSearch($phrase);
print("<br />");
$total_results = count($results);
$match_str = $total_results <> 1 ? " matches" : " match";
print("Search results: <strong>".$total_results.$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
if ($results)
foreach ($results as $i => $page)
print(($i+1).". ".$this->Link($page["tag"])."<br />\n");
$phrase = urlencode($phrase);
print("<br />Not sure which page to choose?<br />Try the <a href=\"".$this->href("", "TextSearchExpanded", "phrase=$phrase")."\">Expanded Text Search</a> which shows surrounding text.");
~& into
~& %%(php)
if ($phrase = $_REQUEST["phrase"])
$phrase = preg_quote($this->htmlspecialchars_ent(stripslashes($phrase)), "/");
$results = $this->FullTextSearch($phrase);
$result_page_list = '';
$total_results = 0;
print("<br />");
if ($results)
foreach ($results as $i => $page)
if ($this->HasAccess("read",$page["tag"]))
$result_page_list .= ($i+1).". ".$this->Link($page["tag"])."<br />\n";
$total_results += 1;
$phrase = urlencode($phrase);
$match_str = $total_results <> 1 ? " matches" : " match";
print("Search results: <strong>".$total_results.$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
if ($total_results > 0)
print($result_page_list);
print("<br />Not sure which page to choose?<br />Try the <a href=\"".$this->href("", "TextSearchExpanded", "phrase=$phrase")."\">Expanded Text Search</a> which shows surrounding text.");
~& Similarly, in actions/textsearchexpanded.php you can fix it by changing the following:
~& %%(php)
if (isset($_REQUEST["phrase"]) && $phrase = $_REQUEST["phrase"])
$phrase = stripslashes($phrase);
print("<br />");
$results = $this->FullTextSearch($phrase);
$match_str = count($results) <> 1 ? " matches" : " match";
print("Search results: <strong>".count($results).$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
$phrase = str_replace("\"", "", $phrase);
if ($results)
{
print "<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\">";
$STORE_FORMATING_AS_TEXT = 1;
foreach ($results as $i => $page)
{
//print(($i+1).". ".$this->Link($page["tag"])."<br />\n");
//print implode($this->LoadPage($page["tag"]));
//$matchString = preg_match("/(.{0,40}$phrase.{0,40})/",implode($this->LoadPage($page['tag'])));
/* display portion of the matching body and highlight
the search term */
preg_match("/(.{0,120}$phrase.{0,120})/is",$page['body'],$matchString);
$text = $this->htmlspecialchars_ent($matchString[0]);
// include("formatters/wakka.php");
$highlightMatch = preg_replace("/($phrase)/i","<font color=\"green\"><b>$1</b></font>",$text,-1);
$matchText = "<font color=\"gray\" size=\"-1\">...</font>$highlightMatch<font color=\"gray\" size=\"-1\">...</font>";
print "
<tr>
<td valign=\"top\" align=\"right\">
<!-- result number -->
<table>
<tr>
<td valign=\"top\" align=\"left\" bgcolor=\"#DDDDDD\">
<font color=\"white\" size=\"-3\">
".($i+1)."
</font>
</td>
</tr>
</table>
</td>
<!-- link -->
<td valign=\"top\">
".$this->Link($page["tag"])."
</td>
<!-- date of last update -->
<td valign=\"top\" align=\"right\">
<font color=\"gray\" size=\"-3\">
$page[time]
</font>
</td>
</tr>
<tr>
<td>

</td>
<td colspan=\"2\">
$matchText
</td>
</tr>
<tr>
<td>

</td>
</tr>
";
}
print "</table>";
~& into
~& %%(php)
if (isset($_REQUEST["phrase"]) && $phrase = $_REQUEST["phrase"])
$phrase = preg_quote($this->htmlspecialchars_ent(stripslashes($phrase)), "/");
print("<br />");
$results = $this->FullTextSearch($phrase);
$phrase = str_replace("\"", "", $phrase);
$result_page_list = '';
$total_results = 0;
if ($results)
print "<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\">";
$STORE_FORMATING_AS_TEXT = 1;
foreach ($results as $i => $page)
if ($this->HasAccess("read",$page["tag"]))
preg_match("/(.{0,120}$phrase.{0,120})/is",$page['body'],$matchString);
$text = $this->htmlspecialchars_ent($matchString[0]);
$highlightMatch = preg_replace("/($phrase)/i","<font color=\"green\"><b>$1</b></font>",$text,-1);
$matchText = "<font color=\"gray\" size=\"-1\">...</font>$highlightMatch<font color=\"gray\" size=\"-1\">...</font>";
$total_results += 1;
$result_page_list .= "
<tr>
<td valign=\"top\" align=\"right\">
<!-- result number -->
<table>
<tr>
<td valign=\"top\" align=\"left\" bgcolor=\"#DDDDDD\">
<font color=\"white\" size=\"-3\">
".($i+1)."
</font>
</td>
</tr>
</table>
</td>
<td valign=\"top\">
<!-- link -->
".$this->Link($page["tag"])."
</td>
<td valign=\"top\" align=\"right\">
<!-- date of last update -->
<font color=\"gray\" size=\"-3\">
$page[time]
</font>
</td>
</tr>
<tr>
<td> </td>
<td colspan=\"2\">$matchText</td>
</tr>
<tr>
<td> </td>
</tr>
";
$match_str = $total_results <> 1 ? " matches" : " match";
print("Search results: <strong>".$total_results.$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
if ($total_results > 0)
print($result_page_list);
print("</table>");
~& This fix also includes another fix on this page by NilsLindenberg in the "Bug in Textsearch (expanded)" section. --QualousHere


Revision [12537]

Edited on 2006-01-05 17:54:56 by DarTar [page cleanup - moving migrated issues to top]
Additions:
[[Ticket:85]]
[[Ticket:85]]
[[Ticket:85]]
Deletions:
$body = preg_replace("/\n[ ]{4}/", "\n\t", $body); # @@@ FIXME: misses first line and multiple sets of four spaces - JW 2005-01-16
Working fix (this might not be the best code doing the job...)
// replace each 4 spaces at beginning of a line with a tabwi
$body = preg_replace("/^[ ]{4}/","\t", $body);
$body = preg_replace("/\n[ ]{4}/","\n\t", $body);
while (preg_match("/\t[ ]{4}/",$body)) {
$body = preg_replace("/\t[ ]{4}/","\t\t", $body);
-- TimoK
~&The line with the "incomplete" indents-handling code actually occurs twice in ##handlers/page/edit.php##; while I haven't addressed that duplication yet (the handler code really needs to be restructured), I came up with the following (a little more robust) code to fix this particular bug: %%(php) # JW FIXED 2005-07-12
$pattern = '/^(\t*) {4}/m'; # m modifier: match ^ at start of line *and* at start of string;
$replace = "$1\t";
while (preg_match($pattern,$body))
$body = preg_replace($pattern,$replace,$body);
# @@@ NOTE: This could be easily extended to also change a '~' into a tab. But should we? '~' is easy to type and edit
%%---Implemented as BETA on this site now. --JavaWoman
(copied from the sandbox --NilsLindenberg)
not support 2byte language in the Code formatters!!!!
%%(c)
// 한글이 깨지겠지
// 진짜 깨지네.. 흑흑.. 에디터창에서 깨지는 것도 열받는데..
...
A page contains unicode characters looks OK when viewed but displays ""''&#*****;''"" while edited in WikiEdit
Simplified Chinese Test:
中文是一种美丽的语言,除了具有音节上的美感,同样拥有视觉上的美感
In 1.1.5.3, I solved this problem by changed some line in ./handlers/page/edit.php
#from
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$body."</textarea><br />\n"
#to
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$this->htmlspecialchars_ent($body)."</textarea><br />\n"
Wikka is wonderful! ZhuangYuyao
~&This workaround you outlined will work as well in Wikka 1.1.6.0. A real solution wil take some more investigation though, so we were unable to fix this for the current release. This is now under investigation. --JavaWoman


Revision [12536]

Edited on 2006-01-05 16:11:34 by DarTar [page cleanup: moving migrated items to top]
Additions:
[[Ticket:84]]
Deletions:
//reported by someone named DarTar ;) on my userpage. --NilsLindenberg//
Note for ourselves: if you look at the commentinfo by dialup-4.227.116.20 you'll see that we have a small formatter bug (Dial1 is parsed as a missing page): CamelCase formatting should not be applied within commentinfo's.
''part of a users host-name is formatted as a wikilink''


Revision [12535]

Edited on 2006-01-05 16:08:09 by DarTar [page cleanup: moving migrated items to top]
Additions:
[[Ticket:83]]
Deletions:
(//copied from SandBox - JavaWoman//)
Safari crashes when I use a formatting button. (DarTar has confirmed this.)
It looks like either Safari has a bug in their JavaScript implementation, or WikiEdit's JavaScript isn't (sufficiently) cross-browser, or both. While the browser shouldn't crash on encountering JavaScript it cannot handle, we certainly need an edit toolbar that's more cross-browser (it doesn't appear at all in Opera 7.2x on Windows). --JavaWoman


Revision [12534]

Edited on 2006-01-05 16:04:27 by DarTar [page cleanup: moving migrated items to top]
Additions:
[[Ticket:81]]
[[Ticket:81]]
[[Ticket:81]]
Deletions:
//moved from StayingLoggedIn. NilsLindenberg//
if you don't log out, then with a simple
echo "<PRE>_REQUEST =";print_r($_REQUEST)."</PRE>";
you can see the user's username and pass (md5'ed of course)
_REQUEST =Array
[skin] => xxxxxx.css
[PHPSESSID] => xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[wikka_user_name] => xxxxxx
[wikka_pass] => xxxxxxxxxxxxxxxxxxxxxxxxxx
I think this is called a session leakage, anyone knows of a solution to this.
Perhaps a solution to this would be changing the name of the session that a particular wikka installation uses,
The name could be a random number/word passed from md5 this way its unique to each wikka installation.
Also changing the path that the session data are stored maybe helpful. (I have seen discussions on this I think on php.net session_name() or session_start() )
I don't really know the implications of this bug are (maybe its not even a bug), perhaps people can see the session data on shared hosts and that is really what concerns me.
-GiorgosKontopoulos (look also at "Multiple wikis ... Login security hole?" later down the page)
__Update__
There are more places this bug makes itself known.
If one has accounts in two different Wikka wiki's sites then changing the skin in one will affect the active skin in the other
Or if you log in/log out in one you find yourself logged in or logged out in the other.
tested it using
1) 2 Wikka engines, same server, using FF1.0.6, had same userName and pass on both
behaves as stated above.
2) 2 Wikka engines, same server, using FF1.0.6, using userA on the one installation
the other installation thinks I am userA but does not actually let me see pages only allowed to userA.
3) jsnx.wikka.com and my test installation using FF1.0.6, had same userName and pass on both
it runs ok it seems.
Not a terrible bug but may have other implications still hidden.
-GiorgosKontopoulos Oct. 27, 02:09:21 UTC
Not sure if this is truly a bug, but I have a number of wikka installations,. each in different (peer) directories on a server, each using different DB's. Now, each has a user named SeanOttey, and if I go log in at site A, then go to site B, I am shown as logged in, but with the other site's user info (i.e. email, password, settings). Potentially, this might create accessibility that an admin did not intend, yes? thanks! Sean.
Okay. Say that I've installed multiple seperate installations of wikka on one host. If I do a login on wikka A, I can also
reach the pages of wikka B, whereas wikka B has an authentication table where the user account of wikka A does not exist!
My guess is that this behaviour occurs because the login cookies are set with path root. And as long the login cookies exist
Wikka doesn't care about authentication anymore??
-- JeroenJansen
~&Same problem. Is it possible to include in wikka.config.php a line in which you specify the default cookie prefix? I guess this could solve the problem. --YanB
~~&Same problem for me as well. I've modified wikka.php to use different session names (add: session_name($wakkaConfig["wakka_name"]); just above the session_start(); ) and different cookies ("wikka_user_name@".$this->config["wakka_name"] and "wikka_pass@".$this->config["wakka_name"]) as my 2 wikkas do have have different wakka_names. Seems to behave as expected now. --OlivierPerron


Revision [12530]

Edited on 2006-01-05 15:32:48 by DarTar [page cleanup: moving migrated items to top and deleting bug reports already copied]
Additions:
[[Ticket:49]]
==== Bugs still to be checked/migrated====
Deletions:
==== Bugs to be checked/migrated====
The list of Wantedpages may be handy, but I just found the list is not sorted alphabetically, making it hard to scan. That's a "UI bug". The list should be sorted, at least - and preferably split up by starting letters, as in PageIndex (when all pages are shown). --JavaWoman
The installation succeed but the wiki doesn't work(connection pb if the db password contains one or more dollars symbols '$'.
The error occur at the creation of the wakka object :
"The wiki is currently unavailable. Error : Unable to connect to the Mysql database"
~& Did you tried to escape them? For example "john$doe" replaced by "john\$doe". AFAIK, it isn't a wikka bug but a php engine's side effect. All string beginning with $ are considered as variables and are interpreted as is. -- PivWan
~~&Solution is to simply use single quotes instead of double quotes so $ is not interpreted as the start of a variable name; involves some changes in the installer. Will likely appear in 1.1.6.1 --JavaWoman


Revision [12529]

Edited on 2006-01-05 15:26:39 by DarTar [page cleanup]
Additions:
[[Ticket:17]]
Deletions:
I tried an expanded Text-Search after [[http://wikka.jsnx.com/TextSearchExpanded?phrase=%2Bparameter+%2Blink +parameter +link]] and got the following error:
"Warning: Compilation failed: nothing to repeat at offset 1 in /.../actions/textsearchexpanded.php on line 33"
for every page.
--NilsLindenberg
~&In my recent RE exploits I have found that a warning of this type comes up when a regular expression isn't quite correct (though not every attempt to match may bring up the warning); haven't investigated further in textsearchexpanded.php though. --JavaWoman
~&Php has a function : preg_quote that may help us. Or try this solution : DotMGTextSearchExpanded


Revision [12528]

Edited on 2006-01-05 15:24:22 by DarTar [page cleanup]
Deletions:
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...
~&Possible clue:
~&I just stumbled over the fact that the little list of "Useful pages" at the end of the default (installation-generated) ""HomePage"" had incorrect coding: The last list item (li) was not terminated, nor was the list itself (no closing ul tag). It took me a bit of trial and error to reproduce this - but have a look at my test code at the end of SandBox (now). Originally I thought that any list at the end of a page would be unterminated, but that turned out not to be the case. Then I hit on something else: the last list element on that default ""HomePage"" (not the one here) ands with a period. My test version on SandBox now also has the last element ending in a period ... and if you look at the (HTML) page source, you'll see it is indeed an unterminated list. Somehow that ending period (maybe in combination with end-of-page?) causes the Formatter never to close the list; take that ending period away, and it works normally. I tried a few variants, to check whether it might be an odd-even problem, but no: whether the number of list items is odd or even, if the last one ends in a period, the list isn't terminated.
~&No difference whether it's anordered (ol) or unordered (ul) list, the formatter behaves the same way.
~&And, BTW, if you look at the preview when editing, the HTML source of the **preview** actually contains a lot of Wiki code that shouldn't be there!
~&I haven't dug in the Formatter yet to find the cause or whether end-of-page makes a difference...
~~&This is indeed an "end of page" problem: teh formatter has some code to close tags inadvertently left open, but does not do this for lists and indent (nor even fro *all* open tags). Fix coded and tested - this will be in 1.1.6.1. --JavaWoman


Revision [12527]

Edited on 2006-01-05 15:21:04 by DarTar [page cleanup]
Additions:
===Valid Email Addresses===
[[Ticket:80]]
Deletions:
===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


Revision [12526]

Edited on 2006-01-05 15:17:38 by DarTar [page cleanup]
Additions:
[[Ticket:47]]
Deletions:
On 1.1.6.0 a registered user can modify his or her settings and store an **empty email address**. The engine does not warn the user and accepts an empty value. This bug should be fixed or at least the behavior of UserSettings should be made consistent with the registration requirements (if an email is required, it is required also //after// registering). Note that this might break (beta-)actions based on user email, such as FeedbackActionUpgrade (to be checked)-- DarTar


Revision [12525]

Edited on 2006-01-05 15:15:04 by DarTar [page cleanup]
Additions:
==== Bugs reported on the tracker ====
[[Ticket:46]]
[[Ticket:13]]
[[Ticket:79]]
==== Bugs to be checked/migrated====
// replace each 4 spaces at beginning of a line with a tabwi
Deletions:
~& This bug has already been reported and has been fixed in the development version. -- DarTar
===Release Including All Patches===
~& Brendon, it's true that Wikka development has slowed down the last months. There is no date yet for the next release, but things should start to move faster: we have recently set up some [[http://wush.net/trac/wikka tools]] to enable a better tracking of new features/bugfixes. This should make the release procedure faster and more frequent. In the meantime, you might want to check out [[http://dartar.free.fr/code this]]. -- DarTar
// replace each 4 spaces at beginning of a line with a tab
// indented text
elseif (preg_match("/\n([\t~]+)(-|&|([0-9a-zA-ZÄÖÜßäöü]+)\))?(\n|$)/s", $thing, $matches))
This simply doesn't match indents on the first line.
I know there is a problem in the edit handler as well with indents, but even if that is fixed (working solution for that problem at WikkaBugsResolved) we still will have the problem here. -- TimoK
~&Fixed and implemented as part of the beta ImprovedFormatter on this site; see ""<a href="ImprovedFormatter#hn_Better_handling_of_nested_lists_and_indents">Better handling of nested lists and indents</a>"" on that page for the details. --JavaWoman
I just started using this program and I love it ! Its exactly what I've been looking for. However what I want is a Wikki where only the administrator can register new users. This seems like such an obvious feature that I am amazed I cant figure out how to do it !
What am I missing ?
--DavidLee
--Sorta Fixed--
Ok I figured this out ... mostly. Feel free to delete this section if its seems obvious to everyone ! (It wasnt to me)
I changed my default ACL for write and comment to "!*" ... but left read as "*".
People can still register themselves but it doesnt do them much good as they cant create pages.
--DavidLee
Hi DavidLee!
No, we don't have an ""{{adduser}}"" yet. If you don't want other people to register, try out the solution from UserRegistration which allows you to stop registration (and you could use phpmyadmin to add users directly to the database). The solution makes it possible to allow registration only with a password, which can be set in the config. See UserRegistration for more details. A division of registration/log-in and usersettings into different actions is planned but won't come in the next release. --NilsLindenberg
//Thanks to MrTrick for pointing out this problem//
It is possible to upload files with a space in the file name. However, when trying to download such a file things don't work as expected: in Mozilla browsers (Mozilla, Firefox, etc.) the suggested filename for the download is truncated at the first space.
Two possible solutions:
~1) Prevent that file names are //stored// with spaces in the name; simply replacing all spaces with underscores would do the trick and keep the file name recognizable. This has the advantage that no assumptions are being made about the server OS //or// the user's OS as to whether spaces in file names are valid.
~2) Mozilla seems to pick up the suggested file name from the Content-Disposition header. (raw)urlencoding the file name here works, but then displays the name with the encoding; enclosing the file name in (double) quotes works better, showing the full file name with spaces. This has the advantage that the original file name is preserved - //provided// both the server OS and the downloading user's OS can handle such file names.---
Take your pick ;-) -- JavaWoman


Revision [12521]

Edited on 2006-01-05 10:18:25 by JavaWoman [minor (layout)]
Additions:
[[Ticket:3]]
~& This bug has already been reported and has been fixed in the development version. -- DarTar
Deletions:
~& This bug has already been reported and has been fixed in the development version - [[Ticket:3]]. -- DarTar
++
++


Revision [12520]

Edited on 2006-01-05 10:11:01 by JavaWoman [comment on remote/local use]
Additions:
~~~&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
Deletions:
::c::


Revision [12517]

Edited on 2006-01-05 09:59:13 by JavaWoman [edit reporting instructions while migration is still taking place]
Additions:
""<div style="padding:5px; background-color:#FEE; border:1px solid #EDD"><h5>New Wikka Tracker available</h5><p>We are happy to announce that Wikka has just opened a dedicated <a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a>. We are currently migrating open issues, bugs and feature requests from this site to the new server but this migration isn't complete yet.</p>
<p>Meanwhile, if you have something to report:<br/>
<strong>First</strong> check if your issue is already being discussed on this page:</p><ul>
<li>If so: check if it has a link to a tracker ID:<ul>
<li>If so: <strong>follow that link</strong> and add your comment there</li>
<li>If not: add your comment to the issue <strong>on this page</strong></li></ul></li>
<li>If not: please use the <strong><a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a></strong> to report your <strong>new</strong> bug or issue.</li></ul>
<p>Thanks for your understanding.</p></div>""
Deletions:
""<div style="width:46%; float:center; padding:5px; background-color:#FEE; border:1px solid #EDD"><h5>New Wikka Tracker available</h5><p>We are happy to announce that Wikka has just opened a dedicated <a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a>. We are currently migrating open issues, bugs and feature requests from this site to the new server. Should you need to report new bugs/issues, you need to use the new tracker. Thanks for your understanding.</p></div>""


Revision [12502]

Edited on 2006-01-04 13:58:54 by NilsLindenberg [copied 4 bugs to tracker]
Additions:
[[Ticket:74]]
[[Ticket:75]]
[[Ticket:76]]
[[Ticket:77]]
Deletions:
When I write a date in DD.MM.YYYY format **and** the date string is right at the beginning of a line, trying to mark the complete string and click the wikiedit buttons for bold (italic, etc.) text results in an incorrect markup:
31.12.2005 <- does not work (case 1)
Filler text 31.12.2005 <- does work (case 2)
Here is the wikiedit output for case 1.
How it is:
%%31.**12.2005**%%
How it should be:
%%**31.12.2005**%%
Again, it works when the date string is not at the very beginning of a new line.
If you try to access the history for the SuggestionBox you'll get an server-error (500). Perhaps related to the size of the history? --NilsLindenberg
~&A rough estimate: there have been between 425 and 450 revisions of that page; the current page **source** size is 92316 bytes; given that the page tends to grow but is sometimes "weeded" when suggestions are implemented or moved to a separate page, the total 'history' **source** size could be something like 12.5MB. Even is it's as "small" as 5MB I wouldn't be surprised to have it break //somehow// (DB access, PHP timeout...).---Maybe we should just give up on 'history' and support only revisions? Where or how something like this breaks is hard to tell, it could be entirely dependent on a specific installation. --JavaWoman
//nearly missed this - copied from MiKolar - JW//
WikkaWiki version 1.1.6.0 login/register actions returns often confusing error messages
(e.g., if a registered user makes an error in his WikiName, he gets an error message
"You must specify an email address", which may be rather confusing to a properly registered
user). Here is my attempt to straighten this up (...) http://www.world-wide-democracy.net/members/MiUploads/usersettings.php.gz
--MiKolar
//copied from the #wikka channel - JW//
<SamuelDr> for the next important guy/gal who'll read this
<SamuelDr> the accesskey="d" on the comments is a little bit useless
<SamuelDr> when there are more than 1 comment deletable on a page
<SamuelDr> I think it wouldn't work really well ;)


Revision [12492]

Edited on 2006-01-03 14:51:21 by NilsLindenberg [removing text of bugs for which tickets exist]
Additions:
""<div style="width:46%; float:center; padding:5px; background-color:#FEE; border:1px solid #EDD"><h5>New Wikka Tracker available</h5><p>We are happy to announce that Wikka has just opened a dedicated <a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a>. We are currently migrating open issues, bugs and feature requests from this site to the new server. Should you need to report new bugs/issues, you need to use the new tracker. Thanks for your understanding.</p></div>""
[[Ticket:41]]
++
++
[[Ticket:5]]
[[Ticket:9]]
(partly) [[Ticket:3]]
Deletions:
""<div style="width:46%; float:center; padding:5px; background-color:#FEE; border:1px solid #EDD"><h5>New Wikka Tracker available</h5><p>We are happy to announce that Wikka has just opened a dedicated <a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a>. We are currently migrating open issues, bugs and feature requests from this site to the new server. Should you need to report new bugs/issues, you are invited to use the new tracker. Thanks for your understanding.</p></div>""
~-before posting new bugs on this page, please make sure they have not been already discussed: {{search}}
If you think you've found a new bug or have some other issue, please post it here - //with// any solution you may have found. (WikkaBugsResolved is only for bugfixes that have made it into a release or to-be-released code already.)
**Please post recently discovered issues on the //top// of this page (just below this note); don't forget to add a ##""===heading===""## as a condensed description.**
workaround : add at the top of show.php $user=$this->GetUser();
before
<div class="page" <?php echo (!$user || ($user["doubleclickedit"] == 'Y')) && ($this->GetMethod() == "show") ? "ondblclick=\"document.location='".$this->href("edit")."';\" " : "" ?>>
after
<div class="page" <?php $user=$this->GetUser(); echo (!$user || ($user["doubleclickedit"] == 'Y')) && ($this->GetMethod() == "show") ? "ondblclick=\"document.location='".$this->href("edit")."';\" " : "" ?>>
I have found this program to be very nice, but it requires a lot of searching this wiki and hacking to get a current version. When can we expect a nicely packaged release?
In arguement for this release, it would speed up community adoption, offer some stability to the mindset of users out there, as well as other benefits.
The SF.net page is also not active give others a negative impression.
Hi! I've found that in Konqueror the PasswordForgotten-script doesnt work! It's because in ##actions/emailpassword.php## on lines 41 and 51
%%(php)$form = "<form name=\"getwikiname\" action=\"\" method=\"post\">";%%
the action-attribute of the <form>-tag is missing. It works without any problems in any browser I've checked with (actually Firefox 1.0.7 and Konqueror 3.4.1) when I change both lines to
%%(php)$form = "<form name=\"getwikiname\" action=\"".$this->href()."\" method=\"post\">";%%
Found this bug in Wikka 1.1.6.0 and don't see any reason why not to change this for better browser-compatibility...
Regards, IceT
===blog.php===
//Moved to WikkaBlog2 since it's user-contributed code]//
As DotMG has pointed out, the input for this two actions isn't validated, making it a security-hole.
~&You can fix it by changing the line
$phrase = stripslashes($phrase);
into
You have to change both files (textsearch and textsearchexpanded). --NilsLindenberg
I noticed: Turning off DoubleClick-editing does not work (double-clicks still go to edit-window) in IE 6.0 or Firefox 1.0.
Keep up the good work!
Cheers, MarkHissinkMuller
~&Yes, I noticed the same thing. This is a bug as of 1.1.6.0. --RyanKnoll
~~&Heres the fix:
~~&add as **first** line in handlers/page/show.php:
~~&%%(php;1)
<?php $user = $this->GetUser(); ?>
~~&and change the second line to:
~~&%%(php;2)
<div class="page" <?php echo ((!$user || ($user["doubleclickedit"] == 'Y')) && $this->GetMethod
~~&--NilsLindenberg


Revision [12477]

Edited on 2005-12-29 13:02:55 by JavaWoman [repairing borked Unicode characters (DarTar, use another browser :))]
Additions:
Looking at the generated code, an empty line within a multi-line comment (with line numbers) results in this code: %%(html4strict)<li><div class="de1"><span class="coMULTI"></span></div></li>%%---while an empty line elsewhere results in %%(html4strict)<li><div class="de1"> </div></li>%%---Note the ## ## in the latter case (which gives the div actual content) while the empty multi-comment line has nothing but an **empty** span, and no actual content.


<td> </td>
<td> </td>
print(" ($timeformatted) <a href=\"".$this->href("", $comment["page_tag"], "show_comments=1")."#comment_".$comment["id"]."\">".$comment["page_tag"]."</a> . . . . ".$this->Format($comment["user"])."<br />\n <em>$comment_preview</em><br />\n");
print(" $commentlink, comment by $comment_by: <br />\n <em>$comment_preview</em><br />\n");
// 한글이 깨지겠지
// 진짜 깨지네.. 흑흑.. 에디터창에서 깨지는 것도 열받는데..
中文是一种美丽的语言,除了具有音节上的美感,同样拥有视觉上的美感
Deletions:
Looking at the generated code, an empty line within a multi-line comment (with line numbers) results in this code: %%(html4strict)<li><div class="de1"><span class="coMULTI"></span></div></li>%%---while an empty line elsewhere results in %%(html4strict)<li><div class="de1"> </div></li>%%---Note the ## ## in the latter case (which gives the div actual content) while the empty multi-comment line has nothing but an **empty** span, and no actual content.
 
 
<td> </td>
<td> </td>
print("   ($timeformatted) <a href=\"".$this->href("", $comment["page_tag"], "show_comments=1")."#comment_".$comment["id"]."\">".$comment["page_tag"]."</a> . . . . ".$this->Format($comment["user"])."<br />\n       <em>$comment_preview</em><br />\n");
print("    $commentlink, comment by $comment_by: <br />\n         <em>$comment_preview</em><br />\n");
// ??? ????
// ?? ???.. ??.. ?????? ??? ?? ????..
????????????????????????????????


Revision [12476]

Edited on 2005-12-29 11:45:37 by DarTar [reverting deleted items + replying on double-click bug]
Additions:
~& This bug has already been reported and has been fixed in the development version - [[Ticket:3]]. -- DarTar
~& Brendon, it's true that Wikka development has slowed down the last months. There is no date yet for the next release, but things should start to move faster: we have recently set up some [[http://wush.net/trac/wikka tools]] to enable a better tracking of new features/bugfixes. This should make the release procedure faster and more frequent. In the meantime, you might want to check out [[http://dartar.free.fr/code this]]. -- DarTar
===PasswordForgotten / emailpassword problem with Konqueror (Form-Action missing)===
Hi! I've found that in Konqueror the PasswordForgotten-script doesnt work! It's because in ##actions/emailpassword.php## on lines 41 and 51
%%(php)$form = "<form name=\"getwikiname\" action=\"\" method=\"post\">";%%
the action-attribute of the <form>-tag is missing. It works without any problems in any browser I've checked with (actually Firefox 1.0.7 and Konqueror 3.4.1) when I change both lines to
%%(php)$form = "<form name=\"getwikiname\" action=\"".$this->href()."\" method=\"post\">";%%
Found this bug in Wikka 1.1.6.0 and don't see any reason why not to change this for better browser-compatibility...
Regards, IceT
===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...
===Retrieving user-information (Session Leakage)===
//moved from StayingLoggedIn. NilsLindenberg//
if you don't log out, then with a simple
echo "<PRE>_REQUEST =";print_r($_REQUEST)."</PRE>";
you can see the user's username and pass (md5'ed of course)
_REQUEST =Array
(
[skin] => xxxxxx.css
[PHPSESSID] => xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[wikka_user_name] => xxxxxx
[wikka_pass] => xxxxxxxxxxxxxxxxxxxxxxxxxx
)
I think this is called a session leakage, anyone knows of a solution to this.
Perhaps a solution to this would be changing the name of the session that a particular wikka installation uses,
The name could be a random number/word passed from md5 this way its unique to each wikka installation.
Also changing the path that the session data are stored maybe helpful. (I have seen discussions on this I think on php.net session_name() or session_start() )
I don't really know the implications of this bug are (maybe its not even a bug), perhaps people can see the session data on shared hosts and that is really what concerns me.
-GiorgosKontopoulos (look also at "Multiple wikis ... Login security hole?" later down the page)
__Update__
There are more places this bug makes itself known.
If one has accounts in two different Wikka wiki's sites then changing the skin in one will affect the active skin in the other
Or if you log in/log out in one you find yourself logged in or logged out in the other.
tested it using
1) 2 Wikka engines, same server, using FF1.0.6, had same userName and pass on both
behaves as stated above.
2) 2 Wikka engines, same server, using FF1.0.6, using userA on the one installation
the other installation thinks I am userA but does not actually let me see pages only allowed to userA.
3) jsnx.wikka.com and my test installation using FF1.0.6, had same userName and pass on both
it runs ok it seems.
Not a terrible bug but may have other implications still hidden.
-GiorgosKontopoulos Oct. 27, 02:09:21 UTC
===Reuse of Username when multiple wikkas on single server===
Not sure if this is truly a bug, but I have a number of wikka installations,. each in different (peer) directories on a server, each using different DB's. Now, each has a user named SeanOttey, and if I go log in at site A, then go to site B, I am shown as logged in, but with the other site's user info (i.e. email, password, settings). Potentially, this might create accessibility that an admin did not intend, yes? thanks! Sean.
===Wikiedit: Link to the Formatting-rules (using IIS and not using mod-rewrite)===
from [[http://arek.c-consulting.co.id/ivan/wikka/wikka.php?wakka=WikiEditHack IvanLaninWiki]]: (see there for his solution)
//I don't use rewrite_mode since I'm using IIS as server, and I also put value for base_url for my wikka. Then I notice, by accident, that the Help button on WikiEdit? does not point to the right page (FormattingRules).//
===Wikka in Windows IIS===
When Wikka is installed in IIS5.0 occurs an error when using cookies and using the header(Location:)
http://br.php.net/manual/pt_BR/function.setcookie.php#51195
This error implies in not log in or out, because the page redirects before the cookie i created.
The problem can be solved using javascript to redirect the page, just change the following line in the code of Redirect function on wikka.php:
%%(php)header("Location: ".$url);%%
by this:
if (substr_count($_SERVER["SERVER_SOFTWARE"],"IIS") > 0) {
~& echo '<SCRIPT>window.location.href = "'.$url.'";</SCRIPT>';
} else {
~& header("Location: ".$url);
}
-- MarceloArmonas (sorry, i don't write in english)
===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
===Wikiedit: Problem with some date strings===
When I write a date in DD.MM.YYYY format **and** the date string is right at the beginning of a line, trying to mark the complete string and click the wikiedit buttons for bold (italic, etc.) text results in an incorrect markup:
31.12.2005 <- does not work (case 1)
Filler text 31.12.2005 <- does work (case 2)
Here is the wikiedit output for case 1.
How it is:
%%31.**12.2005**%%
How it should be:
%%**31.12.2005**%%
Again, it works when the date string is not at the very beginning of a new line.
===history bug===
If you try to access the history for the SuggestionBox you'll get an server-error (500). Perhaps related to the size of the history? --NilsLindenberg
~&A rough estimate: there have been between 425 and 450 revisions of that page; the current page **source** size is 92316 bytes; given that the page tends to grow but is sometimes "weeded" when suggestions are implemented or moved to a separate page, the total 'history' **source** size could be something like 12.5MB. Even is it's as "small" as 5MB I wouldn't be surprised to have it break //somehow// (DB access, PHP timeout...).---Maybe we should just give up on 'history' and support only revisions? Where or how something like this breaks is hard to tell, it could be entirely dependent on a specific installation. --JavaWoman
===blog.php===
//Moved to WikkaBlog2 since it's user-contributed code]//
===usersettings.php===
//nearly missed this - copied from MiKolar - JW//
WikkaWiki version 1.1.6.0 login/register actions returns often confusing error messages
(e.g., if a registered user makes an error in his WikiName, he gets an error message
"You must specify an email address", which may be rather confusing to a properly registered
user). Here is my attempt to straighten this up (...) http://www.world-wide-democracy.net/members/MiUploads/usersettings.php.gz
--MiKolar
===Accesskey on comments===
//copied from the #wikka channel - JW//
<SamuelDr> for the next important guy/gal who'll read this
<SamuelDr> the accesskey="d" on the comments is a little bit useless
<SamuelDr> when there are more than 1 comment deletable on a page
<SamuelDr> I think it wouldn't work really well ;)
===.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.
%%(apache)
### 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
===Formatter-bug in the comments===
//reported by someone named DarTar ;) on my userpage. --NilsLindenberg//
Note for ourselves: if you look at the commentinfo by dialup-4.227.116.20 you'll see that we have a small formatter bug (Dial1 is parsed as a missing page): CamelCase formatting should not be applied within commentinfo's.
''part of a users host-name is formatted as a wikilink''
=== Indenting not working properly in handlers/page/edit.php ===
$body = preg_replace("/\n[ ]{4}/", "\n\t", $body); # @@@ FIXME: misses first line and multiple sets of four spaces - JW 2005-01-16
Working fix (this might not be the best code doing the job...)
// replace each 4 spaces at beginning of a line with a tab
$body = preg_replace("/^[ ]{4}/","\t", $body);
$body = preg_replace("/\n[ ]{4}/","\n\t", $body);
while (preg_match("/\t[ ]{4}/",$body)) {
$body = preg_replace("/\t[ ]{4}/","\t\t", $body);
}
-- TimoK
~&The line with the "incomplete" indents-handling code actually occurs twice in ##handlers/page/edit.php##; while I haven't addressed that duplication yet (the handler code really needs to be restructured), I came up with the following (a little more robust) code to fix this particular bug: %%(php) # JW FIXED 2005-07-12
$pattern = '/^(\t*) {4}/m'; # m modifier: match ^ at start of line *and* at start of string;
$replace = "$1\t";
while (preg_match($pattern,$body))
{
$body = preg_replace($pattern,$replace,$body);
}
# @@@ NOTE: This could be easily extended to also change a '~' into a tab. But should we? '~' is easy to type and edit
%%---Implemented as BETA on this site now. --JavaWoman
===Wakka formatter: Indenting on first line===
// indented text
elseif (preg_match("/\n([\t~]+)(-|&|([0-9a-zA-ZÄÖÜßäöü]+)\))?(\n|$)/s", $thing, $matches))
This simply doesn't match indents on the first line.
I know there is a problem in the edit handler as well with indents, but even if that is fixed (working solution for that problem at WikkaBugsResolved) we still will have the problem here. -- TimoK
~&Fixed and implemented as part of the beta ImprovedFormatter on this site; see ""<a href="ImprovedFormatter#hn_Better_handling_of_nested_lists_and_indents">Better handling of nested lists and indents</a>"" on that page for the details. --JavaWoman
===No Registration Wikki===
I just started using this program and I love it ! Its exactly what I've been looking for. However what I want is a Wikki where only the administrator can register new users. This seems like such an obvious feature that I am amazed I cant figure out how to do it !
What am I missing ?
--DavidLee
--Sorta Fixed--
Ok I figured this out ... mostly. Feel free to delete this section if its seems obvious to everyone ! (It wasnt to me)
I changed my default ACL for write and comment to "!*" ... but left read as "*".
People can still register themselves but it doesnt do them much good as they cant create pages.
--DavidLee
Hi DavidLee!
No, we don't have an ""{{adduser}}"" yet. If you don't want other people to register, try out the solution from UserRegistration which allows you to stop registration (and you could use phpmyadmin to add users directly to the database). The solution makes it possible to allow registration only with a password, which can be set in the config. See UserRegistration for more details. A division of registration/log-in and usersettings into different actions is planned but won't come in the next release. --NilsLindenberg
===Code display problem===
The following combination of conditions triggers the problem:
~-multi-line comment (for instance a multi-line /*........*/ block in php)
~-empty lines within such a comment
~-line numbering turned on
When viewed in Mozilla or Firefox (at least - possibly others), the empty lines **overlap** the preceding lines, as can be seen by the line numbers.
Looking at the generated code, an empty line within a multi-line comment (with line numbers) results in this code: %%(html4strict)<li><div class="de1"><span class="coMULTI"></span></div></li>%%---while an empty line elsewhere results in %%(html4strict)<li><div class="de1"> </div></li>%%---Note the ## ## in the latter case (which gives the div actual content) while the empty multi-comment line has nothing but an **empty** span, and no actual content.
This seems to be a combination of a **GeSHi** bug (there should at least a ## ## be generated as content) combined with a **gecko** oddity (or bug?) that will render a number for an ordered list item but not give it a normal line height if the list item is empty.
**Workaround:** add some whitespace to the empty lines - a single tab works (a space probably will as well).
--JavaWoman
===Installer array_merge()===
//Mentioned in passing on #wikka by a user having actually other problems installing Wikka.//
Remember the array_merge() problem in wikka.php under PHP5? Solved in 1.1.6.0.
Guess what: the same problem still exists - but in the installer itself (##/setup/install.php## - line 7): the second argument is (again) not initialized so users get a warning stating "Argument #2 is not an array in /var/www/html/Wikka/setup/install.php on line 7".
We'd better solve it in the installer as well. --JavaWoman
===View Code Handler issue===
The view code handler does not display any message if the page does not exist. [[http://wikka.jsnx.com/NonExistantPage/showcode Example]] -- Rick
~& Technically, it isn't a bug: Wikka tries to display original data concerning the page. As it doesn't exists, Wikka displays nothing. It isn't a bug but a non-existent feature of Wikka, so I would put this comment in SuggestionBox instead of here. JavaWoman? DarTar? What do you think of it? -- PivWan
~~&Actually, I suggested Rick reported it here since I **do** consider it a bug. It is a **page** handler so the handler should look for a page; I think it should return //something// at least. IMO the best solution would be to generate a warning like "Page does not exist" when the page isn't found, or use the "do you want to create it?" we use when accessing a non-exstant page. --JavaWoman
~~~& Okay, hadn't the whole story. So, it's a bug :) -- PivWan
===Email deletion after registration===
On 1.1.6.0 a registered user can modify his or her settings and store an **empty email address**. The engine does not warn the user and accepts an empty value. This bug should be fixed or at least the behavior of UserSettings should be made consistent with the registration requirements (if an email is required, it is required also //after// registering). Note that this might break (beta-)actions based on user email, such as FeedbackActionUpgrade (to be checked)-- DarTar
===Purging of pages not always happening===
//reported by |Sam| on #wikka, writeup by me --JavaWoman//
Purging of pages doesn't always seem to happen. |Sam| had the page_purge_time set to 1 (which should purge page versions older than one day) but didn't see them being actually purge. Purging is done in the Maintenance() method in ##wikka.php## executed by the main Run() method. However, there is an extra condition here: %%(php)if(!($this->GetMicroTime()%3)) $this->Maintenance();%% I suspect this may cause the Maintenance() method not being executed. The intention of this (undocumented) condition isn't clear to me - should it really be there? --JavaWoman
~&That's correct. I'm not the author of this code, but the intention is clear to me. It's designed to be a performance improvement. Rather than call the Maintenance function for every single page view(!), it adds some randomness based on the remainder of GetMicroTime() divided by 3. For a busy site this could make a significant drop in MySQL queries. I have done some brief testing of this code and found that on average the Maintenance function was called about every four page views. For any site that has even moderate traffic, the Maintenance function will be triggered sufficiently. To answer your question, yes, this condition should be there. However, maybe there should be a configuration option that admins could tweak if they are obsessed and need certainty that pages get purged. -- JsnX
~~&Another way is to follow what (I think) PHP does for session cleanup. Set a threshold and test if a random number (between 0 and 1, inclusive of 0) is less than that threshold. If so, then do cleanup. Otherwise don't. The threshold is then a percentage chance that cleanup will happen on a particular request instead of hoping that the time falls just right. --JameSmith
===RSS feed action hangs or crashes browser if feed does not exist===
//reported by velkr0 on #wikka, analysis and writeup by me -- JavaWoman//
**Problem**: When the rss action is included in a page with a feed URL that happens not to exist (or not exist any more), the page "hangs"; once in this state, editing the page also isn't possible: the hang continues until the browser times out or is closed.
The obvious cause is that neither the ""{{rss}}"" action nor the underlying onyx-rss class checks for //existence// of the resource the feed URL refers to. The problem is already hard to detect when you are first including a feed in a page and maybe make a typo in the feed URL. But if your Wikka provides a page with one or more feeds, and a feed suddenly disappears (or is down momentarily) the result will be very annoying for your visitors.
**Solution**: Either the onyx-rss class or the rss action should check for the availability of the feed (for instance with a HEAD request) before actually trying to retrieve it. Since the class provides caching, the best option would be to handle it in the class (by subclassing the necessary method(s)). If a version of the feed still exists in the cache that version could be displayed (probably this happens automatically anyway), otherwise an error message should be generated instead of the feed output. --JavaWoman
Another problem with Onyx-RSS was just reported by |Sam| on #wikka: in spite of cacheing it seems quite slow, taking something like 2.5 seconds for rendering after retrieving a feed (compared to a normal page rendering time of 0.06 seconds). We should look at the efficiency (or not) of this class - maybe it's time to move to another one that's being actively maintained. --JavaWoman
===Safari and WikiEdit===
(//copied from SandBox - JavaWoman//)
Safari crashes when I use a formatting button. (DarTar has confirmed this.)
It looks like either Safari has a bug in their JavaScript implementation, or WikiEdit's JavaScript isn't (sufficiently) cross-browser, or both. While the browser shouldn't crash on encountering JavaScript it cannot handle, we certainly need an edit toolbar that's more cross-browser (it doesn't appear at all in Opera 7.2x on Windows). --JavaWoman
===WantedPages problem===
The list of Wantedpages may be handy, but I just found the list is not sorted alphabetically, making it hard to scan. That's a "UI bug". The list should be sorted, at least - and preferably split up by starting letters, as in PageIndex (when all pages are shown). --JavaWoman
===passwords containing $ aren't working===
The installation succeed but the wiki doesn't work(connection pb if the db password contains one or more dollars symbols '$'.
The error occur at the creation of the wakka object :
"The wiki is currently unavailable. Error : Unable to connect to the Mysql database"
~& Did you tried to escape them? For example "john$doe" replaced by "john\$doe". AFAIK, it isn't a wikka bug but a php engine's side effect. All string beginning with $ are considered as variables and are interpreted as is. -- PivWan
~~&Solution is to simply use single quotes instead of double quotes so $ is not interpreted as the start of a variable name; involves some changes in the installer. Will likely appear in 1.1.6.1 --JavaWoman
===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?
===Spaces in uploaded files===
//Thanks to MrTrick for pointing out this problem//
It is possible to upload files with a space in the file name. However, when trying to download such a file things don't work as expected: in Mozilla browsers (Mozilla, Firefox, etc.) the suggested filename for the download is truncated at the first space.
Two possible solutions:
~1) Prevent that file names are //stored// with spaces in the name; simply replacing all spaces with underscores would do the trick and keep the file name recognizable. This has the advantage that no assumptions are being made about the server OS //or// the user's OS as to whether spaces in file names are valid.
~2) Mozilla seems to pick up the suggested file name from the Content-Disposition header. (raw)urlencoding the file name here works, but then displays the name with the encoding; enclosing the file name in (double) quotes works better, showing the full file name with spaces. This has the advantage that the original file name is preserved - //provided// both the server OS and the downloading user's OS can handle such file names.---
Take your pick ;-) -- JavaWoman
===ACL Cancel===
If you edit the ACL on a page, click "Store ACLs", then edit the ACL and click "Cancel", it still reads "Access control lists updated.", even though the changes were canceled. This is due to the "Cancel" button causing the browser to navigate backwards, and a javascript popup. --BarkerJr
===Alzheimers for Wikka?===
This is not a bug specifically - it is really a potential implentation weakness, but if a user specifies a page purge time in wikka.config: "pages_purge_time" => "100" and if that page is not edited for a while, then when that page is edited, the last copy will be deleted, leaving no archived copies at all. I think purge pages should delete old pages, but there should always be a minimum number of old copies preserved, otherwise the wiki becomes highly vulnerable to a content deletion attack. Would it be better to remove this feature, or modify it? --IanAndolina
~&Instead of removing or modifying it (the configuration parameter, rather) we could refine it by introducing an extra parameter name something like "pages_keep" to set a maximum number of pages to be kept regardless (maximum, since it could be less if there are not that many versions in the first place). Setting one or the other to 0 could disable purging altogether. --JavaWoman
~~&Sounds good to me - can you think of an elegant way to modify the SQL query to only delete pages older than X that are also more than Xth on a list of revisions. I'm sure I can come up with something ugly ;) --IanAndolina
~~~&I'm good enough at SQL that I need the manual for that. ;-) As far as I can determine, you need two statements (semi pseudo code): 1) a ##select count(*) from pages where ...## to determine the current number of records; and 2) ##delete from pages where ... order by [timestamp] limit [$count - $pages_keep]##. You can't do a subquery in delete (yet) so the count must be a separate step (but it should be very fast). --JavaWoman
===Admin email at installation===
//reported in IRC while I was asleep, sorry - JW does have to sleep sometimes//
(Potential) User extremely frustrated when at installation he's entering a real and valid email address and the Installer rejects it with "Email appears incorrect". This is caused by the extremely brain-dead Javascript in the installer that accepts **nothing but lowercase letters** to appear before the '@'. To be anywhere like realistic it should be corrected to accept numbers, dots, hyphens and underscores as well.
--JavaWoman //(hoping the reporter shows up again so I can help him with a workaround)//
~& Gosh, this is //really// annoying. JW, any news from your general-purpose [[WikkaEmailToolkit email validation]] functions ;-) -- DarTar
~~&The basic problem is that the installer does not use any system routines but instead JavaScript for validation. And the RE it uses for email validation is really, really braindead. Yes, very annoying as I've not seen the user back in #wikka either - we may have lost a user. I could have given a workaround if only I'd not been sleeping. --- Email library is not quite ready but getting close (needs some restructuring, basically); it will be a class, with several abstract methods so the installer should be able to use it as well (provided it can find the class file). And I'm learning some good tricks working on the sessions module (which might also be useful for Wikka). But the installer needs a major overhaul in any case. Sigh... --JavaWoman
===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 {{wikkaversion}}? 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
===Comments in formatted PHP code===
GeSHi has a habit of adding a trailing line if the PHP code contains a comment using ""//"" or ""#"".
For example %%(php) echo "hello world"; // How do you do?%% This does not happen if ""/* */"" is used for comments. For example %%(php) echo "hello world"; /* How do you do? */%%
-- FreekDijkstra
~&Sounds also like a GeSHi problem rather than a Wikka bug. If anyone is installing (or has installed) GeSHi 1.0.6 I'd appreciate feedback on whether this cosmetic problem is solved as well. --JavaWoman
-----
===Encoding of GeSHi===
My default installation of Wikka 1.1.6.0 did display the error
htmlentities(): charset `646' not supported, assuming iso-8859-1 in /home/www/WWW/files/research/air/wiki/3rdparty/plugins/geshi/geshi.php
on the FormattingRules page. I was able to fix this by adding the "set_encoding" line in the GeSHi_Highlight() function in wikka.php:
$geshi =& new GeSHi($sourcecode, $language, $this->config['geshi_languages_path']); # existing code
$geshi->set_encoding('UTF-8'); # set encoding (new line)%%
-- FreekDijkstra
~&This is actually not a Wikka bug, but a problem in GeSHi itself - which only appears in rare cases. See CharsetNotSupportedWorkaround for more information. I think the latest GeSHi version (1.0.6) has addressed this problem. If you'd like to try this, make sure you remove the workaround code in Wikka when installing the new GeSHi version. --JavaWoman
===User name matching===
(related to the //Category name matching// item below)
While [[RegisterActionTest testing]] the beta RegisterAction, I realized that using a username like **""DarTartar""** results in a //"Sorry, username already exists"// error. Looks like a problem in the RE used by the ##""LoadUser()""## function. I'll take a look at it ASAP.
-- DarTar
===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)
===Multiple wikka installations on one host: Login security hole?===
Okay. Say that I've installed multiple seperate installations of wikka on one host. If I do a login on wikka A, I can also
reach the pages of wikka B, whereas wikka B has an authentication table where the user account of wikka A does not exist!
My guess is that this behaviour occurs because the login cookies are set with path root. And as long the login cookies exist
Wikka doesn't care about authentication anymore??
-- JeroenJansen
~&Same problem. Is it possible to include in wikka.config.php a line in which you specify the default cookie prefix? I guess this could solve the problem. --YanB
~~&Same problem for me as well. I've modified wikka.php to use different session names (add: session_name($wakkaConfig["wakka_name"]); just above the session_start(); ) and different cookies ("wikka_user_name@".$this->config["wakka_name"] and "wikka_pass@".$this->config["wakka_name"]) as my 2 wikkas do have have different wakka_names. Seems to behave as expected now. --OlivierPerron
===Category name matching===
Yes, I know the category system needs to be revamped, but I figured I'd report this anyway. If you have a category name that is a substring of another category name, pages referencing the second category will also appear in the first. In other words...I have a category named '""CategoryBookOne"", and another named ""CategoryBookOneJournal"". Pages that reference ""CategoryBookOneJournal"" also show up in the list of pages for ""CategoryBookOne"", which is not the behavior I expected or wanted.
-- TammyCravit
~&I cannot reproduce this on this server, nor on my own development system - at least not with the [[WikkaBetaFeatures beta and alpha]] versions of the category action. Possibly dependent on the version of PHP used where older versions may use a slightly different database query to find pages referring to a category. Tammy, if you're reading this: which version of PHP are you using? (We should test with the 'lower-PHP version of the query!) --JavaWoman
===Installer problems===
Gathered from error reports in different places (including comments on WikkaInstallation, #wikka and IM) - neither new, but worth repeating and putting together, I think:
~-In at least some cases the "detected" base path misses a closing slash (resulting in links that don't work); the installer should check if the derived path has a final slash, and if not, add one, before presenting that to the user.
~-If PHP (and thus Wikka) cannot connect to MySQL the installer just "hangs" after the first screen and printing "Testing configuration"; this seems to be (at least partly) the result of having error messages from the MySQL statements suppressed with a @, which would be OK if the error message were handled afterwards - but this doesn't happen. Other mysql_xxx() calls in the installer also have the @ suppressing error messages. That should either be removed, or all error messages should be picked up and handled by the installer, at the very least by showing the message to the user. ---
~This is especially a problem for users new at MySQL or new even at PHP+MySQL for whom it won't be obvious where to start troubleshooting when the installer simply hangs.
--JavaWoman
===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
===mod_rewrite issue in WikiEdit===
When in edit mode using IIS if you click the help button the program doesn't take you to the FormattingRules page, but tries to go to the ""FormattingRules"" Directory, which does not exist.
~& It assumes that you're using mod_rewrite and goes to the "pretty" url (wikka.jsnx.com/""FormattingRules"" instead of wikka.jsnx.com/wikka.php?wakka=""FormattingRules"") - this needs to either be editable (or is it somewhere in the WikiEdit files and I just haven't found it?) or check with the wikka.config.php to make sure it's using the correct base_url. --MovieLady
===Bug in Textsearch (expanded)===
As DotMG has pointed out, the input for this two actions isn't validated, making it a security-hole.
~&You can fix it by changing the line
$phrase = stripslashes($phrase);
into
$phrase = preg_quote($this->htmlspecialchars_ent(stripslashes($phrase)), "/");
You have to change both files (textsearch and textsearchexpanded). --NilsLindenberg
===Advanced search results reveal confidential info===
Results should be hidden or not shown if the user doesn't have read access to page IMHO. --PolVazo
~& In actions/textsearch.php you can fix it by changing the following;
~& %%(php)
if ($phrase = $_REQUEST["phrase"])
{
$phrase = stripslashes($phrase);
$results = $this->FullTextSearch($phrase);
print("<br />");
$total_results = count($results);
$match_str = $total_results <> 1 ? " matches" : " match";
print("Search results: <strong>".$total_results.$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
if ($results)
{
foreach ($results as $i => $page)
{
print(($i+1).". ".$this->Link($page["tag"])."<br />\n");
}
$phrase = urlencode($phrase);
print("<br />Not sure which page to choose?<br />Try the <a href=\"".$this->href("", "TextSearchExpanded", "phrase=$phrase")."\">Expanded Text Search</a> which shows surrounding text.");
}
}
~& into
~& %%(php)
if ($phrase = $_REQUEST["phrase"])
{
$phrase = preg_quote($this->htmlspecialchars_ent(stripslashes($phrase)), "/");
$results = $this->FullTextSearch($phrase);
$result_page_list = '';
$total_results = 0;
print("<br />");
if ($results)
{
foreach ($results as $i => $page)
{
if ($this->HasAccess("read",$page["tag"]))
{
$result_page_list .= ($i+1).". ".$this->Link($page["tag"])."<br />\n";
$total_results += 1;
}
}
$phrase = urlencode($phrase);
}
$match_str = $total_results <> 1 ? " matches" : " match";
print("Search results: <strong>".$total_results.$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
if ($total_results > 0)
{
print($result_page_list);
print("<br />Not sure which page to choose?<br />Try the <a href=\"".$this->href("", "TextSearchExpanded", "phrase=$phrase")."\">Expanded Text Search</a> which shows surrounding text.");
}
}
~& Similarly, in actions/textsearchexpanded.php you can fix it by changing the following:
~& %%(php)
if (isset($_REQUEST["phrase"]) && $phrase = $_REQUEST["phrase"])
{
$phrase = stripslashes($phrase);
print("<br />");
$results = $this->FullTextSearch($phrase);
$match_str = count($results) <> 1 ? " matches" : " match";
print("Search results: <strong>".count($results).$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
$phrase = str_replace("\"", "", $phrase);
if ($results)
{
print "<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\">";
$STORE_FORMATING_AS_TEXT = 1;
foreach ($results as $i => $page)
{
//print(($i+1).". ".$this->Link($page["tag"])."<br />\n");
//print implode($this->LoadPage($page["tag"]));
//$matchString = preg_match("/(.{0,40}$phrase.{0,40})/",implode($this->LoadPage($page['tag'])));
/* display portion of the matching body and highlight
the search term */
preg_match("/(.{0,120}$phrase.{0,120})/is",$page['body'],$matchString);
$text = $this->htmlspecialchars_ent($matchString[0]);
// include("formatters/wakka.php");
$highlightMatch = preg_replace("/($phrase)/i","<font color=\"green\"><b>$1</b></font>",$text,-1);
$matchText = "<font color=\"gray\" size=\"-1\">...</font>$highlightMatch<font color=\"gray\" size=\"-1\">...</font>";
print "
<tr>
<td valign=\"top\" align=\"right\">
<!-- result number -->
<table>
<tr>
<td valign=\"top\" align=\"left\" bgcolor=\"#DDDDDD\">
<font color=\"white\" size=\"-3\">
".($i+1)."
</font>
</td>
</tr>
</table>
</td>
<!-- link -->
<td valign=\"top\">
".$this->Link($page["tag"])."
</td>
<!-- date of last update -->
<td valign=\"top\" align=\"right\">
<font color=\"gray\" size=\"-3\">
$page[time]
</font>
</td>
</tr>
<tr>
<td>
 
</td>
<td colspan=\"2\">
$matchText
</td>
</tr>
<tr>
<td>
 
</td>
</tr>
";
}
print "</table>";
}
}
~& into
~& %%(php)
if (isset($_REQUEST["phrase"]) && $phrase = $_REQUEST["phrase"])
{
$phrase = preg_quote($this->htmlspecialchars_ent(stripslashes($phrase)), "/");
print("<br />");
$results = $this->FullTextSearch($phrase);
$phrase = str_replace("\"", "", $phrase);
$result_page_list = '';
$total_results = 0;
if ($results)
{
print "<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\">";
$STORE_FORMATING_AS_TEXT = 1;
foreach ($results as $i => $page)
{
if ($this->HasAccess("read",$page["tag"]))
{
preg_match("/(.{0,120}$phrase.{0,120})/is",$page['body'],$matchString);
$text = $this->htmlspecialchars_ent($matchString[0]);
$highlightMatch = preg_replace("/($phrase)/i","<font color=\"green\"><b>$1</b></font>",$text,-1);
$matchText = "<font color=\"gray\" size=\"-1\">...</font>$highlightMatch<font color=\"gray\" size=\"-1\">...</font>";
$total_results += 1;
$result_page_list .= "
<tr>
<td valign=\"top\" align=\"right\">
<!-- result number -->
<table>
<tr>
<td valign=\"top\" align=\"left\" bgcolor=\"#DDDDDD\">
<font color=\"white\" size=\"-3\">
".($i+1)."
</font>
</td>
</tr>
</table>
</td>
<td valign=\"top\">
<!-- link -->
".$this->Link($page["tag"])."
</td>
<td valign=\"top\" align=\"right\">
<!-- date of last update -->
<font color=\"gray\" size=\"-3\">
$page[time]
</font>
</td>
</tr>
<tr>
<td> </td>
<td colspan=\"2\">$matchText</td>
</tr>
<tr>
<td> </td>
</tr>
";
}
}
$match_str = $total_results <> 1 ? " matches" : " match";
print("Search results: <strong>".$total_results.$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
if ($total_results > 0)
{
print($result_page_list);
print("</table>");
}
}
}
~& This fix also includes another fix on this page by NilsLindenberg in the "Bug in Textsearch (expanded)" section. --QualousHere
===Recent[ly]Comment[ed|s] actions should check for permission===
Comments are being previewed even if users do not have access. A simple check needs to be added. -- JsnX
if ($this->HasAccess("comment"))
~& Recent Comments: Here is an implementation of the above suggestion. NickDamoulakis
<?php
if ($comments = $this->LoadRecentComments())
{
$curday = "";
$allComments = 0; // This tracks the total number of comments found
$accessibleComments = 0; // and this one only those that we can look at
foreach ($comments as $comment)
{
$allComments++;
if ($this->HasAccess($comment))
{
$accessibleComments++;
// day header
list($day, $time) = explode(" ", $comment["time"]);
if ($day != $curday)
{
$dateformatted = date("D, d M Y", strtotime($day));
if ($curday) print("<br />\n");
print("<strong>$dateformatted:</strong><br />\n");
$curday = $day;
}
$timeformatted = date("H:i T", strtotime($comment["time"]));
$comment_preview = str_replace("<br />", "", $comment["comment"]);
$comment_preview = substr($comment_preview, 0, 125);
if (strlen($comment["comment"]) > 120) $comment_preview = $comment_preview.".... ";
// print entry
print("   ($timeformatted) <a href=\"".$this->href("", $comment["page_tag"], "show_comments=1")."#comment_".$comment["id"]."\">".$comment["page_tag"]."</a> . . . . ".$this->Format($comment["user"])."<br />\n       <em>$comment_preview</em><br />\n");
}
}
// If we are only showing a portion of the comments, tell the user so.
if ($accessibleComments != $allComments)
{
Echo "<br><hr>You are only shown comments that you have access to.";
}
}
else
{
print("<em>No recent comments.</em>");
}
?>%%
~& Recently Commented: Here is an implementation of the above suggestion. NickDamoulakis
<?php
if ($comments = $this->LoadRecentlyCommented())
{
$curday = "";
$allComments = 0; // This tracks the total number of comments found
$accessibleComments = 0; // and this one only those that we can look at
foreach ($comments as $comment)
{
$allComments++;
if ($this->HasAccess($comment))
{
$accessibleComments++;
// day header
list($day, $time) = explode(" ", $comment["time"]);
if ($day != $curday)
{
$dateformatted = date("D, d M Y", strtotime($day));
if ($curday) print("<br />\n");
print("<strong>$dateformatted:</strong><br />\n");
$curday = $day;
}
$timeformatted = date("H:i T", strtotime($comment["time"]));
$max_preview_length = 122;
$comment_preview = str_replace("<br />", "", $comment["comment"]);
if (strlen($comment_preview) > $max_preview_length) {
$comment_spillover_link = "<a href=\"".$this->href("", $comment["page_tag"], "show_comments=1")."#comment_".$comment["id"]."\" title=\"View comment\">[.... ]</a>";
$comment_preview = substr($comment_preview, 0, $max_preview_length).$comment_spillover_link;
}
$commentlink = "<a href=\"".$this->href("", $comment["page_tag"], "show_comments=1")."#comment_".$comment["id"]."\" title=\"View comment\">".$comment["page_tag"]."</a>";
$comment_by = $comment["user"];
if (!$this->LoadUser($comment_by)) $comment_by .= " (unregistered user)";
// print entry
print("    $commentlink, comment by $comment_by: <br />\n         <em>$comment_preview</em><br />\n");
}
}
// If we are only showing a portion of the comments, tell the user so.
if ($accessibleComments != $allComments)
{
Echo "<br><hr>You are only shown comments that you have access to.";
}
}
else
{
print("<em>There are no recently commented pages.</em>");
}
?>
===tags in the edit notes===
I made a edit note: "removed a <?php (to much)" and got "removed a". Perhaps replacing <> would be the better option? --NilsLindenberg
~&Funny - I just stumbled over the same problem - only in the RecentChanges newsfeed: the <?php causes imbalanced tags there, and thus a syntax error: until that post has "aged" off of the feed, it can't be loaded any more! The [[http://feedvalidator.org/check?url=http%3a%2f%2fwikka.jsnx.com%2fRecentChanges%2frecentchanges.xml validation result]] clearly shows what the problem is. So yes, edit notes should be fed threough htmlspecialchars[_ent]() everywhere they're presented, and that includes the RSS feed! --JavaWoman
~~&And the WikiPing, too :) --NilsLindenberg
~&Oh is **that** what you removed Nils. I couldn't figure out using history what you did. Where did you take it from? And why? Did I have one more <?php than was necessary? In which code block? --GmBowen
~~&It was at the beginning of mail.php: %%(php) <?php <?php%%. I guess you overlooked it when you copied your new version to the page. Happened to me in another case, too. --NilsLindenberg
~&Actually, the problem is not just with tags; any XML "special character" is going to cause an XML error. All will need to be escaped to ensure the RSS feeds and pings are valid XML. (We are having a problem again...) --JavaWoman
~~&Fixed now: Code changes in wikka.php (GetPingParams()), actions/recentchanges.php, handlers/page/recentchanges.xml.php, handlers/page/recentchanges.xml.mm.php, handlers/page/revisions.php and handlers/page/revisions.xml.php. Installed on this server as "beta test" so we can watch behavior. --JavaWoman
===Missing language-support in the code formatter===
(copied from the sandbox --NilsLindenberg)
not support 2byte language in the Code formatters!!!!
%%(c)
// ??? ????
// ?? ???.. ??.. ?????? ??? ?? ????..
...
===Error on ./handlers/page/referrers_sites===
Line 46 :
- Code generates a double </a> for links.
- & in URL should be replaced by &
=> %%(php) print("<td valign=\"top\">" . (($site != "unknown") ? "<a href=\"http://".$this->htmlspecialchars_ent($site)."\">".$this->htmlspecialchars_ent($site)."</a>" : $site) . /*"</a> ".*/($IsAdmin ? "[<a href=\"".$this->href("delete_referrer", "", "spam_site=").$this->htmlspecialchars_ent($site)."&redirect=".$this->GetMethod()."\">Blacklist</a>]" : "")."</td>");%%
Note: You cannot see this error by validating directly a page because W3C is not registered and it will not have the same output as you, in other words, code on line 46 won't be executed. But you can save the page on your hard disk and validate it.
--DotMG
===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
===Accept-Encoding: gzip;q=0, deflate===
**Not really bug, but should be corrected for respect & compliance to RFC2616**
If a browser sends the header
Accept-Encoding: gzip;q=0, deflate
Which should be interpreted as : "I don't support gzip encoding, but I prefer deflate", Wikka will understand "The browser supports gzip-encoding", as it just searches for the text gzip in $_SERVER['HTTP_ACCEPT_ENCODING']. An example I use to treat it correctly is :
%%(php) function ParseHeaderLine($hl, $token=null)
{
$ar_hl = explode(',', $hl);
foreach ($ar_hl as $dotmg_idx => $val)
{
if (preg_match('/^\s*(.*?);\s*q\s*=\s*([0-9\.]*)/i', $val, $match))
{
$res[strtolower($match[1])] = doubleval($match[2]);
}
else
{
$res[strtolower($val)] = 1;
}
}
if ($token) return(isset($res[$token]) && ($res[$token] > 0)); #if $token is set, we return true or false
return ($res); # else we return the header parsed.
}%%
and
%%(php) if ($this->ParseHeaderLine($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ...%%
Note : This function might be useful to deal also with Accept-Language, when Wikka will be made effectively multilingual.
--DotMG
===1.1.6.0beta4: Simplified Chinese (or Unicode relative) in WikiEdit:===
A page contains unicode characters looks OK when viewed but displays ""''&#*****;''"" while edited in WikiEdit
Simplified Chinese Test:
????????????????????????????????
In 1.1.5.3, I solved this problem by changed some line in ./handlers/page/edit.php
#from
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$body."</textarea><br />\n"
#to
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$this->htmlspecialchars_ent($body)."</textarea><br />\n"
Wikka is wonderful! ZhuangYuyao
~&This workaround you outlined will work as well in Wikka 1.1.6.0. A real solution wil take some more investigation though, so we were unable to fix this for the current release. This is now under investigation. --JavaWoman
===Double-click editing===
I noticed: Turning off DoubleClick-editing does not work (double-clicks still go to edit-window) in IE 6.0 or Firefox 1.0.
Keep up the good work!
Cheers, MarkHissinkMuller
~&Yes, I noticed the same thing. This is a bug as of 1.1.6.0. --RyanKnoll
~~&Heres the fix:
~~&add as **first** line in handlers/page/show.php:
~~&%%(php;1)
<?php $user = $this->GetUser(); ?>
~~&and change the second line to:
~~&%%(php;2)
<div class="page" <?php echo ((!$user || ($user["doubleclickedit"] == 'Y')) && $this->GetMethod
() == "show") ? "ondblclick=\"document.location='".$this->href("edit")."';\" " : "" ?>>
~~&--NilsLindenberg
There is another issue with double-click editing: while registered users can edit their preferences to use double-click editing or not, it is always on for non-registered (or not logged-in) users. The result is that on pages that can be edited only by registered users, a double-click results in an unfriendly error message. Especially on a site that is mostly read-only for visitors this is a bad situation. The solution is to make this admin-configurable.
Add to wikka.config.php:
%%(php) "doubleclickedit" => "Y", # set to "N" to disable double-click editing%%
and change the proposed line for the show handler above to:
%%(php;2)<div class="page" <?php echo (((!$user && $this->config['doubleclickedit'] == "Y") || ($user['doubleclickedit'] == 'Y')) && $this->GetMethod
() == "show") ? "ondblclick=\"document.location='".$this->href("edit")."';\" " : "" ?>>
%%--- --JavaWoman
~&In that case, wouldn't you want new profiles to have dblclick turned off by default ? (TroelsKnakNielsen)
===$_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
===PageIndex problem===
DarTar and I have recently created some test pages, testing page names related to how Wikka evaluates 'valid' page names: ,My,Page and ÄhnLich (yes, they both exist, even if they don't show up as such in this sentence!). Now look at where they show up on PageIndex... surely there shouldn't be **two** '#' indices??
--JavaWoman
~&I think that this is due to the encoding of the MySQL tables. I can't see how that would be fixed with a small touch on the code. If this is the matter then I hope that it also rings the i18n bell too. //Translation to Greek is my bussiness ;)// --GeorgePetsagourakis
~~&Yes, my i18n bells were already loudly ringing... but you bring up a good point with MySQL. I hadn't thought about a real cause yet, just wanted to record what I saw before I got distracted again ;-). Sort order is a whole subject of its own within i18n .... --JavaWoman
===Install Note on Basic URL and CSS===
First, this may applied to my ISP only. When I installed, I have to use
the ?wakka= options. However, I have to add a / to the end of the
default Basic URL before append ?wakka= to it. So I think it maybe
helpful to modify the instruction to '... so it should include
the "/?wakka=" parameter...'
~&ArpY: Maybe this is caused by a config error. Please have a look at your config - is there a slash at the end of the base_url?
~~&IMO the installer should take care that there is a slash if the user doesn't enter it --JavaWoman
===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
===Weirdness with Include===
Um, I don't know how to describe this really. Put ""{{include page="Category Documentation"}}"" (//without the space!//)on the SandBox page....I can't figure out why it gives that output as Sandbox doesn't own anything.
~&Looks like the weirdness is caused by the ""{{Category}}"" action which assumes the "current page" represents the category - and find pages "belonging to" a category by finding a mention of that page name. Good sign our category system does need an [[CategorySystemOverhaul overhaul]]! --JavaWoman
~&Include pulls in a page that itself has the category action on it; the "official" version of this action assumes that the page it occurs on **is** a category. The "//experimental//" category action that is now active on this site no longer makes this assumption but recognizes that SandBox isn't a category page and defaults to the top category. See Sandbox for a an example (at this moment). --JavaWoman
~~&I can see that it now works, but what do you mean that it "recognizes that Sandbox isn't an action".....do you mean target page? --GmBowen
~~~&Oops, sorry (corrected now) - I meant the new category action sees whether the page it's "sitting" on is a category page or not - if not it defaults to showing the list for the top-level category. --JavaWoman (aka IamBack)
===Backlinks / ""LoadPagesLinkingTo()""===
I just discovered that the ##""{{backlinks}}""## action may list pages that don't "exist" any more, in the sense that they (apparently) still are in the database but without any active version (seemingly as a result of a rename action. I added an example on [[JavaWoman my own page]] where you can see a supposed backlink from ReleaseNotes (which was replaced by WikkaReleaseNotes).
~&The cause is apparently in the ""LoadPagesLinkingTo()"" method which is used by ##""{{backlinks}}""## action. It currently is implemented like this:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' order by tag"); }
%% I think replacing this by:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' and latest = 'Y' order by tag"); }
%% might do the trick to avoid deceased pages - but please test!
~&--JavaWoman
~~&It wont do, since the link-table has no latest col ;). But shouldn't the delete-handler delete these links from the table anyway? --NilsLindenberg
~~~&Indeed it is the delete handler that is at fault here by not deleting all records from the links table that refer to the (to be) deleted page. This is simple enough to fix (by extending the query a little to match both the "from_tag" and "to_tag" columns) but for a future version to be released with such a fix there should also be an (admin-only) utility to clear left-behind records from the links table that //should// have been deleted before. --JavaWoman
====GetEnv is not a good idea!====
At ./wikka.php, you will see a line %%(php)<?php if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";?>%%
In the most cases, a website is hosted in a machine as a VirtualHost, this means that a number of websites share the same environment variables. If someone knows where your site is hosted, he can put his site at the same server, and use a script containing %%(php)<?php putenv('WAKKA_CONFIG=/home/hacker/config.php');?>%%. And all wikka sites on the same server will use his configuration file. The rest actions to take to hack your site will be as easy as eating sandwich.
Php doc says that an environment variable is altered only during the life of the script, but with my dev Easyphp's on windows, that is false. (I think a "new" environment variable keep its value, even on Linux).
I wanted to make a unique Wikka interface used by 3 sites on the same server. The best secure solution I found is to alter ./wikka.php like this :
%%(php)<?php
if (file_exists("wakka.config.php")) rename("wakka.config.php", "wikka.config.php");
#if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";
if (!$configfile && isset($GLOBALS['wikka_config'])) $configfile = $GLOBALS['wikka_config'];
if (!$configfile) $configfile = "wikka.config.php";
if (file_exists($configfile)) include($configfile);
and put the 2 files sitenumber2.php and .htaccess below at the root of the server number 2:
__sitenumber2.php:__
%%(php)<?php
$GLOBALS['wikka_config'] = "/path/to/altered_config.php";
chdir("/path/to/basewikka");
include('wikka.php');
?>%%
__.htaccess:__
%%<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.*/[^\./]*[^/])$ $1/
RewriteRule ^(css|images|wikiedit2)/(.*)$ /path/to/basewikka/$1/$2 [L]
RewriteRule ^(.*)$ sitenumber2.php?wakka=$1 [QSA,L]
</IfModule>%%
--DotMG
~&I've now written up my thoughts about a [[WikkaSecureConfig more secure way to handle Wikka's configuration]] (which should also provide also more flexibility). --JavaWoman
===Expanded Text Search fails===
I tried an expanded Text-Search after [[http://wikka.jsnx.com/TextSearchExpanded?phrase=%2Bparameter+%2Blink +parameter +link]] and got the following error:
"Warning: Compilation failed: nothing to repeat at offset 1 in /.../actions/textsearchexpanded.php on line 33"
for every page.
--NilsLindenberg
~&In my recent RE exploits I have found that a warning of this type comes up when a regular expression isn't quite correct (though not every attempt to match may bring up the warning); haven't investigated further in textsearchexpanded.php though. --JavaWoman
~&Php has a function : preg_quote that may help us. Or try this solution : DotMGTextSearchExpanded
-----
=== Yet more formatter bugs ===
Looking at **formatters/wikka.php** to find the cause of the two bugs listed below (found one), I notice to my horror that a **lot** of the regular expressions used there are actually incorrect. They allow such things as using a comma to indent a line (in addition to a tab, or ~, at the start of a line: **demo** in the SandBox, and in the list **below**!), or a comma in a WikiName (even at the start) or in an InterWiki link. That can't have been the intention - it's simply a matter of incorrect RE syntax. I'd become sort of "sensitized" to this phenomenon looking at DarTar's RE on ValidPageNames earlier today - now I see where he found an example (see my comment on that page on his RE!).
''See also [[,My,Page]] - yup, that's a real page now. ;-)''
~&Rather than simply fixing all the REs (and other REs all over the place...) I'd like to propose a more fundamental solution:
~&-create a "library" of RE building blocks to be used in the Wikka core (for an example of what I mean with building blocks see my propopsal for an alternative RE on ValidPageNames); simply create a separate file with define()s for these building blocks, and include them at the start of the main wikka.php file;
~&-gather all RE used in the Wikka core here (extensions/plugins could have their own set of defines - as long as they don't have conflicting names);
~&-now use **only** these building blocks when using REs anywhere in the Wikka core.
~&This should make it much easier to create both //correct//, and //consistent// regular expressions; any (near)duplicates will be much easier to discover, and fix.
~&
~&Probably best to leave this to just **after** the coming release, so we have a stable code base again. I volunteer to undertake this work. (Unlike some people, I happen to like REs.) :)
~&--JavaWoman
=== 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
~&Possible clue:
~&I just stumbled over the fact that the little list of "Useful pages" at the end of the default (installation-generated) ""HomePage"" had incorrect coding: The last list item (li) was not terminated, nor was the list itself (no closing ul tag). It took me a bit of trial and error to reproduce this - but have a look at my test code at the end of SandBox (now). Originally I thought that any list at the end of a page would be unterminated, but that turned out not to be the case. Then I hit on something else: the last list element on that default ""HomePage"" (not the one here) ands with a period. My test version on SandBox now also has the last element ending in a period ... and if you look at the (HTML) page source, you'll see it is indeed an unterminated list. Somehow that ending period (maybe in combination with end-of-page?) causes the Formatter never to close the list; take that ending period away, and it works normally. I tried a few variants, to check whether it might be an odd-even problem, but no: whether the number of list items is odd or even, if the last one ends in a period, the list isn't terminated.
~&
~&No difference whether it's anordered (ol) or unordered (ul) list, the formatter behaves the same way.
~&
~&And, BTW, if you look at the preview when editing, the HTML source of the **preview** actually contains a lot of Wiki code that shouldn't be there!
~&
~&I haven't dug in the Formatter yet to find the cause or whether end-of-page makes a difference...
~&--JavaWoman
~~&This is indeed an "end of page" problem: teh formatter has some code to close tags inadvertently left open, but does not do this for lists and indent (nor even fro *all* open tags). Fix coded and tested - this will be in 1.1.6.1. --JavaWoman
=== 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
~~&I'm running MySQL 5 fine with the mysql_* functions. When you compile PHP, it's your choice to compile the mysql_* or mysqli_* functions. I chose to compile it with mysql_*, which is working fine for me. --BarkerJr
==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 "**dan**gerous" - 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
===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
===Windows Paths With ""{{files}}"" Action===
On a Windows/IIS installation, including the ""{{files}}"" action causes errors similar to the following:
Warning: mkdir(uploads\SandBox): Permission denied in D:\sitepath\wwwroot\wikka\actions\files.php on line 12
Warning: opendir(uploads\SandBox): failed to open dir: Invalid argument in D:\sitepath\wwwroot\wikka\actions\files.php on line 156
Warning: readdir(): supplied argument is not a valid Directory resource in D:\sitepath\wwwroot\wikka\actions\files.php on line 157
Warning: closedir(): supplied argument is not a valid Directory resource in D:\sitepath\wwwroot\wikka\actions\files.php on line 200
This is caused by the assumption of "/" as the directory seperator instead of Window's "\". Using the DIRECTORY_SEPARATOR variable corrects this is.
In actions/files.php change:
$upload_path = $this->config['upload_path'].'/'.$this->GetPageTag();
%% into
$upload_path = $this->config['upload_path'].DIRECTORY_SEPARATOR.$this->GetPageTag();
and also:
$destfile = $upload_path.'/'.$strippedname;
%% into
$destfile = $upload_path.DIRECTORY_SEPARATOR.$strippedname;
Warning: This has only been tested so far under Windows. -- QualousHere
CategoryDevelopmentSuggestions
Deletions:
~& Brendon, it's true that Wikka development has slowed down the last months. There is no date yet for the next release, but things should start to move faster: we have recently set up some [[http://wush.net/trac/wikka tools]] to enable a better tracking of new features/bugfixes. This should make the release procedure faster and more frequent. In the mea


Revision [12475]

Edited on 2005-12-29 10:51:04 by McMurlock [reverting deleted items + replying on double-click bug]
Additions:
===UserSettings for Doubleclick Editing doesn't work===
workaround : add at the top of show.php $user=$this->GetUser();
before
<div class="page" <?php echo (!$user || ($user["doubleclickedit"] == 'Y')) && ($this->GetMethod() == "show") ? "ondblclick=\"document.location='".$this->href("edit")."';\" " : "" ?>>
after
<div class="page" <?php $user=$this->GetUser(); echo (!$user || ($user["doubleclickedit"] == 'Y')) && ($this->GetMethod() == "show") ? "ondblclick=\"document.location='".$this->href("edit")."';\" " : "" ?>>
~& Brendon, it's true that Wikka development has slowed down the last months. There is no date yet for the next release, but things should start to move faster: we have recently set up some [[http://wush.net/trac/wikka tools]] to enable a better tracking of new features/bugfixes. This should make the release procedure faster and more frequent. In the mea
Deletions:
~& Brendon, it's true that Wikka development has slowed down the last months. There is no date yet for the next release, but things should start to move faster: we have recently set up some [[http://wush.net/trac/wikka tools]] to enable a better tracking of new features/bugfixes. This should make the release procedure faster and more frequent. In the meantime, you might want to check out [[http://dartar.free.fr/code this]]. -- DarTar
===PasswordForgotten / emailpassword problem with Konqueror (Form-Action missing)===
Hi! I've found that in Konqueror the PasswordForgotten-script doesnt work! It's because in ##actions/emailpassword.php## on lines 41 and 51
%%(php)$form = "<form name=\"getwikiname\" action=\"\" method=\"post\">";%%
the action-attribute of the <form>-tag is missing. It works without any problems in any browser I've checked with (actually Firefox 1.0.7 and Konqueror 3.4.1) when I change both lines to
%%(php)$form = "<form name=\"getwikiname\" action=\"".$this->href()."\" method=\"post\">";%%
Found this bug in Wikka 1.1.6.0 and don't see any reason why not to change this for better browser-compatibility...
Regards, IceT
===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...
===Retrieving user-information (Session Leakage)===
//moved from StayingLoggedIn. NilsLindenberg//
if you don't log out, then with a simple
echo "<PRE>_REQUEST =";print_r($_REQUEST)."</PRE>";
you can see the user's username and pass (md5'ed of course)
_REQUEST =Array
(
[skin] => xxxxxx.css
[PHPSESSID] => xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[wikka_user_name] => xxxxxx
[wikka_pass] => xxxxxxxxxxxxxxxxxxxxxxxxxx
)
I think this is called a session leakage, anyone knows of a solution to this.
Perhaps a solution to this would be changing the name of the session that a particular wikka installation uses,
The name could be a random number/word passed from md5 this way its unique to each wikka installation.
Also changing the path that the session data are stored maybe helpful. (I have seen discussions on this I think on php.net session_name() or session_start() )
I don't really know the implications of this bug are (maybe its not even a bug), perhaps people can see the session data on shared hosts and that is really what concerns me.
-GiorgosKontopoulos (look also at "Multiple wikis ... Login security hole?" later down the page)
__Update__
There are more places this bug makes itself known.
If one has accounts in two different Wikka wiki's sites then changing the skin in one will affect the active skin in the other
Or if you log in/log out in one you find yourself logged in or logged out in the other.
tested it using
1) 2 Wikka engines, same server, using FF1.0.6, had same userName and pass on both
behaves as stated above.
2) 2 Wikka engines, same server, using FF1.0.6, using userA on the one installation
the other installation thinks I am userA but does not actually let me see pages only allowed to userA.
3) jsnx.wikka.com and my test installation using FF1.0.6, had same userName and pass on both
it runs ok it seems.
Not a terrible bug but may have other implications still hidden.
-GiorgosKontopoulos Oct. 27, 02:09:21 UTC
===Reuse of Username when multiple wikkas on single server===
Not sure if this is truly a bug, but I have a number of wikka installations,. each in different (peer) directories on a server, each using different DB's. Now, each has a user named SeanOttey, and if I go log in at site A, then go to site B, I am shown as logged in, but with the other site's user info (i.e. email, password, settings). Potentially, this might create accessibility that an admin did not intend, yes? thanks! Sean.
===Wikiedit: Link to the Formatting-rules (using IIS and not using mod-rewrite)===
from [[http://arek.c-consulting.co.id/ivan/wikka/wikka.php?wakka=WikiEditHack IvanLaninWiki]]: (see there for his solution)
//I don't use rewrite_mode since I'm using IIS as server, and I also put value for base_url for my wikka. Then I notice, by accident, that the Help button on WikiEdit∞ does not point to the right page (FormattingRules).//
===Wikka in Windows IIS===
When Wikka is installed in IIS5.0 occurs an error when using cookies and using the header(Location:)
http://br.php.net/manual/pt_BR/function.setcookie.php#51195
This error implies in not log in or out, because the page redirects before the cookie i created.
The problem can be solved using javascript to redirect the page, just change the following line in the code of Redirect function on wikka.php:
%%(php)header("Location: ".$url);%%
by this:
if (substr_count($_SERVER["SERVER_SOFTWARE"],"IIS") > 0) {
~& echo '<SCRIPT>window.location.href = "'.$url.'";</SCRIPT>';
} else {
~& header("Location: ".$url);
}
-- MarceloArmonas (sorry, i don't write in english)
===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
===Wikiedit: Problem with some date strings===
When I write a date in DD.MM.YYYY format **and** the date string is right at the beginning of a line, trying to mark the complete string and click the wikiedit buttons for bold (italic, etc.) text results in an incorrect markup:
31.12.2005 <- does not work (case 1)
Filler text 31.12.2005 <- does work (case 2)
Here is the wikiedit output for case 1.
How it is:
%%31.**12.2005**%%
How it should be:
%%**31.12.2005**%%
Again, it works when the date string is not at the very beginning of a new line.
===history bug===
If you try to access the history for the SuggestionBox you'll get an server-error (500). Perhaps related to the size of the history? --NilsLindenberg
~&A rough estimate: there have been between 425 and 450 revisions of that page; the current page **source** size is 92316 bytes; given that the page tends to grow but is sometimes "weeded" when suggestions are implemented or moved to a separate page, the total 'history' **source** size could be something like 12.5MB. Even is it's as "small" as 5MB I wouldn't be surprised to have it break //somehow// (DB access, PHP timeout...).---Maybe we should just give up on 'history' and support only revisions? Where or how something like this breaks is hard to tell, it could be entirely dependent on a specific installation. --JavaWoman
===blog.php===
//Moved to WikkaBlog2 since it's user-contributed code]//
===usersettings.php===
//nearly missed this - copied from MiKolar - JW//
WikkaWiki version 1.1.6.0 login/register actions returns often confusing error messages
(e.g., if a registered user makes an error in his WikiName, he gets an error message
"You must specify an email address", which may be rather confusing to a properly registered
user). Here is my attempt to straighten this up (...) http://www.world-wide-democracy.net/members/MiUploads/usersettings.php.gz
--MiKolar
===Accesskey on comments===
//copied from the #wikka channel - JW//
<SamuelDr> for the next important guy/gal who'll read this
<SamuelDr> the accesskey="d" on the comments is a little bit useless
<SamuelDr> when there are more than 1 comment deletable on a page
<SamuelDr> I think it wouldn't work really well ;)
===.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.
%%(apache)
### 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
===Formatter-bug in the comments===
//reported by someone named DarTar ;) on my userpage. --NilsLindenberg//
Note for ourselves: if you look at the commentinfo by dialup-4.227.116.20 you'll see that we have a small formatter bug (Dial1 is parsed as a missing page): CamelCase formatting should not be applied within commentinfo's.
''part of a users host-name is formatted as a wikilink''
=== Indenting not working properly in handlers/page/edit.php ===
$body = preg_replace("/\n[ ]{4}/", "\n\t", $body); # @@@ FIXME: misses first line and multiple sets of four spaces - JW 2005-01-16
Working fix (this might not be the best code doing the job...)
// replace each 4 spaces at beginning of a line with a tab
$body = preg_replace("/^[ ]{4}/","\t", $body);
$body = preg_replace("/\n[ ]{4}/","\n\t", $body);
while (preg_match("/\t[ ]{4}/",$body)) {
$body = preg_replace("/\t[ ]{4}/","\t\t", $body);
}
-- TimoK
~&The line with the "incomplete" indents-handling code actually occurs twice in ##handlers/page/edit.php##; while I haven't addressed that duplication yet (the handler code really needs to be restructured), I came up with the following (a little more robust) code to fix this particular bug: %%(php) # JW FIXED 2005-07-12
$pattern = '/^(\t*) {4}/m'; # m modifier: match ^ at start of line *and* at start of string;
$replace = "$1\t";
while (preg_match($pattern,$body))
{
$body = preg_replace($pattern,$replace,$body);
}
# @@@ NOTE: This could be easily extended to also change a '~' into a tab. But should we? '~' is easy to type and edit
%%---Implemented as BETA on this site now. --JavaWoman
===Wakka formatter: Indenting on first line===
// indented text
elseif (preg_match("/\n([\t~]+)(-|&|([0-9a-zA-ZÄÖÜßäöü]+)\))?(\n|$)/s", $thing, $matches))
This simply doesn't match indents on the first line.
I know there is a problem in the edit handler as well with indents, but even if that is fixed (working solution for that problem at WikkaBugsResolved) we still will have the problem here. -- TimoK
~&Fixed and implemented as part of the beta ImprovedFormatter on this site; see ""<a href="ImprovedFormatter#hn_Better_handling_of_nested_lists_and_indents">Better handling of nested lists and indents</a>"" on that page for the details. --JavaWoman
===No Registration Wikki===
I just started using this program and I love it ! Its exactly what I've been looking for. However what I want is a Wikki where only the administrator can register new users. This seems like such an obvious feature that I am amazed I cant figure out how to do it !
What am I missing ?
--DavidLee
--Sorta Fixed--
Ok I figured this out ... mostly. Feel free to delete this section if its seems obvious to everyone ! (It wasnt to me)
I changed my default ACL for write and comment to "!*" ... but left read as "*".
People can still register themselves but it doesnt do them much good as they cant create pages.
--DavidLee
Hi DavidLee!
No, we don't have an ""{{adduser}}"" yet. If you don't want other people to register, try out the solution from UserRegistration which allows you to stop registration (and you could use phpmyadmin to add users directly to the database). The solution makes it possible to allow registration only with a password, which can be set in the config. See UserRegistration for more details. A division of registration/log-in and usersettings into different actions is planned but won't come in the next release. --NilsLindenberg
===Code display problem===
The following combination of conditions triggers the problem:
~-multi-line comment (for instance a multi-line /*........*/ block in php)
~-empty lines within such a comment
~-line numbering turned on
When viewed in Mozilla or Firefox (at least - possibly others), the empty lines **overlap** the preceding lines, as can be seen by the line numbers.
Looking at the generated code, an empty line within a multi-line comment (with line numbers) results in this code: %%(html4strict)<li><div class="de1"><span class="coMULTI"></span></div></li>%%---while an empty line elsewhere results in %%(html4strict)<li><div class="de1"> </div></li>%%---Note the ##&nbsp;## in the latter case (which gives the div actual content) while the empty multi-comment line has nothing but an **empty** span, and no actual content.
This seems to be a combination of a **GeSHi** bug (there should at least a ##&nbsp;## be generated as content) combined with a **gecko** oddity (or bug?) that will render a number for an ordered list item but not give it a normal line height if the list item is empty.
**Workaround:** add some whitespace to the empty lines - a single tab works (a space probably will as well).
--JavaWoman
===Installer array_merge()===
//Mentioned in passing on #wikka by a user having actually other problems installing Wikka.//
Remember the array_merge() problem in wikka.php under PHP5? Solved in 1.1.6.0.
Guess what: the same problem still exists - but in the installer itself (##/setup/install.php## - line 7): the second argument is (again) not initialized so users get a warning stating "Argument #2 is not an array in /var/www/html/Wikka/setup/install.php on line 7".
We'd better solve it in the installer as well. --JavaWoman
===View Code Handler issue===
The view code handler does not display any message if the page does not exist. [[http://wikka.jsnx.com/NonExistantPage/showcode Example]] -- Rick
~& Technically, it isn't a bug: Wikka tries to display original data concerning the page. As it doesn't exists, Wikka displays nothing. It isn't a bug but a non-existent feature of Wikka, so I would put this comment in SuggestionBox instead of here. JavaWoman? DarTar? What do you think of it? -- PivWan
~~&Actually, I suggested Rick reported it here since I **do** consider it a bug. It is a **page** handler so the handler should look for a page; I think it should return //something// at least. IMO the best solution would be to generate a warning like "Page does not exist" when the page isn't found, or use the "do you want to create it?" we use when accessing a non-exstant page. --JavaWoman
~~~& Okay, hadn't the whole story. So, it's a bug :) -- PivWan
===Email deletion after registration===
On 1.1.6.0 a registered user can modify his or her settings and store an **empty email address**. The engine does not warn the user and accepts an empty value. This bug should be fixed or at least the behavior of UserSettings should be made consistent with the registration requirements (if an email is required, it is required also //after// registering). Note that this might break (beta-)actions based on user email, such as FeedbackActionUpgrade (to be checked)-- DarTar
===Purging of pages not always happening===
//reported by |Sam| on #wikka, writeup by me --JavaWoman//
Purging of pages doesn't always seem to happen. |Sam| had the page_purge_time set to 1 (which should purge page versions older than one day) but didn't see them being actually purge. Purging is done in the Maintenance() method in ##wikka.php## executed by the main Run() method. However, there is an extra condition here: %%(php)if(!($this->GetMicroTime()%3)) $this->Maintenance();%% I suspect this may cause the Maintenance() method not being executed. The intention of this (undocumented) condition isn't clear to me - should it really be there? --JavaWoman
~&That's correct. I'm not the author of this code, but the intention is clear to me. It's designed to be a performance improvement. Rather than call the Maintenance function for every single page view(!), it adds some randomness based on the remainder of GetMicroTime() divided by 3. For a busy site this could make a significant drop in MySQL queries. I have done some brief testing of this code and found that on average the Maintenance function was called about every four page views. For any site that has even moderate traffic, the Maintenance function will be triggered sufficiently. To answer your question, yes, this condition should be there. However, maybe there should be a configuration option that admins could tweak if they are obsessed and need certainty that pages get purged. -- JsnX
~~&Another way is to follow what (I think) PHP does for session cleanup. Set a threshold and test if a random number (between 0 and 1, inclusive of 0) is less than that threshold. If so, then do cleanup. Otherwise don't. The threshold is then a percentage chance that cleanup will happen on a particular request instead of hoping that the time falls just right. --JameSmith
===RSS feed action hangs or crashes browser if feed does not exist===
//reported by velkr0 on #wikka, analysis and writeup by me -- JavaWoman//
**Problem**: When the rss action is included in a page with a feed URL that happens not to exist (or not exist any more), the page "hangs"; once in this state, editing the page also isn't possible: the hang continues until the browser times out or is closed.
The obvious cause is that neither the ""{{rss}}"" action nor the underlying onyx-rss class checks for //existence// of the resource the feed URL refers to. The problem is already hard to detect when you are first including a feed in a page and maybe make a typo in the feed URL. But if your Wikka provides a page with one or more feeds, and a feed suddenly disappears (or is down momentarily) the result will be very annoying for your visitors.
**Solution**: Either the onyx-rss class or the rss action should check for the availability of the feed (for instance with a HEAD request) before actually trying to retrieve it. Since the class provides caching, the best option would be to handle it in the class (by subclassing the necessary method(s)). If a version of the feed still exists in the cache that version could be displayed (probably this happens automatically anyway), otherwise an error message should be generated instead of the feed output. --JavaWoman
Another problem with Onyx-RSS was just reported by |Sam| on #wikka: in spite of cacheing it seems quite slow, taking something like 2.5 seconds for rendering after retrieving a feed (compared to a normal page rendering time of 0.06 seconds). We should look at the efficiency (or not) of this class - maybe it's time to move to another one that's being actively maintained. --JavaWoman
===Safari and WikiEdit===
(//copied from SandBox - JavaWoman//)
Safari crashes when I use a formatting button. (DarTar has confirmed this.)
It looks like either Safari has a bug in their JavaScript implementation, or WikiEdit's JavaScript isn't (sufficiently) cross-browser, or both. While the browser shouldn't crash on encountering JavaScript it cannot handle, we certainly need an edit toolbar that's more cross-browser (it doesn't appear at all in Opera 7.2x on Windows). --JavaWoman
===WantedPages problem===
The list of Wantedpages may be handy, but I just found the list is not sorted alphabetically, making it hard to scan. That's a "UI bug". The list should be sorted, at least - and preferably split up by starting letters, as in PageIndex (when all pages are shown). --JavaWoman
===passwords containing $ aren't working===
The installation succeed but the wiki doesn't work(connection pb if the db password contains one or more dollars symbols '$'.
The error occur at the creation of the wakka object :
"The wiki is currently unavailable. Error : Unable to connect to the Mysql database"
~& Did you tried to escape them? For example "john$doe" replaced by "john\$doe". AFAIK, it isn't a wikka bug but a php engine's side effect. All string beginning with $ are considered as variables and are interpreted as is. -- PivWan
~~&Solution is to simply use single quotes instead of double quotes so $ is not interpreted as the start of a variable name; involves some changes in the installer. Will likely appear in 1.1.6.1 --JavaWoman
===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?
===Spaces in uploaded files===
//Thanks to MrTrick for pointing out this problem//
It is possible to upload files with a space in the file name. However, when trying to download such a file things don't work as expected: in Mozilla browsers (Mozilla, Firefox, etc.) the suggested filename for the download is truncated at the first space.
Two possible solutions:
~1) Prevent that file names are //stored// with spaces in the name; simply replacing all spaces with underscores would do the trick and keep the file name recognizable. This has the advantage that no assumptions are being made about the server OS //or// the user's OS as to whether spaces in file names are valid.
~2) Mozilla seems to pick up the suggested file name from the Content-Disposition header. (raw)urlencoding the file name here works, but then displays the name with the encoding; enclosing the file name in (double) quotes works better, showing the full file name with spaces. This has the advantage that the original file name is preserved - //provided// both the server OS and the downloading user's OS can handle such file names.---
Take your pick ;-) -- JavaWoman
===ACL Cancel===
If you edit the ACL on a page, click "Store ACLs", then edit the ACL and click "Cancel", it still reads "Access control lists updated.", even though the changes were canceled. This is due to the "Cancel" button causing the browser to navigate backwards, and a javascript popup. --BarkerJr
===Alzheimers for Wikka?===
This is not a bug specifically - it is really a potential implentation weakness, but if a user specifies a page purge time in wikka.config: "pages_purge_time" => "100" and if that page is not edited for a while, then when that page is edited, the last copy will be deleted, leaving no archived copies at all. I think purge pages should delete old pages, but there should always be a minimum number of old copies preserved, otherwise the wiki becomes highly vulnerable to a content deletion attack. Would it be better to remove this feature, or modify it? --IanAndolina
~&Instead of removing or modifying it (the configuration parameter, rather) we could refine it by introducing an extra parameter name something like "pages_keep" to set a maximum number of pages to be kept regardless (maximum, since it could be less if there are not that many versions in the first place). Setting one or the other to 0 could disable purging altogether. --JavaWoman
~~&Sounds good to me - can you think of an elegant way to modify the SQL query to only delete pages older than X that are also more than Xth on a list of revisions. I'm sure I can come up with something ugly ;) --IanAndolina
~~~&I'm good enough at SQL that I need the manual for that. ;-) As far as I can determine, you need two statements (semi pseudo code): 1) a ##select count(*) from pages where ...## to determine the current number of records; and 2) ##delete from pages where ... order by [timestamp] limit [$count - $pages_keep]##. You can't do a subquery in delete (yet) so the count must be a separate step (but it should be very fast). --JavaWoman
===Admin email at installation===
//reported in IRC while I was asleep, sorry - JW does have to sleep sometimes//
(Potential) User extremely frustrated when at installation he's entering a real and valid email address and the Installer rejects it with "Email appears incorrect". This is caused by the extremely brain-dead Javascript in the installer that accepts **nothing but lowercase letters** to appear before the '@'. To be anywhere like realistic it should be corrected to accept numbers, dots, hyphens and underscores as well.
--JavaWoman //(hoping the reporter shows up again so I can help him with a workaround)//
~& Gosh, this is //really// annoying. JW, any news from your general-purpose [[WikkaEmailToolkit email validation]] functions ;-) -- DarTar
~~&The basic problem is that the installer does not use any system routines but instead JavaScript for validation. And the RE it uses for email validation is really, really braindead. Yes, very annoying as I've not seen the user back in #wikka either - we may have lost a user. I could have given a workaround if only I'd not been sleeping. --- Email library is not quite ready but getting close (needs some restructuring, basically); it will be a class, with several abstract methods so the installer should be able to use it as well (provided it can find the class file). And I'm learning some good tricks working on the sessions module (which might also be useful for Wikka). But the installer needs a major overhaul in any case. Sigh... --JavaWoman
===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 {{wikkaversion}}? 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
===Comments in formatted PHP code===
GeSHi has a habit of adding a trailing line if the PHP code contains a comment using ""//"" or ""#"".
For example %%(php) echo "hello world"; // How do you do?%% This does not happen if ""/* */"" is used for comments. For example %%(php) echo "hello world"; /* How do you do? */%%
-- FreekDijkstra
~&Sounds also like a GeSHi problem rather than a Wikka bug. If anyone is installing (or has installed) GeSHi 1.0.6 I'd appreciate feedback on whether this cosmetic problem is solved as well. --JavaWoman
-----
===Encoding of GeSHi===
My default installation of Wikka 1.1.6.0 did display the error
htmlentities(): charset `646' not supported, assuming iso-8859-1 in /home/www/WWW/files/research/air/wiki/3rdparty/plugins/geshi/geshi.php
on the FormattingRules page. I was able to fix this by adding the "set_encoding" line in the GeSHi_Highlight() function in wikka.php:
$geshi =& new GeSHi($sourcecode, $language, $this->config['geshi_languages_path']); # existing code
$geshi->set_encoding('UTF-8'); # set encoding (new line)%%
-- FreekDijkstra
~&This is actually not a Wikka bug, but a problem in GeSHi itself - which only appears in rare cases. See CharsetNotSupportedWorkaround for more information. I think the latest GeSHi version (1.0.6) has addressed this problem. If you'd like to try this, make sure you remove the workaround code in Wikka when installing the new GeSHi version. --JavaWoman
===User name matching===
(related to the //Category name matching// item below)
While [[RegisterActionTest testing]] the beta RegisterAction, I realized that using a username like **""DarTartar""** results in a //"Sorry, username already exists"// error. Looks like a problem in the RE used by the ##""LoadUser()""## function. I'll take a look at it ASAP.
-- DarTar
===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)
===Multiple wikka installations on one host: Login security hole?===
Okay. Say that I've installed multiple seperate installations of wikka on one host. If I do a login on wikka A, I can also
reach the pages of wikka B, whereas wikka B has an authentication table where the user account of wikka A does not exist!
My guess is that this behaviour occurs because the login cookies are set with path root. And as long the login cookies exist
Wikka doesn't care about authentication anymore??
-- JeroenJansen
~&Same problem. Is it possible to include in wikka.config.php a line in which you specify the default cookie prefix? I guess this could solve the problem. --YanB
~~&Same problem for me as well. I've modified wikka.php to use different session names (add: session_name($wakkaConfig["wakka_name"]); just above the session_start(); ) and different cookies ("wikka_user_name@".$this->config["wakka_name"] and "wikka_pass@".$this->config["wakka_name"]) as my 2 wikkas do have have different wakka_names. Seems to behave as expected now. --OlivierPerron
===Category name matching===
Yes, I know the category system needs to be revamped, but I figured I'd report this anyway. If you have a category name that is a substring of another category name, pages referencing the second category will also appear in the first. In other words...I have a category named '""CategoryBookOne"", and another named ""CategoryBookOneJournal"". Pages that reference ""CategoryBookOneJournal"" also show up in the list of pages for ""CategoryBookOne"", which is not the behavior I expected or wanted.
-- TammyCravit
~&I cannot reproduce this on this server, nor on my own development system - at least not with the [[WikkaBetaFeatures beta and alpha]] versions of the category action. Possibly dependent on the version of PHP used where older versions may use a slightly different database query to find pages referring to a category. Tammy, if you're reading this: which version of PHP are you using? (We should test with the 'lower-PHP version of the query!) --JavaWoman
===Installer problems===
Gathered from error reports in different places (including comments on WikkaInstallation, #wikka and IM) - neither new, but worth repeating and putting together, I think:
~-In at least some cases the "detected" base path misses a closing slash (resulting in links that don't work); the installer should check if the derived path has a final slash, and if not, add one, before presenting that to the user.
~-If PHP (and thus Wikka) cannot connect to MySQL the installer just "hangs" after the first screen and printing "Testing configuration"; this seems to be (at least partly) the result of having error messages from the MySQL statements suppressed with a @, which would be OK if the error message were handled afterwards - but this doesn't happen. Other mysql_xxx() calls in the installer also have the @ suppressing error messages. That should either be removed, or all error messages should be picked up and handled by the installer, at the very least by showing the message to the user. ---
~This is especially a problem for users new at MySQL or new even at PHP+MySQL for whom it won't be obvious where to start troubleshooting when the installer simply hangs.
--JavaWoman
===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
===mod_rewrite issue in WikiEdit===
When in edit mode using IIS if you click the help button the program doesn't take you to the FormattingRules page, but tries to go to the ""FormattingRules"" Directory, which does not exist.
~& It assumes that you're using mod_rewrite and goes to the "pretty" url (wikka.jsnx.com/""FormattingRules"" instead of wikka.jsnx.com/wikka.php?wakka=""FormattingRules"") - this needs to either be editable (or is it somewhere in the WikiEdit files and I just haven't found it?) or check with the wikka.config.php to make sure it's using the correct base_url. --MovieLady
===Bug in Textsearch (expanded)===
As DotMG has pointed out, the input for this two actions isn't validated, making it a security-hole.
~&You can fix it by changing the line
$phrase = stripslashes($phrase);
into
$phrase = preg_quote($this->htmlspecialchars_ent(stripslashes($phrase)), "/");
You have to change both files (textsearch and textsearchexpanded). --NilsLindenberg
===Advanced search results reveal confidential info===
Results should be hidden or not shown if the user doesn't have read access to page IMHO. --PolVazo
~& In actions/textsearch.php you can fix it by changing the following;
~& %%(php)
if ($phrase = $_REQUEST["phrase"])
{
$phrase = stripslashes($phrase);
$results = $this->FullTextSearch($phrase);
print("<br />");
$total_results = count($results);
$match_str = $total_results <> 1 ? " matches" : " match";
print("Search results: <strong>".$total_results.$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
if ($results)
{
foreach ($results as $i => $page)
{
print(($i+1).". ".$this->Link($page["tag"])."<br />\n");
}
$phrase = urlencode($phrase);
print("<br />Not sure which page to choose?<br />Try the <a href=\"".$this->href("", "TextSearchExpanded", "phrase=$phrase")."\">Expanded Text Search</a> which shows surrounding text.");
}
}
~& into
~& %%(php)
if ($phrase = $_REQUEST["phrase"])
{
$phrase = preg_quote($this->htmlspecialchars_ent(stripslashes($phrase)), "/");
$results = $this->FullTextSearch($phrase);
$result_page_list = '';
$total_results = 0;
print("<br />");
if ($results)
{
foreach ($results as $i => $page)
{
if ($this->HasAccess("read",$page["tag"]))
{
$result_page_list .= ($i+1).". ".$this->Link($page["tag"])."<br />\n";
$total_results += 1;
}
}
$phrase = urlencode($phrase);
}
$match_str = $total_results <> 1 ? " matches" : " match";
print("Search results: <strong>".$total_results.$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
if ($total_results > 0)
{
print($result_page_list);
print("<br />Not sure which page to choose?<br />Try the <a href=\"".$this->href("", "TextSearchExpanded", "phrase=$phrase")."\">Expanded Text Search</a> which shows surrounding text.");
}
}
~& Similarly, in actions/textsearchexpanded.php you can fix it by changing the following:
~& %%(php)
if (isset($_REQUEST["phrase"]) && $phrase = $_REQUEST["phrase"])
{
$phrase = stripslashes($phrase);
print("<br />");
$results = $this->FullTextSearch($phrase);
$match_str = count($results) <> 1 ? " matches" : " match";
print("Search results: <strong>".count($results).$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
$phrase = str_replace("\"", "", $phrase);
if ($results)
{
print "<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\">";
$STORE_FORMATING_AS_TEXT = 1;
foreach ($results as $i => $page)
{
//print(($i+1).". ".$this->Link($page["tag"])."<br />\n");
//print implode($this->LoadPage($page["tag"]));
//$matchString = preg_match("/(.{0,40}$phrase.{0,40})/",implode($this->LoadPage($page['tag'])));
/* display portion of the matching body and highlight
the search term */
preg_match("/(.{0,120}$phrase.{0,120})/is",$page['body'],$matchString);
$text = $this->htmlspecialchars_ent($matchString[0]);
// include("formatters/wakka.php");
$highlightMatch = preg_replace("/($phrase)/i","<font color=\"green\"><b>$1</b></font>",$text,-1);
$matchText = "<font color=\"gray\" size=\"-1\">...</font>$highlightMatch<font color=\"gray\" size=\"-1\">...</font>";
print "
<tr>
<td valign=\"top\" align=\"right\">
<!-- result number -->
<table>
<tr>
<td valign=\"top\" align=\"left\" bgcolor=\"#DDDDDD\">
<font color=\"white\" size=\"-3\">
".($i+1)."
</font>
</td>
</tr>
</table>
</td>
<!-- link -->
<td valign=\"top\">
".$this->Link($page["tag"])."
</td>
<!-- date of last update -->
<td valign=\"top\" align=\"right\">
<font color=\"gray\" size=\"-3\">
$page[time]
</font>
</td>
</tr>
<tr>
<td>
 
</td>
<td colspan=\"2\">
$matchText
</td>
</tr>
<tr>
<td>
 
</td>
</tr>
";
}
print "</table>";
}
}
~& into
~& %%(php)
if (isset($_REQUEST["phrase"]) && $phrase = $_REQUEST["phrase"])
{
$phrase = preg_quote($this->htmlspecialchars_ent(stripslashes($phrase)), "/");
print("<br />");
$results = $this->FullTextSearch($phrase);
$phrase = str_replace("\"", "", $phrase);
$result_page_list = '';
$total_results = 0;
if ($results)
{
print "<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\">";
$STORE_FORMATING_AS_TEXT = 1;
foreach ($results as $i => $page)
{
if ($this->HasAccess("read",$page["tag"]))
{
preg_match("/(.{0,120}$phrase.{0,120})/is",$page['body'],$matchString);
$text = $this->htmlspecialchars_ent($matchString[0]);
$highlightMatch = preg_replace("/($phrase)/i","<font color=\"green\"><b>$1</b></font>",$text,-1);
$matchText = "<font color=\"gray\" size=\"-1\">...</font>$highlightMatch<font color=\"gray\" size=\"-1\">...</font>";
$total_results += 1;
$result_page_list .= "
<tr>
<td valign=\"top\" align=\"right\">
<!-- result number -->
<table>
<tr>
<td valign=\"top\" align=\"left\" bgcolor=\"#DDDDDD\">
<font color=\"white\" size=\"-3\">
".($i+1)."
</font>
</td>
</tr>
</table>
</td>
<td valign=\"top\">
<!-- link -->
".$this->Link($page["tag"])."
</td>
<td valign=\"top\" align=\"right\">
<!-- date of last update -->
<font color=\"gray\" size=\"-3\">
$page[time]
</font>
</td>
</tr>
<tr>
<td> </td>
<td colspan=\"2\">$matchText</td>
</tr>
<tr>
<td> </td>
</tr>
";
}
}
$match_str = $total_results <> 1 ? " matches" : " match";
print("Search results: <strong>".$total_results.$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
if ($total_results > 0)
{
print($result_page_list);
print("</table>");
}
}
}
~& This fix also includes another fix on this page by NilsLindenberg in the "Bug in Textsearch (expanded)" section. --QualousHere
===Recent[ly]Comment[ed|s] actions should check for permission===
Comments are being previewed even if users do not have access. A simple check needs to be added. -- JsnX
if ($this->HasAccess("comment"))
~& Recent Comments: Here is an implementation of the above suggestion. NickDamoulakis
<?php
if ($comments = $this->LoadRecentComments())
{
$curday = "";
$allComments = 0; // This tracks the total number of comments found
$accessibleComments = 0; // and this one only those that we can look at
foreach ($comments as $comment)
{
$allComments++;
if ($this->HasAccess($comment))
{
$accessibleComments++;
// day header
list($day, $time) = explode(" ", $comment["time"]);
if ($day != $curday)
{
$dateformatted = date("D, d M Y", strtotime($day));
if ($curday) print("<br />\n");
print("<strong>$dateformatted:</strong><br />\n");
$curday = $day;
}
$timeformatted = date("H:i T", strtotime($comment["time"]));
$comment_preview = str_replace("<br />", "", $comment["comment"]);
$comment_preview = substr($comment_preview, 0, 125);
if (strlen($comment["comment"]) > 120) $comment_preview = $comment_preview.".... ";
// print entry
print("   ($timeformatted) <a href=\"".$this->href("", $comment["page_tag"], "show_comments=1")."#comment_".$comment["id"]."\">".$comment["page_tag"]."</a> . . . . ".$this->Format($comment["user"])."<br />\n       <em>$comment_preview</em><br />\n");
}
}
// If we are only showing a portion of the comments, tell the user so.
if ($accessibleComments != $allComments)
{
Echo "<br><hr>You are only shown comments that you have access to.";
}
}
else
{
print("<em>No recent comments.</em>");
}
?>%%
~& Recently Commented: Here is an implementation of the above suggestion. NickDamoulakis
<?php
if ($comments = $this->LoadRecentlyCommented())
{
$curday = "";
$allComments = 0; // This tracks the total number of comments found
$accessibleComments = 0; // and this one only those that we can look at
foreach ($comments as $comment)
{
$allComments++;
if ($this->HasAccess($comment))
{
$accessibleComments++;
// day header
list($day, $time) = explode(" ", $comment["time"]);
if ($day != $curday)
{
$dateformatted = date("D, d M Y", strtotime($day));
if ($curday) print("<br />\n");
print("<strong>$dateformatted:</strong><br />\n");
$curday = $day;
}
$timeformatted = date("H:i T", strtotime($comment["time"]));
$max_preview_length = 122;
$comment_preview = str_replace("<br />", "", $comment["comment"]);
if (strlen($comment_preview) > $max_preview_length) {
$comment_spillover_link = "<a href=\"".$this->href("", $comment["page_tag"], "show_comments=1")."#comment_".$comment["id"]."\" title=\"View comment\">[.... ]</a>";
$comment_preview = substr($comment_preview, 0, $max_preview_length).$comment_spillover_link;
}
$commentlink = "<a href=\"".$this->href("", $comment["page_tag"], "show_comments=1")."#comment_".$comment["id"]."\" title=\"View comment\">".$comment["page_tag"]."</a>";
$comment_by = $comment["user"];
if (!$this->LoadUser($comment_by)) $comment_by .= " (unregistered user)";
// print entry
print("    $commentlink, comment by $comment_by: <br />\n         <em>$comment_preview</em><br />\n");
}
}
// If we are only showing a portion of the comments, tell the user so.
if ($accessibleComments != $allComments)
{
Echo "<br><hr>You are only shown comments that you have access to.";
}
}
else
{
print("<em>There are no recently commented pages.</em>");
}
?>
===tags in the edit notes===
I made a edit note: "removed a <?php (to much)" and got "removed a". Perhaps replacing <> would be the better option? --NilsLindenberg
~&Funny - I just stumbled over the same problem - only in the RecentChanges newsfeed: the <?php causes imbalanced tags there, and thus a syntax error: until that post has "aged" off of the feed, it can't be loaded any more! The [[http://feedvalidator.org/check?url=http%3a%2f%2fwikka.jsnx.com%2fRecentChanges%2frecentchanges.xml validation result]] clearly shows what the problem is. So yes, edit notes should be fed threough htmlspecialchars[_ent]() everywhere they're presented, and that includes the RSS feed! --JavaWoman
~~&And the WikiPing, too :) --NilsLindenberg
~&Oh is **that** what you removed Nils. I couldn't figure out using history what you did. Where did you take it from? And why? Did I have one more <?php than was necessary? In which code block? --GmBowen
~~&It was at the beginning of mail.php: %%(php) <?php <?php%%. I guess you overlooked it when you copied your new version to the page. Happened to me in another case, too. --NilsLindenberg
~&Actually, the problem is not just with tags; any XML "special character" is going to cause an XML error. All will need to be escaped to ensure the RSS feeds and pings are valid XML. (We are having a problem again...) --JavaWoman
~~&Fixed now: Code changes in wikka.php (GetPingParams()), actions/recentchanges.php, handlers/page/recentchanges.xml.php, handlers/page/recentchanges.xml.mm.php, handlers/page/revisions.php and handlers/page/revisions.xml.php. Installed on this server as "beta test" so we can watch behavior. --JavaWoman
===Missing language-support in the code formatter===
(copied from the sandbox --NilsLindenberg)
not support 2byte language in the Code formatters!!!!
%%(c)
// 한글이 깨지겠지
// 진짜 깨지네.. 흑흑.. 에디터창에서 깨지는 것도 열받는데..
...
===Error on ./handlers/page/referrers_sites===
Line 46 :
- Code generates a double </a> for links.
- & in URL should be replaced by &amp;
=> %%(php) print("<td valign=\"top\">" . (($site != "unknown") ? "<a href=\"http://".$this->htmlspecialchars_ent($site)."\">".$this->htmlspecialchars_ent($site)."</a>" : $site) . /*"</a> ".*/($IsAdmin ? "[<a href=\"".$this->href("delete_referrer", "", "spam_site=").$this->htmlspecialchars_ent($site)."&redirect=".$this->GetMethod()."\">Blacklist</a>]" : "")."</td>");%%
Note: You cannot see this error by validating directly a page because W3C is not registered and it will not have the same output as you, in other words, code on line 46 won't be executed. But you can save the page on your hard disk and validate it.
--DotMG
===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
===Accept-Encoding: gzip;q=0, deflate===
**Not really bug, but should be corrected for respect & compliance to RFC2616**
If a browser sends the header
Accept-Encoding: gzip;q=0, deflate
Which should be interpreted as : "I don't support gzip encoding, but I prefer deflate", Wikka will understand "The browser supports gzip-encoding", as it just searches for the text gzip in $_SERVER['HTTP_ACCEPT_ENCODING']. An example I use to treat it correctly is :
%%(php) function ParseHeaderLine($hl, $token=null)
{
$ar_hl = explode(',', $hl);
foreach ($ar_hl as $dotmg_idx => $val)
{
if (preg_match('/^\s*(.*?);\s*q\s*=\s*([0-9\.]*)/i', $val, $match))
{
$res[strtolower($match[1])] = doubleval($match[2]);
}
else
{
$res[strtolower($val)] = 1;
}
}
if ($token) return(isset($res[$token]) && ($res[$token] > 0)); #if $token is set, we return true or false
return ($res); # else we return the header parsed.
}%%
and
%%(php) if ($this->ParseHeaderLine($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ...%%
Note : This function might be useful to deal also with Accept-Language, when Wikka will be made effectively multilingual.
--DotMG
===1.1.6.0beta4: Simplified Chinese (or Unicode relative) in WikiEdit:===
A page contains unicode characters looks OK when viewed but displays ""''&#*****;''"" while edited in WikiEdit
Simplified Chinese Test:
中文是一种美丽的语言,除了具有音节上的美感,同样拥有视觉上的美感
In 1.1.5.3, I solved this problem by changed some line in ./handlers/page/edit.php
#from
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$body."</textarea><br />\n"
#to
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$this->htmlspecialchars_ent($body)."</textarea><br />\n"
Wikka is wonderful! ZhuangYuyao
~&This workaround you outlined will work as well in Wikka 1.1.6.0. A real solution wil take some more investigation though, so we were unable to fix this for the current release. This is now under investigation. --JavaWoman
===Double-click editing===
I noticed: Turning off DoubleClick-editing does not work (double-clicks still go to edit-window) in IE 6.0 or Firefox 1.0.
Keep up the good work!
Cheers, MarkHissinkMuller
~&Yes, I noticed the same thing. This is a bug as of 1.1.6.0. --RyanKnoll
~~&Heres the fix:
~~&add as **first** line in handlers/page/show.php:
~~&%%(php;1)
<?php $user = $this->GetUser(); ?>
~~&and change the second line to:
~~&%%(php;2)
<div class="page" <?php echo ((!$user || ($user["doubleclickedit"] == 'Y')) && $this->GetMethod
() == "show") ? "ondblclick=\"document.location='".$this->href("edit")."';\" " : "" ?>>
~~&--NilsLindenberg
There is another issue with double-click editing: while registered users can edit their preferences to use double-click editing or not, it is always on for non-registered (or not logged-in) users. The result is that on pages that can be edited only by registered users, a double-click results in an unfriendly error message. Especially on a site that is mostly read-only for visitors this is a bad situation. The solution is to make this admin-configurable.
Add to wikka.config.php:
%%(php) "doubleclickedit" => "Y", # set to "N" to disable double-click editing%%
and change the proposed line for the show handler above to:
%%(php;2)<div class="page" <?php echo (((!$user && $this->config['doubleclickedit'] == "Y") || ($user['doubleclickedit'] == 'Y')) && $this->GetMethod
() == "show") ? "ondblclick=\"document.location='".$this->href("edit")."';\" " : "" ?>>
%%--- --JavaWoman
~&In that case, wouldn't you want new profiles to have dblclick turned off by default ? (TroelsKnakNielsen)
===$_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
===PageIndex problem===
DarTar and I have recently created some test pages, testing page names related to how Wikka evaluates 'valid' page names: ,My,Page and ÄhnLich (yes, they both exist, even if they don't show up as such in this sentence!). Now look at where they show up on PageIndex... surely there shouldn't be **two** '#' indices??
--JavaWoman
~&I think that this is due to the encoding of the MySQL tables. I can't see how that would be fixed with a small touch on the code. If this is the matter then I hope that it also rings the i18n bell too. //Translation to Greek is my bussiness ;)// --GeorgePetsagourakis
~~&Yes, my i18n bells were already loudly ringing... but you bring up a good point with MySQL. I hadn't thought about a real cause yet, just wanted to record what I saw before I got distracted again ;-). Sort order is a whole subject of its own within i18n .... --JavaWoman
===Install Note on Basic URL and CSS===
First, this may applied to my ISP only. When I installed, I have to use
the ?wakka= options. However, I have to add a / to the end of the
default Basic URL before append ?wakka= to it. So I think it maybe
helpful to modify the instruction to '... so it should include
the "/?wakka=" parameter...'
~&ArpY: Maybe this is caused by a config error. Please have a look at your config - is there a slash at the end of the base_url?
~~&IMO the installer should take care that there is a slash if the user doesn't enter it --JavaWoman
===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
===Weirdness with Include===
Um, I don't know how to describe this really. Put ""{{include page="Category Documentation"}}"" (//without the space!//)on the SandBox page....I can't figure out why it gives that output as Sandbox doesn't own anything.
~&Looks like the weirdness is caused by the ""{{Category}}"" action which assumes the "current page" represents the category - and find pages "belonging to" a category by finding a mention of that page name. Good sign our category system does need an [[CategorySystemOverhaul overhaul]]! --JavaWoman
~&Include pulls in a page that itself has the category action on it; the "official" version of this action assumes that the page it occurs on **is** a category. The "//experimental//" category action that is now active on this site no longer makes this assumption but recognizes that SandBox isn't a category page and defaults to the top category. See Sandbox for a an example (at this moment). --JavaWoman
~~&I can see that it now works, but what do you mean that it "recognizes that Sandbox isn't an action".....do you mean target page? --GmBowen
~~~&Oops, sorry (corrected now) - I meant the new category action sees whether the page it's "sitting" on is a category page or not - if not it defaults to showing the list for the top-level category. --JavaWoman (aka IamBack)
===Backlinks / ""LoadPagesLinkingTo()""===
I just discovered that the ##""{{backlinks}}""## action may list pages that don't "exist" any more, in the sense that they (apparently) still are in the database but without any active version (seemingly as a result of a rename action. I added an example on [[JavaWoman my own page]] where you can see a supposed backlink from ReleaseNotes (which was replaced by WikkaReleaseNotes).
~&The cause is apparently in the ""LoadPagesLinkingTo()"" method which is used by ##""{{backlinks}}""## action. It currently is implemented like this:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' order by tag"); }
%% I think replacing this by:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' and latest = 'Y' order by tag"); }
%% might do the trick to avoid deceased pages - but please test!
~&--JavaWoman
~~&It wont do, since the link-table has no latest col ;). But shouldn't the delete-handler delete these links from the table anyway? --NilsLindenberg
~~~&Indeed it is the delete handler that is at fault here by not deleting all records from the links table that refer to the (to be) deleted page. This is simple enough to fix (by extending the query a little to match both the "from_tag" and "to_tag" columns) but for a future version to be released with such a fix there should also be an (admin-only) utility to clear left-behind records from the links table that //should// have been deleted before. --JavaWoman
====GetEnv is not a good idea!====
At ./wikka.php, you will see a line %%(php)<?php if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";?>%%
In the most cases, a website is hosted in a machine as a VirtualHost, this means that a number of websites share the same environment variables. If someone knows where your site is hosted, he can put his site at the same server, and use a script containing %%(php)<?php putenv('WAKKA_CONFIG=/home/hacker/config.php');?>%%. And all wikka sites on the same server will use his configuration file. The rest actions to take to hack your site will be as easy as eating sandwich.
Php doc says that an environment variable is altered only during the life of the script, but with my dev Easyphp's on windows, that is false. (I think a "new" environment variable keep its value, even on Linux).
I wanted to make a unique Wikka interface used by 3 sites on the same server. The best secure solution I found is to alter ./wikka.php like this :
%%(php)<?php
if (file_exists("wakka.config.php")) rename("wakka.config.php", "wikka.config.php");
#if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";
if (!$configfile && isset($GLOBALS['wikka_config'])) $configfile = $GLOBALS['wikka_config'];
if (!$configfile) $configfile = "wikka.config.php";
if (file_exists($configfile)) include($configfile);
and put the 2 files sitenumber2.php and .htaccess below at the root of the server number 2:
__sitenumber2.php:__
%%(php)<?php
$GLOBALS['wikka_config'] = "/path/to/altered_config.php";
chdir("/path/to/basewikka");
include('wikka.php');
?>%%
__.htaccess:__
%%<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.*/[^\./]*[^/])$ $1/
RewriteRule ^(css|images|wikiedit2)/(.*)$ /path/to/basewikka/$1/$2 [L]
RewriteRule ^(.*)$ sitenumber2.php?wakka=$1 [QSA,L]
</IfModule>%%
--DotMG
~&I've now written up my thoughts about a [[WikkaSecureConfig more secure way to handle Wikka's configuration]] (which should also provide also more flexibility). --JavaWoman
===Expanded Text Search fails===
I tried an expanded Text-Search after [[http://wikka.jsnx.com/TextSearchExpanded?phrase=%2Bparameter+%2Blink +parameter +link]] and got the following error:
"Warning: Compilation failed: nothing to repeat at offset 1 in /.../actions/textsearchexpanded.php on line 33"
for every page.
--NilsLindenberg
~&In my recent RE exploits I have found that a warning of this type comes up when a regular expression isn't quite correct (though not every attempt to match may bring up the warning); haven't investigated further in textsearchexpanded.php though. --JavaWoman
~&Php has a function : preg_quote that may help us. Or try this solution : DotMGTextSearchExpanded
-----
=== Yet more formatter bugs ===
Looking at **formatters/wikka.php** to find the cause of the two bugs listed below (found one), I notice to my horror that a **lot** of the regular expressions used there are actually incorrect. They allow such things as using a comma to indent a line (in addition to a tab, or ~, at the start of a line: **demo** in the SandBox, and in the list **below**!), or a comma in a WikiName (even at the start) or in an InterWiki link. That can't have been the intention - it's simply a matter of incorrect RE syntax. I'd become sort of "sensitized" to this phenomenon looking at DarTar's RE on ValidPageNames earlier today - now I see where he found an example (see my comment on that page on his RE!).
''See also [[,My,Page]] - yup, that's a real page now. ;-)''
~&Rather than simply fixing all the REs (and other REs all over the place...) I'd like to propose a more fundamental solution:
~&-create a "library" of RE building blocks to be used in the Wikka core (for an example of what I mean with building blocks see my propopsal for an alternative RE on ValidPageNames); simply create a separate file with define()s for these building blocks, and include them at the start of the main wikka.php file;
~&-gather all RE used in the Wikka core here (extensions/plugins could have their own set of defines - as long as they don't have conflicting names);
~&-now use **only** these building blocks when using REs anywhere in the Wikka core.
~&This should make it much easier to create both //correct//, and //consistent// regular expressions; any (near)duplicates will be much easier to discover, and fix.
~&
~&Probably best to leave this to just **after** the coming release, so we have a stable code base again. I volunteer to undertake this work. (Unlike some people, I happen to like REs.) :)
~&--JavaWoman
=== 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
~&Possible clue:
~&I just stumbled over the fact that the little list of "Useful pages" at the end of the default (installation-generated) ""HomePage"" had incorrect coding: The last list item (li) was not terminated, nor was the list itself (no closing ul tag). It took me a bit of trial and error to reproduce this - but have a look at my test code at the end of SandBox (now). Originally I thought that any list at the end of a page would be unterminated, but that turned out not to be the case. Then I hit on something else: the last list element on that default ""HomePage"" (not the one here) ands with a period. My test version on SandBox now also has the last element ending in a period ... and if you look at the (HTML) page source, you'll see it is indeed an unterminated list. Somehow that ending period (maybe in combination with end-of-page?) causes the Formatter never to close the list; take that ending period away, and it works normally. I tried a few variants, to check whether it might be an odd-even problem, but no: whether the number of list items is odd or even, if the last one ends in a period, the list isn't terminated.
~&
~&No difference whether it's anordered (ol) or unordered (ul) list, the formatter behaves the same way.
~&
~&And, BTW, if you look at the preview when editing, the HTML source of the **preview** actually contains a lot of Wiki code that shouldn't be there!
~&
~&I haven't dug in the Formatter yet to find the cause or whether end-of-page makes a difference...
~&--JavaWoman
~~&This is indeed an "end of page" problem: teh formatter has some code to close tags inadvertently left open, but does not do this for lists and indent (nor even fro *all* open tags). Fix coded and tested - this will be in 1.1.6.1. --JavaWoman
=== 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
~~&I'm running MySQL 5 fine with the mysql_* functions. When you compile PHP, it's your choice to compile the mysql_* or mysqli_* functions. I chose to compile it with mysql_*, which is working fine for me. --BarkerJr
==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 "**dan**gerous" - 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
===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
===Windows Paths With ""{{files}}"" Action===
On a Windows/IIS installation, including the ""{{files}}"" action causes errors similar to the following:
Warning: mkdir(uploads\SandBox): Permission denied in D:\sitepath\wwwroot\wikka\actions\files.php on line 12
Warning: opendir(uploads\SandBox): failed to open dir: Invalid argument in D:\sitepath\wwwroot\wikka\actions\files.php on line 156
Warning: readdir(): supplied argument is not a valid Directory resource in D:\sitepath\wwwroot\wikka\actions\files.php on line 157
Warning: closedir(): supplied argument is not a valid Directory resource in D:\sitepath\wwwroot\wikka\actions\files.php on line 200
This is caused by the assumption of "/" as the directory seperator instead of Window's "\". Using the DIRECTORY_SEPARATOR variable corrects this is.
In actions/files.php change:
$upload_path = $this->config['upload_path'].'/'.$this->GetPageTag();
%% into
$upload_path = $this->config['upload_path'].DIRECTORY_SEPARATOR.$this->GetPageTag();
and also:
$destfile = $upload_path.'/'.$strippedname;
%% into
$destfile = $upload_path.DIRECTORY_SEPARATOR.$strippedname;
Warning: This has only been tested so far under Windows. -- QualousHere
CategoryDevelopmentSuggestions


Revision [12091]

Edited on 2005-12-03 11:15:48 by NilsLindenberg [reply to anonymus]
Additions:
~&Details like the versions of your IE, your webserver and Mysql (and perhaps a link to the page) would be helpfull! NilsLindenberg


Revision [12090]

Edited on 2005-12-03 01:42:23 by FireLy [reply to anonymus]
Additions:
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.
Deletions:
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


Revision [12089]

Edited on 2005-12-03 01:38:01 by FireLy [reply to anonymus]
Additions:
===the Blank on IE browser===
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


Revision [12071]

Edited on 2005-11-30 21:04:15 by MikeECuffe [removed my bug. problem was not wikki related]
Deletions:
===problems after moving database from mysql version 5 to mysql 4.1.14===
I needed to migrate to mysql4 to use another application so I exported the DB with mysqldump --mysql40 and imported it to the empty mysql 4.1.14 and everything was fine. I could read and logon to the wikki.
The next day I edited a page and put a ':' into the comment field - something I no not to do again until the new release comes out - anyway the wikki burped so I modified the mysql page entry {3030_pages.latest='Y' & 3030_pages.id=63} as the id was set to 0 and the latest ws N (both default values).
so since then I keep getting (duplicate key id (0) ) errors.
I looked on the wikki for any mysql issues but didn't see any about migrating db's - does anyone have any idea what I can do?
Thank a million MikeECuffe


Revision [12055]

Edited on 2005-11-30 00:00:57 by MikeECuffe [removed my bug. problem was not wikki related]
Additions:
===problems after moving database from mysql version 5 to mysql 4.1.14===
I needed to migrate to mysql4 to use another application so I exported the DB with mysqldump --mysql40 and imported it to the empty mysql 4.1.14 and everything was fine. I could read and logon to the wikki.
The next day I edited a page and put a ':' into the comment field - something I no not to do again until the new release comes out - anyway the wikki burped so I modified the mysql page entry {3030_pages.latest='Y' & 3030_pages.id=63} as the id was set to 0 and the latest ws N (both default values).
so since then I keep getting (duplicate key id (0) ) errors.
I looked on the wikki for any mysql issues but didn't see any about migrating db's - does anyone have any idea what I can do?
Thank a million MikeECuffe


Revision [11991]

Edited on 2005-11-24 14:03:05 by DarTar [moving solved bugs]
Deletions:
===##""GetCookie()""## bug===
The ##""GetCookie()""## method in ##wikka.php## does not check whether a named cookie actually exists; this results in a NOTICE and then even partially unstyled pages; this turned up with the (beta) skins feature. (That's why I call a notice a "lurking bug". :))
Fixed already on this site; in wikka.php, change:
%%(php;599) function GetCookie($name) { return $_COOKIE[$name]; }
---to:
%%(php) function GetCookie($name)
if (isset($_COOKIE[$name]))
return $_COOKIE[$name];
else
return FALSE;
--- I've also made corresponding changes to ##actions/editskin.php##, ##actions/header.php##, ##actions/myskin.php##, ##actions/selectskin.php## and ##actions/skin.php## in the beta versions as implemented on this server. (See also WikkaBetaFeatures.) --JavaWoman
===WikiEdit : Ctrl+5 executed twice===
When I type Ctrl+4 (**h4**), the current line is surrounded by ""==="" and ""==="", that's OK. But when I type Ctrl+5 (**h5**), What I get is ""===="" and ""===="", as if I've typed Ctrl+3. On a relatively slow computer, I saw that the WikiEdit engine added ""=="" twice. --DotMG
~&Confirmed - we'll look into this. --JavaWoman
I saw the source of the problem : Find the checkKey() prototype in file ##protoedit.js##, and just add "##""k==53+2048 ||""##":
%%(javascript)ProtoEdit.prototype.checkKey = function (k) {
if (k==85+4096 || k==73+4096 || k==49+2048 || k==50+2048 || k==51+2048 || k==52+2048 || k==53+2048 ||
k==76+4096 || k==76+2048 || k==78+2048 || k==79+2048 || k==66+2048 || k==83+2048 ||
===Problem with handlers===
I noted this problem with handlers. If you specify, for example
http://url/wiki/?wakka=HomePage/../../index
You can trick the include out of the /handlers/page directory. I'm not sure it can be a problem, but indeed it's weird.
--MunehiroYamakawa
~& There's a bug in the ##Method()##-method in wikka.php.
~& The calls to ##strstr()## and ##strrpos()## have a wrong order of arguments. I think, it can be a **security issue**, since we have access to arbitrary .php-files on the server. Even user-uploaded ones...
~& See fix below.
~& Change line 795 in wikka.php to
~& %%(php) if (strstr($method,'/')) %%
~& And line 797 to
~& %%(php) $method = substr($method, strrpos($method, '/' )+1); %%
~& -- PhilippAHartmann


Revision [11990]

Edited on 2005-11-23 23:05:26 by WikkaNewbie [moving solved bugs]
Additions:
~~& 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.
Deletions:
~& 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.


Revision [11989]

Edited on 2005-11-23 23:04:08 by WikkaNewbie [moving solved bugs]

No Differences

Revision [11988]

Edited on 2005-11-23 23:02:19 by WikkaNewbie [moving solved bugs]
Additions:
~& 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.


Revision [11986]

Edited on 2005-11-23 17:22:52 by NickDamoulakis [moving solved bugs]
Additions:
~& Recent Comments: Here is an implementation of the above suggestion. NickDamoulakis
if ($comments = $this->LoadRecentComments())
$curday = "";
$allComments = 0; // This tracks the total number of comments found
$accessibleComments = 0; // and this one only those that we can look at
foreach ($comments as $comment)
$allComments++;
if ($this->HasAccess($comment))
$accessibleComments++;
// day header
list($day, $time) = explode(" ", $comment["time"]);
if ($day != $curday)
$dateformatted = date("D, d M Y", strtotime($day));
if ($curday) print("<br />\n");
print("<strong>$dateformatted:</strong><br />\n");
$curday = $day;
$timeformatted = date("H:i T", strtotime($comment["time"]));
$comment_preview = str_replace("<br />", "", $comment["comment"]);
$comment_preview = substr($comment_preview, 0, 125);
if (strlen($comment["comment"]) > 120) $comment_preview = $comment_preview.".... ";
// print entry
print("   ($timeformatted) <a href=\"".$this->href("", $comment["page_tag"], "show_comments=1")."#comment_".$comment["id"]."\">".$comment["page_tag"]."</a> . . . . ".$this->Format($comment["user"])."<br />\n       <em>$comment_preview</em><br />\n");
// If we are only showing a portion of the comments, tell the user so.
if ($accessibleComments != $allComments)
Echo "<br><hr>You are only shown comments that you have access to.";
else
print("<em>No recent comments.</em>");
~& Recently Commented: Here is an implementation of the above suggestion. NickDamoulakis
if ($comments = $this->LoadRecentlyCommented())
$curday = "";
$allComments = 0; // This tracks the total number of comments found
$accessibleComments = 0; // and this one only those that we can look at
foreach ($comments as $comment)
$allComments++;
if ($this->HasAccess($comment))
$accessibleComments++;
// day header
list($day, $time) = explode(" ", $comment["time"]);
if ($day != $curday)
$dateformatted = date("D, d M Y", strtotime($day));
if ($curday) print("<br />\n");
print("<strong>$dateformatted:</strong><br />\n");
$curday = $day;
$timeformatted = date("H:i T", strtotime($comment["time"]));
$max_preview_length = 122;
$comment_preview = str_replace("<br />", "", $comment["comment"]);
if (strlen($comment_preview) > $max_preview_length) {
$comment_spillover_link = "<a href=\"".$this->href("", $comment["page_tag"], "show_comments=1")."#comment_".$comment["id"]."\" title=\"View comment\">[.... ]</a>";
$comment_preview = substr($comment_preview, 0, $max_preview_length).$comment_spillover_link;
$commentlink = "<a href=\"".$this->href("", $comment["page_tag"], "show_comments=1")."#comment_".$comment["id"]."\" title=\"View comment\">".$comment["page_tag"]."</a>";
$comment_by = $comment["user"];
if (!$this->LoadUser($comment_by)) $comment_by .= " (unregistered user)";
// print entry
print("    $commentlink, comment by $comment_by: <br />\n         <em>$comment_preview</em><br />\n");
// If we are only showing a portion of the comments, tell the user so.
if ($accessibleComments != $allComments)
Echo "<br><hr>You are only shown comments that you have access to.";
else
print("<em>There are no recently commented pages.</em>");


Revision [11984]

Edited on 2005-11-23 15:15:43 by NickDamoulakis [moving solved bugs]
Additions:
===Retrieving user-information (Session Leakage)===
I think this is called a session leakage, anyone knows of a solution to this.
There are more places this bug makes itself known.
Deletions:
===Retrieving user-information (Session Likage)===
I think this is called a session likage, anyone knows of a solution to this.
There is more places this bug makes itself known.


Revision [11977]

Edited on 2005-11-23 10:58:18 by DarTar [re: localhost]
Additions:
~& 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
Deletions:
~& 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. -- DarTar


Revision [11976]

Edited on 2005-11-23 10:57:19 by DarTar [re: localhost]
Additions:
~& 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. -- DarTar


Revision [11975]

Edited on 2005-11-23 09:56:30 by WikkaNewbie [re: localhost]

No Differences

Revision [11974]

Edited on 2005-11-23 09:55:26 by WikkaNewbie [re: localhost]
Additions:
===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?


Revision [11951]

Edited on 2005-11-22 23:38:35 by DarTar [less funky box]
Additions:
""<div style="width:46%; float:center; padding:5px; background-color:#FEE; border:1px solid #EDD"><h5>New Wikka Tracker available</h5><p>We are happy to announce that Wikka has just opened a dedicated <a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a>. We are currently migrating open issues, bugs and feature requests from this site to the new server. Should you need to report new bugs/issues, you are invited to use the new tracker. Thanks for your understanding.</p></div>""
Deletions:
""<div style="width:50%; float:center; padding:5px; background-color:#F66; border:1px solid #F33"><h5>New Wikka Tracker available</h5><p>We are happy to announce that Wikka has just opened a dedicated <a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a>. We are currently migrating open issues, bugs and feature requests from this site to the new server. Should you need to report new bugs/issues, you are invited to use the new tracker. Thanks for your understanding.</p></div>""


Revision [11891]

Edited on 2005-11-17 16:06:16 by DarTar [re: BrendonB]
Additions:
~& Brendon, it's true that Wikka development has slowed down the last months. There is no date yet for the next release, but things should start to move faster: we have recently set up some [[http://wush.net/trac/wikka tools]] to enable a better tracking of new features/bugfixes. This should make the release procedure faster and more frequent. In the meantime, you might want to check out [[http://dartar.free.fr/code this]]. -- DarTar


Revision [11879]

Edited on 2005-11-17 01:59:36 by BrendonB [re: BrendonB]
Additions:
===Release Including All Patches===
I have found this program to be very nice, but it requires a lot of searching this wiki and hacking to get a current version. When can we expect a nicely packaged release?
In arguement for this release, it would speed up community adoption, offer some stability to the mindset of users out there, as well as other benefits.
The SF.net page is also not active give others a negative impression.


Revision [11801]

Edited on 2005-11-11 21:38:02 by DarTar [announcing Wikka tracker]
Additions:
""<div style="width:50%; float:center; padding:5px; background-color:#F66; border:1px solid #F33"><h5>New Wikka Tracker available</h5><p>We are happy to announce that Wikka has just opened a dedicated <a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a>. We are currently migrating open issues, bugs and feature requests from this site to the new server. Should you need to report new bugs/issues, you are invited to use the new tracker. Thanks for your understanding.</p></div>""
Deletions:
""<div style="width:60%; float:center; padding:5px; background-color:#F66; border:1px solid #F33"><h5>New Wikka Tracker available</h5><p>We are happy to announce that Wikka has just opened a dedicated <a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a>. We are currently migrating open issues, bugs and feature requests from this site to the new server. Should you need to report new bugs/issues, you are invited to use the new tracker. Thanks for your understanding.</p></div>""


Revision [11797]

Edited on 2005-11-11 18:45:44 by DarTar [announcing Wikka tracker]
Additions:
""<div style="width:60%; float:center; padding:5px; background-color:#F66; border:1px solid #F33"><h5>New Wikka Tracker available</h5><p>We are happy to announce that Wikka has just opened a dedicated <a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a>. We are currently migrating open issues, bugs and feature requests from this site to the new server. Should you need to report new bugs/issues, you are invited to use the new tracker. Thanks for your understanding.</p></div>""
Deletions:
{{lastedit show="3"}}


Revision [11665]

Edited on 2005-11-05 22:09:40 by IceT [announcing Wikka tracker]
Additions:
===PasswordForgotten / emailpassword problem with Konqueror (Form-Action missing)===
Hi! I've found that in Konqueror the PasswordForgotten-script doesnt work! It's because in ##actions/emailpassword.php## on lines 41 and 51
%%(php)$form = "<form name=\"getwikiname\" action=\"\" method=\"post\">";%%
the action-attribute of the <form>-tag is missing. It works without any problems in any browser I've checked with (actually Firefox 1.0.7 and Konqueror 3.4.1) when I change both lines to
%%(php)$form = "<form name=\"getwikiname\" action=\"".$this->href()."\" method=\"post\">";%%
Found this bug in Wikka 1.1.6.0 and don't see any reason why not to change this for better browser-compatibility...
Regards, IceT


Revision [11601]

Edited on 2005-10-27 03:16:45 by GiorgosKontopoulos [announcing Wikka tracker]
Additions:
If one has accounts in two different Wikka wiki's sites then changing the skin in one will affect the active skin in the other
Or if you log in/log out in one you find yourself logged in or logged out in the other.
tested it using
1) 2 Wikka engines, same server, using FF1.0.6, had same userName and pass on both
behaves as stated above.
2) 2 Wikka engines, same server, using FF1.0.6, using userA on the one installation
the other installation thinks I am userA but does not actually let me see pages only allowed to userA.
3) jsnx.wikka.com and my test installation using FF1.0.6, had same userName and pass on both
it runs ok it seems.
-GiorgosKontopoulos Oct. 27, 02:09:21 UTC
Deletions:
If one has accounts in two different Wikka wiki's sites then changing the skin in one will affect the active skin in the other (at least if browsing them simultanesously with the same Browser)


Revision [11600]

Edited on 2005-10-27 02:40:15 by GiorgosKontopoulos [Update to Session Likage]
Additions:
===Retrieving user-information (Session Likage)===
__Update__
There is more places this bug makes itself known.
If one has accounts in two different Wikka wiki's sites then changing the skin in one will affect the active skin in the other (at least if browsing them simultanesously with the same Browser)
Not a terrible bug but may have other implications still hidden.
Deletions:
===Retrieving user-information===


Revision [11457]

Edited on 2005-10-18 10:51:52 by TomSmith [Update to Session Likage]
Additions:
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)
..... I don't get this... but hey, if it works...


Revision [11454]

Edited on 2005-10-17 10:16:57 by TomSmith [Update to Session Likage]
Additions:
===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


Revision [11302]

Edited on 2005-10-07 22:31:46 by GiorgosKontopoulos [clean up link to StayingLoggedIn after NilsLindenberg moving bug here]
Additions:
-GiorgosKontopoulos (look also at "Multiple wikis ... Login security hole?" later down the page)
Deletions:
-GiorgosKontopoulos
~&Something relative: session likage described as "security hole" in StayingLoggedIn --GiorgosKontopoulos


Revision [11301]

Edited on 2005-10-07 14:34:27 by NilsLindenberg [bug from StayingLoggedIn + layout]
Additions:
===Retrieving user-information===
//moved from StayingLoggedIn. NilsLindenberg//
if you don't log out, then with a simple
echo "<PRE>_REQUEST =";print_r($_REQUEST)."</PRE>";
you can see the user's username and pass (md5'ed of course)
_REQUEST =Array
[skin] => xxxxxx.css
[PHPSESSID] => xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[wikka_user_name] => xxxxxx
[wikka_pass] => xxxxxxxxxxxxxxxxxxxxxxxxxx
I think this is called a session likage, anyone knows of a solution to this.
Perhaps a solution to this would be changing the name of the session that a particular wikka installation uses,
The name could be a random number/word passed from md5 this way its unique to each wikka installation.
Also changing the path that the session data are stored maybe helpful. (I have seen discussions on this I think on php.net session_name() or session_start() )
I don't really know the implications of this bug are (maybe its not even a bug), perhaps people can see the session data on shared hosts and that is really what concerns me.
-GiorgosKontopoulos
Not sure if this is truly a bug, but I have a number of wikka installations,. each in different (peer) directories on a server, each using different DB's. Now, each has a user named SeanOttey, and if I go log in at site A, then go to site B, I am shown as logged in, but with the other site's user info (i.e. email, password, settings). Potentially, this might create accessibility that an admin did not intend, yes? thanks! Sean.
Deletions:
Not
sure if this is truly a bug, but I have a number of wikka installations,. each in different (peer) directories on a server, each using different DB's. Now, each has a user named SeanOttey, and if I go log in at site A, then go to site B, I am shown as logged in, but with the other site's user info (i.e. email, password, settings). Potentially, this might create accessibility that an admin did not intend, yes? thanks! Sean.


Revision [11296]

Edited on 2005-10-07 00:47:06 by PhilippAHartmann [Added fix for handler-path issue (now really)]
Additions:
~& %%(php) if (strstr($method,'/')) %%
Deletions:
~& %%(php) $method = substr($method, strrpos('/', $method)); %%


Revision [11293]

Edited on 2005-10-07 00:44:41 by PhilippAHartmann [Adding fix for handler-path sanitization]
Additions:
~& There's a bug in the ##Method()##-method in wikka.php.
~& The calls to ##strstr()## and ##strrpos()## have a wrong order of arguments. I think, it can be a **security issue**, since we have access to arbitrary .php-files on the server. Even user-uploaded ones...
~& See fix below.
~& Change line 795 in wikka.php to
~& %%(php) $method = substr($method, strrpos('/', $method)); %%
~& And line 797 to
~& %%(php) $method = substr($method, strrpos($method, '/' )+1); %%
~& -- PhilippAHartmann
Deletions:
~& There's a bug in the ##Method()##-method in wikka.php. The calls to ##strstr()## and ##strrpos()## have a wrong order of arguments. I think, it can be a **security issue**, since we have access to arbitrary .php-files on the server. Even user-uploaded ones... :/ -- PhilippAHartmann


Revision [11287]

Edited on 2005-10-07 00:06:14 by PhilippAHartmann [Adding fix for handler-path sanitization]
Additions:
~& There's a bug in the ##Method()##-method in wikka.php. The calls to ##strstr()## and ##strrpos()## have a wrong order of arguments. I think, it can be a **security issue**, since we have access to arbitrary .php-files on the server. Even user-uploaded ones... :/ -- PhilippAHartmann


Revision [11269]

Edited on 2005-10-06 12:13:06 by TroelsKnakNielsen [comment on dblclick issue]
Additions:
~&In that case, wouldn't you want new profiles to have dblclick turned off by default ? (TroelsKnakNielsen)


Revision [11252]

Edited on 2005-10-03 18:54:11 by GiorgosKontopoulos [added link to StayingLoggedIn for similar security risk]
Additions:
~&Something relative: session likage described as "security hole" in StayingLoggedIn --GiorgosKontopoulos


Revision [11237]

Edited on 2005-10-01 20:40:32 by SeanOttey [added possible bug regarding use of user details in multiple wikkas on a server]
Additions:
===Reuse of Username when multiple wikkas on single server===
Not
sure if this is truly a bug, but I have a number of wikka installations,. each in different (peer) directories on a server, each using different DB's. Now, each has a user named SeanOttey, and if I go log in at site A, then go to site B, I am shown as logged in, but with the other site's user info (i.e. email, password, settings). Potentially, this might create accessibility that an admin did not intend, yes? thanks! Sean.


Revision [11165]

Edited on 2005-09-24 17:22:25 by NilsLindenberg [clarification]
Additions:
===Wikiedit: Link to the Formatting-rules (using IIS and not using mod-rewrite)===
Deletions:
===Wikiedit: Link to the Formatting-rules (using IIS and mod-rewrite)===


Revision [11164]

Edited on 2005-09-24 17:01:08 by NilsLindenberg [added bug about wikiedit and IIS]
Additions:
===Wikiedit: Link to the Formatting-rules (using IIS and mod-rewrite)===
from [[http://arek.c-consulting.co.id/ivan/wikka/wikka.php?wakka=WikiEditHack IvanLaninWiki]]: (see there for his solution)
//I don't use rewrite_mode since I'm using IIS as server, and I also put value for base_url for my wikka. Then I notice, by accident, that the Help button on WikiEdit∞ does not point to the right page (FormattingRules).//


Revision [11143]

Edited on 2005-09-21 18:04:14 by PhilippeVincent [simplifying SF-hosted Bug]
Additions:
Here are the symptoms :
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.
Deletions:
I've struggled several times switching users from Administrator to my ""WikiName"",
here are the symptoms :
Then you can click another time, and it takes a long time before showing the Javascript dialog box '//You are logged out, now//'.
According to some experimented users, Administrator could harm because it's not a WikiName.
However switching between two different ""WikiNames"" produces the same issue.
IMHO, I think it may be a problem with the ""SourceForge"" hosting space, I've tried logout/login on different Wikka sites already hosted by ""SourceForge"" -> same issue.
Right now, I keep using my wikka space and I press 2 or 3 times on the logout button... a bit annoying
~&Philippe, could you give the address so we can look there? What about mod_rewrite (Url-rewriting)? Is it turned off?--NilsLindenberg
~~& You can have a look at my own project [[http://maloya.sourceforge.net maloya]]
~~& I notice most of (perhaps all of) the sourceforge hosted wikka site suffer the same issue, for instance you can try on [[http://astronomy.sourceforge.net]] too
~~& Some other projects like kuroo seems to be hosted somewhere else and it's ok.
~~& I've tried several times with different browsers : Konqueror, Mozilla and Firefox and the logout process reacts always in a weird manner
~~& With or without mod_rewrite, I encounter the same trouble.
~~& --PhilippeVincent
~~~& Could you please post your settings for "base_url" and "rewrite_mode"? --NilsLindenberg
~~~~& "base_url" => "http://maloya.sourceforge.net/wiki/",
~~~~& "rewrite_mode" => "1",
~~~~& --PhilippeVincent
~~& Philippe, I' ve just tested registering/logging in/logging out at the maloya website and it works just fine for me. Does this mean you managed to fix the problem? If not, this might depend on the way your browser handles cookies and sessions. I suggest you check your cookies settings and try to access the server with a different browser to see if it makes any difference -- DarTar
~~~& Nope, the problem still exists on different machines, different browsers but it seems to be sourceforge related solely
~~~& Try this sequence :
~~~& - Go to maloya.sf.net and connect as ""YourWikiName""
~~~& - Go to ""HomePage""
~~~& - Logout, then go to ""HomePage"" again
~~~& - the 'loggout now' dialog box should appear a couple of seconds later ( a bit late uhh)
~~~& - Connect a second time as ""YourWikiName""
~~~& - Browse again ""HomePage"", Categories, Changes, etc... some pages still appear as 'Not Registered'
~~~& A friend of mine told me about server cache or bad cookies handling... [may be a stupid suggestion]
~~~& --PhilippeVincent


Revision [10980]

Edited on 2005-09-09 02:46:06 by QualousHere [Windows Paths With {{files}} Action]
Additions:
===Windows Paths With ""{{files}}"" Action===
On a Windows/IIS installation, including the ""{{files}}"" action causes errors similar to the following:
Warning: mkdir(uploads\SandBox): Permission denied in D:\sitepath\wwwroot\wikka\actions\files.php on line 12
Warning: opendir(uploads\SandBox): failed to open dir: Invalid argument in D:\sitepath\wwwroot\wikka\actions\files.php on line 156
Warning: readdir(): supplied argument is not a valid Directory resource in D:\sitepath\wwwroot\wikka\actions\files.php on line 157
Warning: closedir(): supplied argument is not a valid Directory resource in D:\sitepath\wwwroot\wikka\actions\files.php on line 200
This is caused by the assumption of "/" as the directory seperator instead of Window's "\". Using the DIRECTORY_SEPARATOR variable corrects this is.
In actions/files.php change:
$upload_path = $this->config['upload_path'].'/'.$this->GetPageTag();
%% into
$upload_path = $this->config['upload_path'].DIRECTORY_SEPARATOR.$this->GetPageTag();
and also:
$destfile = $upload_path.'/'.$strippedname;
%% into
$destfile = $upload_path.DIRECTORY_SEPARATOR.$strippedname;
Warning: This has only been tested so far under Windows. -- QualousHere


Revision [10949]

Edited on 2005-09-08 05:18:41 by QualousHere [Added fix for "Advanced search results reveal confidential info" issue]
Additions:
~&You can fix it by changing the line
~& In actions/textsearch.php you can fix it by changing the following;
~& %%(php)
if ($phrase = $_REQUEST["phrase"])
{
$phrase = stripslashes($phrase);
$results = $this->FullTextSearch($phrase);
print("<br />");
$total_results = count($results);
$match_str = $total_results <> 1 ? " matches" : " match";
print("Search results: <strong>".$total_results.$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
if ($results)
foreach ($results as $i => $page)
print(($i+1).". ".$this->Link($page["tag"])."<br />\n");
$phrase = urlencode($phrase);
print("<br />Not sure which page to choose?<br />Try the <a href=\"".$this->href("", "TextSearchExpanded", "phrase=$phrase")."\">Expanded Text Search</a> which shows surrounding text.");
~& into
~& %%(php)
if ($phrase = $_REQUEST["phrase"])
{
$results = $this->FullTextSearch($phrase);
$result_page_list = '';
$total_results = 0;
print("<br />");
if ($results)
foreach ($results as $i => $page)
if ($this->HasAccess("read",$page["tag"]))
$result_page_list .= ($i+1).". ".$this->Link($page["tag"])."<br />\n";
$total_results += 1;
$phrase = urlencode($phrase);
$match_str = $total_results <> 1 ? " matches" : " match";
print("Search results: <strong>".$total_results.$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
if ($total_results > 0)
print($result_page_list);
print("<br />Not sure which page to choose?<br />Try the <a href=\"".$this->href("", "TextSearchExpanded", "phrase=$phrase")."\">Expanded Text Search</a> which shows surrounding text.");
~& Similarly, in actions/textsearchexpanded.php you can fix it by changing the following:
~& %%(php)
if (isset($_REQUEST["phrase"]) && $phrase = $_REQUEST["phrase"])
{
$phrase = stripslashes($phrase);
print("<br />");
$results = $this->FullTextSearch($phrase);
$match_str = count($results) <> 1 ? " matches" : " match";
print("Search results: <strong>".count($results).$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
$phrase = str_replace("\"", "", $phrase);
if ($results)
{
print "<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\">";
$STORE_FORMATING_AS_TEXT = 1;
foreach ($results as $i => $page)
{
//print(($i+1).". ".$this->Link($page["tag"])."<br />\n");
//print implode($this->LoadPage($page["tag"]));
//$matchString = preg_match("/(.{0,40}$phrase.{0,40})/",implode($this->LoadPage($page['tag'])));
/* display portion of the matching body and highlight
the search term */
preg_match("/(.{0,120}$phrase.{0,120})/is",$page['body'],$matchString);
$text = $this->htmlspecialchars_ent($matchString[0]);
// include("formatters/wakka.php");
$highlightMatch = preg_replace("/($phrase)/i","<font color=\"green\"><b>$1</b></font>",$text,-1);
$matchText = "<font color=\"gray\" size=\"-1\">...</font>$highlightMatch<font color=\"gray\" size=\"-1\">...</font>";
print "
<tr>
<td valign=\"top\" align=\"right\">
<!-- result number -->
<table>
<tr>
<td valign=\"top\" align=\"left\" bgcolor=\"#DDDDDD\">
<font color=\"white\" size=\"-3\">
".($i+1)."
</font>
</td>
</tr>
</table>
</td>
<!-- link -->
<td valign=\"top\">
".$this->Link($page["tag"])."
</td>
<!-- date of last update -->
<td valign=\"top\" align=\"right\">
<font color=\"gray\" size=\"-3\">
$page[time]
</font>
</td>
</tr>
<tr>
<td>
 
</td>
<td colspan=\"2\">
$matchText
</td>
</tr>
<tr>
<td>
 
</td>
</tr>
";
}
print "</table>";
~& into
~& %%(php)
if (isset($_REQUEST["phrase"]) && $phrase = $_REQUEST["phrase"])
{
print("<br />");
$results = $this->FullTextSearch($phrase);
$phrase = str_replace("\"", "", $phrase);
$result_page_list = '';
$total_results = 0;
if ($results)
print "<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\">";
$STORE_FORMATING_AS_TEXT = 1;
foreach ($results as $i => $page)
if ($this->HasAccess("read",$page["tag"]))
preg_match("/(.{0,120}$phrase.{0,120})/is",$page['body'],$matchString);
$text = $this->htmlspecialchars_ent($matchString[0]);
$highlightMatch = preg_replace("/($phrase)/i","<font color=\"green\"><b>$1</b></font>",$text,-1);
$matchText = "<font color=\"gray\" size=\"-1\">...</font>$highlightMatch<font color=\"gray\" size=\"-1\">...</font>";
$total_results += 1;
$result_page_list .= "
<tr>
<td valign=\"top\" align=\"right\">
<!-- result number -->
<table>
<tr>
<td valign=\"top\" align=\"left\" bgcolor=\"#DDDDDD\">
<font color=\"white\" size=\"-3\">
".($i+1)."
</font>
</td>
</tr>
</table>
</td>
<td valign=\"top\">
<!-- link -->
".$this->Link($page["tag"])."
</td>
<td valign=\"top\" align=\"right\">
<!-- date of last update -->
<font color=\"gray\" size=\"-3\">
$page[time]
</font>
</td>
</tr>
<tr>
<td> </td>
<td colspan=\"2\">$matchText</td>
</tr>
<tr>
<td> </td>
</tr>
";
$match_str = $total_results <> 1 ? " matches" : " match";
print("Search results: <strong>".$total_results.$match_str."</strong> for <strong>$phrase</strong><br /><br />\n");
if ($total_results > 0)
print($result_page_list);
print("</table>");
~& This fix also includes another fix on this page by NilsLindenberg in the "Bug in Textsearch (expanded)" section. --QualousHere
Deletions:
You can fix it by changing the line


Revision [10895]

Edited on 2005-08-31 00:27:12 by KoG [htaccess comment on 403 fix]
Additions:
~~~&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


Revision [10813]

Edited on 2005-08-25 10:40:32 by DarTar [moving bug to top, minor changes]
Additions:
~-check resolved bugs/issues (//in released or to-be-released code//) in WikkaBugsResolved first
~-workarounds for unusual problems and temporary fixes for known bugs are listed at WikkaWorkarounds
~-for issues related to Wikka layout refer to WikkaCSS
~-for feature suggestions go to the SuggestionBox
~-general help can be found on the [[WikkaDocumentation Wikka documentation page]]
~-before posting new bugs on this page, please make sure they have not been already discussed: {{search}}
Deletions:
-check resolved bugs/issues (//in released or to-be-released code//) in WikkaBugsResolved first
-workarounds for unusual problems and temporary fixes for known bugs listed at WikkaWorkarounds
-for issues related to Wikka layout refer to: WikkaCSS
-for feature suggestions rather than bugs, go to the SuggestionBox
-looking for help? check the [[WikkaDocumentation Wikka Documentation]]


Revision [10812]

Edited on 2005-08-25 10:36:13 by DarTar [moving bug to top, minor changes]
Additions:
<<**Read this first**:
<<>>==Note:==
If you think you've found a new bug or have some other issue, please post it here - //with// any solution you may have found. (WikkaBugsResolved is only for bugfixes that have made it into a release or to-be-released code already.)
**Please post recently discovered issues on the //top// of this page (just below this note); don't forget to add a ##""===heading===""## as a condensed description.**
This error implies in not log in or out, because the page redirects before the cookie i created.
%%(php)header("Location: ".$url);%%
CategoryDevelopmentSuggestions
Deletions:
<<**Related pages**:
<<>>==Attention:==
If you found a new bug or other issue, please post it here - //with// any solution you may have found. (WikkaBugsResolved is only fot bugfixes that have made it into a release or to-be-released code already.)
''Please use the comments only to actually //comment// on a reported bug but not to report a new one!''
**Please post recently discovered issues on the //top// of this page (just below this note); don't forget to add a ""===heading==="" as a condensed description.**
This error implies in not log in or out, becsause the page redirects before the cookie i created.
header("Location: ".$url);
CategoryDevelopm
entSuggestions


Revision [10808]

Edited on 2005-08-24 03:23:04 by MarceloArmonas [moving bug to top, minor changes]
Additions:
===Wikka in Windows IIS===
When Wikka is installed in IIS5.0 occurs an error when using cookies and using the header(Location:)
http://br.php.net/manual/pt_BR/function.setcookie.php#51195
This error implies in not log in or out, becsause the page redirects before the cookie i created.
The problem can be solved using javascript to redirect the page, just change the following line in the code of Redirect function on wikka.php:
header("Location: ".$url);
by this:
if (substr_count($_SERVER["SERVER_SOFTWARE"],"IIS") > 0) {
~& echo '<SCRIPT>window.location.href = "'.$url.'";</SCRIPT>';
} else {
~& header("Location: ".$url);
-- MarceloArmonas (sorry, i don't write in english)
CategoryDevelopm
entSuggestions
Deletions:
CategoryDevelopmentSuggestions


Revision [10733]

Edited on 2005-08-16 12:27:01 by PhilippeVincent [logout fails silently]
Additions:
~& 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


Revision [10662]

Edited on 2005-08-12 18:59:07 by PhilippeVincent [More precisions about the sourceforge issue]
Additions:
~&Philippe, could you give the address so we can look there? What about mod_rewrite (Url-rewriting)? Is it turned off?--NilsLindenberg
~~~& Could you please post your settings for "base_url" and "rewrite_mode"? --NilsLindenberg
~~~& Nope, the problem still exists on different machines, different browsers but it seems to be sourceforge related solely
~~~& - Go to maloya.sf.net and connect as ""YourWikiName""
~~~& - Go to ""HomePage""
~~~& - Logout, then go to ""HomePage"" again
~~~& - the 'loggout now' dialog box should appear a couple of seconds later ( a bit late uhh)
~~~& - Connect a second time as ""YourWikiName""
~~~& - Browse again ""HomePage"", Categories, Changes, etc... some pages still appear as 'Not Registered'
~~~& A friend of mine told me about server cache or bad cookies handling... [may be a stupid suggestion]
~~~& --PhilippeVincent
Deletions:
~&Philippe, could you give the address so we can look there? What about mod_rewrite (Url-rewriting)? Is it turned off?
~&--NilsLindenberg
~~~& Could you please post your settings for "base_url" and "rewrite_mode"?
~~~& --NilsLindenberg
~~~& Nope, the problem still exists.
~~~& - Connect as YourWikiName
~~~& - Go to HomePage
~~~& - Logout, then go to HomePage again
~~~& - the 'loggout' dialog box should appear a couple of seconds later
~~~& - Connect a second time as YourWikiName
~~~& - Browse again HomePage, Categories, Changes, etc... some pages still appear as 'Not Registered'


Revision [10655]

Edited on 2005-08-12 13:19:24 by PhilippeVincent [sequence for the loggout bug]
Additions:
~~~& Nope, the problem still exists.
~~~& Try this sequence :
~~~& - Connect as YourWikiName
~~~& - Go to HomePage
~~~& - Logout, then go to HomePage again
~~~& - the 'loggout' dialog box should appear a couple of seconds later
~~~& - Connect a second time as YourWikiName
~~~& - Browse again HomePage, Categories, Changes, etc... some pages still appear as 'Not Registered'


Revision [10632]

Edited on 2005-08-12 10:17:22 by CklTest [sequence for the loggout bug]
Additions:
~~& 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.


Revision [10631]

Edited on 2005-08-12 09:08:47 by DarTar [re: philippe & ckltest]
Additions:
===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
~&Philippe, could you give the address so we can look there? What about mod_rewrite (Url-rewriting)? Is it turned off?
~~& Philippe, I' ve just tested registering/logging in/logging out at the maloya website and it works just fine for me. Does this mean you managed to fix the problem? If not, this might depend on the way your browser handles cookies and sessions. I suggest you check your cookies settings and try to access the server with a different browser to see if it makes any difference -- DarTar
Deletions:
~&Philliphe, could you give the address so we can look there? What about mod_rewrite (Url-rewriting)? Is it turned off?
---
==Wrong Links==


Revision [10627]

Edited on 2005-08-11 18:54:18 by CklTest [re: philippe & ckltest]
Additions:
---


Revision [10626]

Edited on 2005-08-11 18:52:48 by CklTest [re: philippe & ckltest]
Additions:
==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


Revision [10621]

Edited on 2005-08-11 14:41:00 by PhilippeVincent [re: philippe & ckltest]
Additions:
--PhilippeVincent 10 Aug 2005
~&Philliphe, could you give the address so we can look there? What about mod_rewrite (Url-rewriting)? Is it turned off?
~&--NilsLindenberg
~~& With or without mod_rewrite, I encounter the same trouble.
~~& --PhilippeVincent
~~~& Could you please post your settings for "base_url" and "rewrite_mode"?
~~~& --NilsLindenberg
~~~~& "base_url" => "http://maloya.sourceforge.net/wiki/",
~~~~& "rewrite_mode" => "1",
~~~~& --PhilippeVincent
Deletions:
-- PhilippeVincent 10 Aug 2005
~&Philliphe, could you give the address so we can look there? What about mod_rewrite (Url-rewriting)? Is it turned off? --NilsLindenberg
~~& With or without mod_rewrite, I encounter the same trouble.
~~& Could you please post your settings for "base_url" and "rewrite_mode"? --NilsLindenberg


Revision [10614]

Edited on 2005-08-11 14:08:02 by NilsLindenberg [reply to philippe]
Additions:
~~& Could you please post your settings for "base_url" and "rewrite_mode"? --NilsLindenberg


Revision [10611]

Edited on 2005-08-11 10:52:36 by PhilippeVincent [In Reply to NilsLindenberg]
Additions:
~~& You can have a look at my own project [[http://maloya.sourceforge.net maloya]]
~~& I notice most of (perhaps all of) the sourceforge hosted wikka site suffer the same issue, for instance you can try on [[http://astronomy.sourceforge.net]] too
~~& Some other projects like kuroo seems to be hosted somewhere else and it's ok.
~~& I've tried several times with different browsers : Konqueror, Mozilla and Firefox and the logout process reacts always in a weird manner
~~& With or without mod_rewrite, I encounter the same trouble.


Revision [10595]

Edited on 2005-08-10 11:28:42 by NilsLindenberg [moved bug to the top + reply]
Additions:
~&Philliphe, could you give the address so we can look there? What about mod_rewrite (Url-rewriting)? Is it turned off? --NilsLindenberg


Revision [10592]

Edited on 2005-08-10 09:34:23 by PhilippeVincent [Logout issue]
Additions:
===Logout fails silently or takes long time on ""SourceForge"" hosted site ===
I've struggled several times switching users from Administrator to my ""WikiName"",
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.
Then you can click another time, and it takes a long time before showing the Javascript dialog box '//You are logged out, now//'.
According to some experimented users, Administrator could harm because it's not a WikiName.
However switching between two different ""WikiNames"" produces the same issue.
IMHO, I think it may be a problem with the ""SourceForge"" hosting space, 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"".
Right now, I keep using my wikka space and I press 2 or 3 times on the logout button... a bit annoying
-- PhilippeVincent 10 Aug 2005


Revision [10285]

Edited on 2005-07-30 19:48:58 by JavaWoman [new bug moved to the top]

No Differences

Revision [10282]

Edited on 2005-07-30 19:19:58 by EniBevoli [new bug moved to the top]
Additions:
===Wikiedit: Problem with some date strings===
When I write a date in DD.MM.YYYY format **and** the date string is right at the beginning of a line, trying to mark the complete string and click the wikiedit buttons for bold (italic, etc.) text results in an incorrect markup:
31.12.2005 <- does not work (case 1)
Filler text 31.12.2005 <- does work (case 2)
Here is the wikiedit output for case 1.
How it is:
%%31.**12.2005**%%
How it should be:
%%**31.12.2005**%%
Again, it works when the date string is not at the very beginning of a new line.


Revision [10270]

Edited on 2005-07-30 17:51:06 by JavaWoman [comment re: history bug]
Additions:
===history bug===
~&A rough estimate: there have been between 425 and 450 revisions of that page; the current page **source** size is 92316 bytes; given that the page tends to grow but is sometimes "weeded" when suggestions are implemented or moved to a separate page, the total 'history' **source** size could be something like 12.5MB. Even is it's as "small" as 5MB I wouldn't be surprised to have it break //somehow// (DB access, PHP timeout...).---Maybe we should just give up on 'history' and support only revisions? Where or how something like this breaks is hard to tell, it could be entirely dependent on a specific installation. --JavaWoman
Deletions:
===history-bug===


Revision [10268]

Edited on 2005-07-30 17:18:17 by NilsLindenberg [history-bug]
Additions:
===history-bug===
If you try to access the history for the SuggestionBox you'll get an server-error (500). Perhaps related to the size of the history? --NilsLindenberg


Revision [9990]

Edited on 2005-07-15 16:13:56 by JavaWoman [approach for fixing LoadPagesLinkingTo() problem]
Additions:
~~~&Indeed it is the delete handler that is at fault here by not deleting all records from the links table that refer to the (to be) deleted page. This is simple enough to fix (by extending the query a little to match both the "from_tag" and "to_tag" columns) but for a future version to be released with such a fix there should also be an (admin-only) utility to clear left-behind records from the links table that //should// have been deleted before. --JavaWoman


Revision [9988]

Edited on 2005-07-15 15:58:56 by JavaWoman [setting default on/off for double-click edit]
Additions:
~~&%%(php;1)
~~&%%(php;2)
~~&--NilsLindenberg
There is another issue with double-click editing: while registered users can edit their preferences to use double-click editing or not, it is always on for non-registered (or not logged-in) users. The result is that on pages that can be edited only by registered users, a double-click results in an unfriendly error message. Especially on a site that is mostly read-only for visitors this is a bad situation. The solution is to make this admin-configurable.
Add to wikka.config.php:
%%(php) "doubleclickedit" => "Y", # set to "N" to disable double-click editing%%
and change the proposed line for the show handler above to:
%%(php;2)<div class="page" <?php echo (((!$user && $this->config['doubleclickedit'] == "Y") || ($user['doubleclickedit'] == 'Y')) && $this->GetMethod
%%--- --JavaWoman
Deletions:
~~&%%(php)
~~&%%(php)
~~&--NilsLindenberg


Revision [9975]

Edited on 2005-07-14 21:40:09 by JavaWoman [fixing ypot]
Additions:
=== Indenting not working properly in handlers/page/edit.php ===
Deletions:
=== Identing not working properly in handlers/page/edit.php ===


Revision [9974]

Edited on 2005-07-14 21:34:48 by JavaWoman [Identing not working properly in edit handler: fixed]
Additions:
~&The line with the "incomplete" indents-handling code actually occurs twice in ##handlers/page/edit.php##; while I haven't addressed that duplication yet (the handler code really needs to be restructured), I came up with the following (a little more robust) code to fix this particular bug: %%(php) # JW FIXED 2005-07-12
$pattern = '/^(\t*) {4}/m'; # m modifier: match ^ at start of line *and* at start of string;
$replace = "$1\t";
while (preg_match($pattern,$body))
{
$body = preg_replace($pattern,$replace,$body);
# @@@ NOTE: This could be easily extended to also change a '~' into a tab. But should we? '~' is easy to type and edit
%%---Implemented as BETA on this site now. --JavaWoman


Revision [9972]

Edited on 2005-07-14 21:14:46 by JavaWoman [fix available for "Wakka formatter: Indenting on first line"]
Additions:
~&Fixed and implemented as part of the beta ImprovedFormatter on this site; see ""<a href="ImprovedFormatter#hn_Better_handling_of_nested_lists_and_indents">Better handling of nested lists and indents</a>"" on that page for the details. --JavaWoman


Revision [9955]

Edited on 2005-07-14 16:17:08 by JavaWoman [bug + fix for GetCookie() method]
Additions:
===##""GetCookie()""## bug===
The ##""GetCookie()""## method in ##wikka.php## does not check whether a named cookie actually exists; this results in a NOTICE and then even partially unstyled pages; this turned up with the (beta) skins feature. (That's why I call a notice a "lurking bug". :))
Fixed already on this site; in wikka.php, change:
%%(php;599) function GetCookie($name) { return $_COOKIE[$name]; }
---to:
%%(php) function GetCookie($name)
{
if (isset($_COOKIE[$name]))
{
return $_COOKIE[$name];
}
else
{
return FALSE;
}
}
--- I've also made corresponding changes to ##actions/editskin.php##, ##actions/header.php##, ##actions/myskin.php##, ##actions/selectskin.php## and ##actions/skin.php## in the beta versions as implemented on this server. (See also WikkaBetaFeatures.) --JavaWoman
// replace each 4 spaces at beginning of a line with a tab
$body = preg_replace("/^[ ]{4}/","\t", $body);
$body = preg_replace("/\n[ ]{4}/","\n\t", $body);
$body = preg_replace("/\t[ ]{4}/","\t\t", $body);
}
elseif (preg_match("/\n([\t~]+)(-|&|([0-9a-zA-ZÄÖÜßäöü]+)\))?(\n|$)/s", $thing, $matches))
Deletions:
// replace each 4 spaces at beginning of a line with a tab
$body = preg_replace("/^[ ]{4}/","\t", $body);
$body = preg_replace("/\n[ ]{4}/","\n\t", $body);
$body = preg_replace("/\t[ ]{4}/","\t\t", $body);
}
elseif (preg_match("/\n([\t~]+)(-|&|([0-9a-zA-ZÄÖÜßäöü]+)\))?(\n|$)/s", $thing, $matches))


Revision [9863]

Edited on 2005-07-05 19:40:29 by JavaWoman [layout]
Additions:
===blog.php===
//Moved to WikkaBlog2 since it's user-contributed code]//
Deletions:
====blog.php====
[Moved to WikkaBlog2 since it's user-contributed code]


Revision [9791]

Edited on 2005-07-05 14:15:48 by DarTar [moving issue to user-contributed page]
Additions:
[Moved to WikkaBlog2 since it's user-contributed code]
Deletions:
(I home non-core issues go here) This is about WikkaBlog2.
I find that noone is allowed to post blog comments (i.e. not the wikka page std comments).
All ACLs are '*'; I even blanked all, or have the page owned by nobody, and still no rights; I suppose HasAccess('comment') fails.
(see [[http://cativan.com/VisitingIdeas this page]])


Revision [9788]

Edited on 2005-07-05 13:24:55 by CatIvan [moving issue to user-contributed page]
Additions:
(see [[http://cativan.com/VisitingIdeas this page]])


Revision [9787]

Edited on 2005-07-05 13:18:29 by CatIvan [moving issue to user-contributed page]
Additions:
====blog.php====
(I home non-core issues go here) This is about WikkaBlog2.
I find that noone is allowed to post blog comments (i.e. not the wikka page std comments).
All ACLs are '*'; I even blanked all, or have the page owned by nobody, and still no rights; I suppose HasAccess('comment') fails.


Revision [9781]

Edited on 2005-07-05 09:47:05 by JavaWoman [usersettings.php added]
Additions:
===usersettings.php===
//nearly missed this - copied from MiKolar - JW//
WikkaWiki version 1.1.6.0 login/register actions returns often confusing error messages
(e.g., if a registered user makes an error in his WikiName, he gets an error message
"You must specify an email address", which may be rather confusing to a properly registered
user). Here is my attempt to straighten this up (...) http://www.world-wide-democracy.net/members/MiUploads/usersettings.php.gz
--MiKolar


Revision [9749]

Edited on 2005-07-04 08:03:06 by JavaWoman [adding comment re 403 and 500 errors]
Additions:
~~&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


Revision [9745]

Edited on 2005-07-03 17:49:38 by Ikhnaton2 [adding comment re 403 and 500 errors]
Additions:
~& 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


Revision [9721]

Edited on 2005-07-01 12:00:12 by JavaWoman [tags in the edit notes: fixed]
Additions:
~~&Fixed now: Code changes in wikka.php (GetPingParams()), actions/recentchanges.php, handlers/page/recentchanges.xml.php, handlers/page/recentchanges.xml.mm.php, handlers/page/revisions.php and handlers/page/revisions.xml.php. Installed on this server as "beta test" so we can watch behavior. --JavaWoman


Revision [9717]

Edited on 2005-07-01 09:24:00 by JavaWoman [added note re: tags in the edit notes]
Additions:
===tags in the edit notes===
~~&It was at the beginning of mail.php: %%(php) <?php <?php%%. I guess you overlooked it when you copied your new version to the page. Happened to me in another case, too. --NilsLindenberg
~&Actually, the problem is not just with tags; any XML "special character" is going to cause an XML error. All will need to be escaped to ensure the RSS feeds and pings are valid XML. (We are having a problem again...) --JavaWoman
Deletions:
===tags in the edit-notes===
~~&It was at the beginning of mail.php: %%(php) <?php <?php%%. I guess you overlooked it when you copied your new version to the page. Happent to me in another case, too. --NilsLindenberg


Revision [9654]

Edited on 2005-06-27 07:00:35 by JavaWoman [accesskey on comments]
Additions:
===Accesskey on comments===
//copied from the #wikka channel - JW//
<SamuelDr> for the next important guy/gal who'll read this
<SamuelDr> the accesskey="d" on the comments is a little bit useless
<SamuelDr> when there are more than 1 comment deletable on a page
<SamuelDr> I think it wouldn't work really well ;)


Revision [9645]

Edited on 2005-06-26 08:53:25 by KoG [apparently new bugs go to the top of the page...]

No Differences

Revision [9644]

Edited on 2005-06-26 08:49:58 by KoG [added .htaccess fix for error403/mod_rewrite - kog]
Additions:
===.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.
%%(apache)
### 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
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


Revision [9643]

Edited on 2005-06-26 08:48:23 by JavaWoman [adapting description]
Additions:
-check resolved bugs/issues (//in released or to-be-released code//) in WikkaBugsResolved first
If you found a new bug or other issue, please post it here - //with// any solution you may have found. (WikkaBugsResolved is only fot bugfixes that have made it into a release or to-be-released code already.)
Deletions:
-for resolved bugs/issues see: WikkaBugsResolved


Revision [9603]

Edited on 2005-06-24 22:05:05 by JavaWoman [minor (layout)]
Additions:
''part of a users host-name is formatted as a wikilink''
Deletions:
''part of a users host-anme is formatted as a wikilink''


Revision [9597]

Edited on 2005-06-24 18:57:34 by NilsLindenberg [added formatter-bug]
Additions:
===Formatter-bug in the comments===
//reported by someone named DarTar ;) on my userpage. --NilsLindenberg//
Note for ourselves: if you look at the commentinfo by dialup-4.227.116.20 you'll see that we have a small formatter bug (Dial1 is parsed as a missing page): CamelCase formatting should not be applied within commentinfo's.
''part of a users host-anme is formatted as a wikilink''


Revision [9389]

Edited on 2005-06-22 08:33:51 by JavaWoman [Ctrl+5 solution added (from comment)]
Additions:
I saw the source of the problem : Find the checkKey() prototype in file ##protoedit.js##, and just add "##""k==53+2048 ||""##":
%%(javascript)ProtoEdit.prototype.checkKey = function (k) {
if (k==85+4096 || k==73+4096 || k==49+2048 || k==50+2048 || k==51+2048 || k==52+2048 || k==53+2048 ||
k==76+4096 || k==76+2048 || k==78+2048 || k==79+2048 || k==66+2048 || k==83+2048 ||


Revision [9382]

Edited on 2005-06-22 06:43:22 by JavaWoman [indenting bug/fixmoved here from WikkaBugsResolved]
Additions:
=== Identing not working properly in handlers/page/edit.php ===
$body = preg_replace("/\n[ ]{4}/", "\n\t", $body); # @@@ FIXME: misses first line and multiple sets of four spaces - JW 2005-01-16
Working fix (this might not be the best code doing the job...)
// replace each 4 spaces at beginning of a line with a tab
$body = preg_replace("/^[ ]{4}/","\t", $body);
$body = preg_replace("/\n[ ]{4}/","\n\t", $body);
while (preg_match("/\t[ ]{4}/",$body)) {
$body = preg_replace("/\t[ ]{4}/","\t\t", $body);
}
-- TimoK


Revision [9356]

Edited on 2005-06-21 20:14:52 by TimoK [Indenting problems in the formatter]
Additions:
===Wakka formatter: Indenting on first line===
// indented text
elseif (preg_match("/\n([\t~]+)(-|&|([0-9a-zA-ZÄÖÜßäöü]+)\))?(\n|$)/s", $thing, $matches))
This simply doesn't match indents on the first line.
I know there is a problem in the edit handler as well with indents, but even if that is fixed (working solution for that problem at WikkaBugsResolved) we still will have the problem here. -- TimoK


Revision [9292]

Edited on 2005-06-21 07:28:18 by JavaWoman [comment re: Ctrl+5; minor noise removal]
Additions:
When I type Ctrl+4 (**h4**), the current line is surrounded by ""==="" and ""==="", that's OK. But when I type Ctrl+5 (**h5**), What I get is ""===="" and ""===="", as if I've typed Ctrl+3. On a relatively slow computer, I saw that the WikiEdit engine added ""=="" twice. --DotMG
~&Confirmed - we'll look into this. --JavaWoman
Hi DavidLee!
No, we don't have an ""{{adduser}}"" yet. If you don't want other people to register, try out the solution from UserRegistration which allows you to stop registration (and you could use phpmyadmin to add users directly to the database). The solution makes it possible to allow registration only with a password, which can be set in the config. See UserRegistration for more details. A division of registration/log-in and usersettings into different actions is planned but won't come in the next release. --NilsLindenberg
Deletions:
When I type Ctrl+4 (**h4**), the current line is surrounded by ""==="" and ""==="", that's OK. But when I type Ctrl+5 (**h5**), What I get is ""===="" and ""===="", as if I've typed Ctrl+3. On a relatively slow computer, I saw that the WikiEdit engine added ""=="" twice. --DotMG
Hi AnonymusUser!
For the next time: please sign your bug-report. It can be any kind of nickname if you don't want to give away your real one, but it makes it easier to sort out who wrote what.
( Note from DavidLee -- Sorry I lost track which window I was on and didnt realize I had not logged in properly !! -- changed sig from above comment )
To your question: No, we don't have an ""{{adduser}}"" yet. If you don0't want other people to register, try out the solution from UserRegistration which allows you to stop registration (and you could use phpmyadmin to add users directly to the database). The solution makes it possible to allow registration only with a password, which can be set in the config. See UserRegistration for more details. A division of registration/logg-in and usersettings into different actions is planned but won't come in the next release. --NilsLindenberg


Revision [9291]

Edited on 2005-06-21 05:40:42 by DotMG [New WikiEdit Bug found when typing Ctrl+5]
Additions:
===WikiEdit : Ctrl+5 executed twice===
When I type Ctrl+4 (**h4**), the current line is surrounded by ""==="" and ""==="", that's OK. But when I type Ctrl+5 (**h5**), What I get is ""===="" and ""===="", as if I've typed Ctrl+3. On a relatively slow computer, I saw that the WikiEdit engine added ""=="" twice. --DotMG


Revision [9254]

Edited on 2005-06-16 21:07:02 by DavidLee [New WikiEdit Bug found when typing Ctrl+5]
Additions:
( Note from DavidLee -- Sorry I lost track which window I was on and didnt realize I had not logged in properly !! -- changed sig from above comment )
Deletions:
[[ Note from DavidLee -- Sorry I lost track which window I was on and didnt realize I had not logged in properly !! -- changed sig from above comment ]]


Revision [9253]

Edited on 2005-06-16 21:06:20 by DavidLee [New WikiEdit Bug found when typing Ctrl+5]
Additions:
[[ Note from DavidLee -- Sorry I lost track which window I was on and didnt realize I had not logged in properly !! -- changed sig from above comment ]]
Deletions:
--AnotherUser


Revision [9240]

Edited on 2005-06-15 19:54:07 by JavaWoman [another sig]
Additions:
--AnotherUser


Revision [9239]

Edited on 2005-06-15 19:50:52 by JavaWoman [adding sig to new issue ;-)]
Additions:
--DavidLee


Revision [9236]

Edited on 2005-06-15 17:15:33 by NilsLindenberg [reply to unknown user]
Additions:
Hi AnonymusUser!
For the next time: please sign your bug-report. It can be any kind of nickname if you don't want to give away your real one, but it makes it easier to sort out who wrote what.
To your question: No, we don't have an ""{{adduser}}"" yet. If you don0't want other people to register, try out the solution from UserRegistration which allows you to stop registration (and you could use phpmyadmin to add users directly to the database). The solution makes it possible to allow registration only with a password, which can be set in the config. See UserRegistration for more details. A division of registration/logg-in and usersettings into different actions is planned but won't come in the next release. --NilsLindenberg


Revision [9235]

Edited on 2005-06-15 13:51:25 by AnotherUser [reply to unknown user]
Additions:
I changed my default ACL for write and comment to "!*" ... but left read as "*".
Deletions:
I changed my default ACL for write and comment to "!*" ... but left read as "!*".


Revision [9234]

Edited on 2005-06-15 13:50:55 by AnotherUser [reply to unknown user]
Additions:
--Sorta Fixed--
Deletions:
--SortaFixed--


Revision [9233]

Edited on 2005-06-15 13:50:32 by AnotherUser [reply to unknown user]
Additions:
--SortaFixed--
Ok I figured this out ... mostly. Feel free to delete this section if its seems obvious to everyone ! (It wasnt to me)
I changed my default ACL for write and comment to "!*" ... but left read as "!*".
People can still register themselves but it doesnt do them much good as they cant create pages.


Revision [9225]

Edited on 2005-06-15 02:15:03 by DavidLee [reply to unknown user]
Deletions:
---


Revision [9224]

Edited on 2005-06-15 02:09:58 by DavidLee [reply to unknown user]
Additions:
===No Registration Wikki===
I just started using this program and I love it ! Its exactly what I've been looking for. However what I want is a Wikki where only the administrator can register new users. This seems like such an obvious feature that I am amazed I cant figure out how to do it !
What am I missing ?
---


Revision [9200]

Edited on 2005-06-13 09:57:55 by JavaWoman [ypot]
Additions:
//Moved here from a comment so it won't get "lost". --JavaWoman//
Deletions:
//Moved here from a comment so it won't get "lost". ---JavaWoman//


Revision [9199]

Edited on 2005-06-13 09:54:48 by JavaWoman [instructions]
Additions:
''Please use the comments only to actually //comment// on a reported bug but not to report a new one!''
**Please post recently discovered issues on the //top// of this page (just below this note); don't forget to add a ""===heading==="" as a condensed description.**
Deletions:
**Please post recently discovered bugs on the //top// of this page (just below this note).**


Revision [9198]

Edited on 2005-06-13 09:50:01 by JavaWoman [moving comment to page]
Additions:
===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)


Revision [9194]

Edited on 2005-06-13 09:12:00 by JavaWoman [Problem with "History"?? moved to WikkaBugsResolved]
Deletions:
===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)
~~&I suspect this was caused by a (temporary) configuration problem with rewrite_mode (which will cause odd URLs for TextSearch); none of the changes afterwards show this problem. Classified as not-a-bug. --JavaWoman


Revision [9192]

Edited on 2005-06-13 09:08:32 by JavaWoman [XML Feed Problem moved to WikkaBugsResolved]
Deletions:
===XML Feed Problem===
When clicking on the XML feed link at the bottom of the page - get the following :
XML Parsing Error: xml processing instruction not at start of external entity
Location: http://www.cataclysmos.org/wiki/RecentChanges/recentchanges.xml
Line Number 10, Column 1:<?xml version="1.0" encoding="ISO-8859-1"?>
^
~& There is whitespace before the xml declaration, which is not allowed as far as I know. Not sure tho **why** it is there. Is that an out-of-the-box wikka 1.1.6.0?
~~& It is standard except for patches applied for UserRegistration and TableAction. I installed a second fresh wikka and it worked OK so I must have broken something.
~~& I found the problem - for the user registration you have to change wikka.config.php - the web based software I was using to edit the file had added some blank lines at the bottom of the config file. What this had to do with XML I am not sure but it works fine now.


Revision [9191]

Edited on 2005-06-13 08:37:56 by JavaWoman [moved Problems with double double-quote htm? to WikkaBugsResolved]
Deletions:
===Problems with double double-quote html?===
//moved from SuggestionBox//
Received an error msg that was particularly perplexing. Since i wasn't sure where exactly to try and get help for it, i thought i'd post here tho i know it's off topic. **NonObjectMemberFunction**
PS if there is a better place to have posted this, i'd be happy to know what page that is.
~& How about this page? Btw, annoying people from whom you want help is always a bad idea... --NilsLindenberg
~~& Well, i wasn't sure if it was an actual bug or not. I thought it might be a server config issue on my part and i didn't want to clutter up this here bug page. Also, and this is totally my bad, it didn't really occur to me that it was Easter w'end and that ppl might have actual lives. Thanks to JavaWoman we snapped out a solution on irc and i added it to the page.


Revision [9187]

Edited on 2005-06-13 08:24:37 by JavaWoman [slight reorg, layout]
Additions:
===Safari and WikiEdit===
===WantedPages problem===
===Problem with handlers===
===XML Feed Problem===
===Problems with double double-quote html?===
===passwords containing $ aren't working===
~~&Solution is to simply use single quotes instead of double quotes so $ is not interpreted as the start of a variable name; involves some changes in the installer. Will likely appear in 1.1.6.1 --JavaWoman
===Messages delayed===
===Extreme extreme slowness===
===Advanced search results reveal confidential info===
~&I think that this is due to the encoding of the MySQL tables. I can't see how that would be fixed with a small touch on the code. If this is the matter then I hope that it also rings the i18n bell too. //Translation to Greek is my bussiness ;)// --GeorgePetsagourakis
~~&IMO the installer should take care that there is a slash if the user doesn't enter it --JavaWoman
~&''The screenshots no longer seem to exist --JavaWoman
""http://gmbowen.educ.unb.ca/wikitest/bug.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
~~~~&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
~&Looks like the weirdness is caused by the ""{{Category}}"" action which assumes the "current page" represents the category - and find pages "belonging to" a category by finding a mention of that page name. Good sign our category system does need an [[CategorySystemOverhaul overhaul]]! --JavaWoman
~&I've now written up my thoughts about a [[WikkaSecureConfig more secure way to handle Wikka's configuration]] (which should also provide also more flexibility). --JavaWoman
"Warning: Compilation failed: nothing to repeat at offset 1 in /.../actions/textsearchexpanded.php on line 33"
~&In my recent RE exploits I have found that a warning of this type comes up when a regular expression isn't quite correct (though not every attempt to match may bring up the warning); haven't investigated further in textsearchexpanded.php though. --JavaWoman
''See also [[,My,Page]] - yup, that's a real page now. ;-)''
~~&I suspect this was caused by a (temporary) configuration problem with rewrite_mode (which will cause odd URLs for TextSearch); none of the changes afterwards show this problem. Classified as not-a-bug. --JavaWoman
Deletions:
====Safari and WikiEdit====
====WantedPages problem====
====Problem with handlers====
====XML Feed Problem====
==== Problems with double double-quote html?====
==== passwords containing $ aren't working====
~~&Solution is to use single quotes instead of double quotes so $ is not interpreted as the start of a variable name; involves some changes in the installer. Will appear in 1.1.6.1 --JavaWoman
====Messages delayed====
====Extreme extreme slowness====
**Advanced search results reveal confidential info**
~&I think that this is due to the encoding of the MySQL tables. I can't see how that would be fixed with a small touch on the code. If this is the matter then I hope that it also rings the i18n bell too. //Translation to Greek is my bussiness ;)//
~&""--""GeorgePetsagourakis
http://gmbowen.educ.unb.ca/wikitest/bug.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''
~~~~&''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''
~&''Looks like the weirdness is caused by the ""{{Category}}"" action which assumes the "current page" represents the category - and find pages "belonging to" a category by finding a mention of that page name. Good sign our category system does need an [[CategorySystemOverhaul overhaul]]! --JavaWoman''
~&''I've now written up my thoughts about a [[WikkaSecureConfig more secure way to handle Wikka's configuration]] (which should also provide also more flexibility). --JavaWoman''
''Warning: Compilation failed: nothing to repeat at offset 1 in /.../actions/textsearchexpanded.php on line 33''
~&''In my recent RE exploits I have found that a warning of this type comes up when a regular expression isn't quite correct (though not every attempt to match may bring up teh warning); haven't investigated further in textsearchexpanded.php though. --JavaWoman''
,''Note: see also [[,My,Page]] - yup, that's a real page now. ;-)''
~&I suspect this was caused by a (temporary) configuration problem with rewrite_mode (which will cause odd URLs for TextSearch); none of the changes afterwards show this problem. Classified as not-a-bug. --JavaWoman
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
===Logout problem===
With Wikka Wakka Wiki 1.1.6.0. Php5
Login.
Go to Preferences/Logout, click the logout button
=> it goes to:
%%[[mypath]]/wikka.php?wakka=UserSettings?action=logout%%
So, it tries to find the "UserSettings?action=logout" page, doesn't and propose to create it.
The path should be:
%%[[mypath]]/wikka.php?wakka=UserSettings&action=logout%%
~&Looks like mod_rewrite is configured incorrect, please take a look at ModRewrite! --NilsLindenberg
~&Not a bug -- JavaWoman


Revision [9173]

Edited on 2005-06-12 22:28:57 by JavaWoman [two issues classified as not-a-bug (to be moved later)]
Additions:
"" [ (20:46 CEST∞) [history∞] - TextSearch?phrase=ElVitoWakkaWiki∞ ⇒ ppp-82-135-6-82.mnet-online.de ]"" which seems kinda wrong. -- Mike (aka GmBowen)
~&I suspect this was caused by a (temporary) configuration problem with rewrite_mode (which will cause odd URLs for TextSearch); none of the changes afterwards show this problem. Classified as not-a-bug. --JavaWoman
===Email Addresses===
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
===Logout problem===
~&Not a bug -- JavaWoman
Deletions:
"" [ (20:46 CEST?) [history?] - TextSearch?phrase=ElVitoWakkaWiki? ? ppp-82-135-6-82.mnet-online.de ]"" which seems kinda wrong. -- Mike (aka GmBowen)
==Email Addresses==
- Mod_rewrite : take a look at FaviconDotIco and RobotsDotTxt
====Logout problem====


Revision [9172]

Edited on 2005-06-12 22:10:22 by JavaWoman [comment re: Category name matching]
Additions:
~&I cannot reproduce this on this server, nor on my own development system - at least not with the [[WikkaBetaFeatures beta and alpha]] versions of the category action. Possibly dependent on the version of PHP used where older versions may use a slightly different database query to find pages referring to a category. Tammy, if you're reading this: which version of PHP are you using? (We should test with the 'lower-PHP version of the query!) --JavaWoman


Revision [9171]

Edited on 2005-06-12 22:00:16 by JavaWoman [minor]
Additions:
Um, I don't know how to describe this really. Put ""{{include page="Category Documentation"}}"" (//without the space!//)on the SandBox page....I can't figure out why it gives that output as Sandbox doesn't own anything.
Deletions:
Um, I don't know how to describe this really. Put ""{{include page="CategoryDocumentation"}}"" on the SandBox page....I can't figure out why it gives that output as Sandbox doesn't own anything.


Revision [9003]

Edited on 2005-06-08 18:35:21 by JameSmith [minor]
Additions:
~~&Another way is to follow what (I think) PHP does for session cleanup. Set a threshold and test if a random number (between 0 and 1, inclusive of 0) is less than that threshold. If so, then do cleanup. Otherwise don't. The threshold is then a percentage chance that cleanup will happen on a particular request instead of hoping that the time falls just right. --JameSmith


Revision [8941]

Edited on 2005-06-07 21:26:40 by JavaWoman [mod_rewrite issue in WikiEdit (more descriptive heading)]
Additions:
===mod_rewrite issue in WikiEdit===
Deletions:
===mod_rewrite issue===


Revision [8939]

Edited on 2005-06-07 20:51:37 by MovieLady [mod_rewrite on the wiki edit help link]
Additions:
~& It assumes that you're using mod_rewrite and goes to the "pretty" url (wikka.jsnx.com/""FormattingRules"" instead of wikka.jsnx.com/wikka.php?wakka=""FormattingRules"") - this needs to either be editable (or is it somewhere in the WikiEdit files and I just haven't found it?) or check with the wikka.config.php to make sure it's using the correct base_url. --MovieLady


Revision [8891]

Edited on 2005-06-06 19:20:11 by JavaWoman [minor]
Additions:
This seems to be a combination of a **GeSHi** bug (there should at least a ##&nbsp;## be generated as content) combined with a **gecko** oddity (or bug?) that will render a number for an ordered list item but not give it a normal line height if the list item is empty.
Deletions:
This seems to be a combination of a **GeSHi** bug (there should at least a   be generated) combined with a **gecko** oddity (or bug?) that will render a number for an ordered list item but not give it a normal line height if the list item is empty.


Revision [8890]

Edited on 2005-06-06 19:17:49 by JavaWoman [added Code display problem]
Additions:
===Code display problem===
The following combination of conditions triggers the problem:
~-multi-line comment (for instance a multi-line /*........*/ block in php)
~-empty lines within such a comment
~-line numbering turned on
When viewed in Mozilla or Firefox (at least - possibly others), the empty lines **overlap** the preceding lines, as can be seen by the line numbers.
Looking at the generated code, an empty line within a multi-line comment (with line numbers) results in this code: %%(html4strict)<li><div class="de1"><span class="coMULTI"></span></div></li>%%---while an empty line elsewhere results in %%(html4strict)<li><div class="de1"> </div></li>%%---Note the ##&nbsp;## in the latter case (which gives the div actual content) while the empty multi-comment line has nothing but an **empty** span, and no actual content.
This seems to be a combination of a **GeSHi** bug (there should at least a   be generated) combined with a **gecko** oddity (or bug?) that will render a number for an ordered list item but not give it a normal line height if the list item is empty.
**Workaround:** add some whitespace to the empty lines - a single tab works (a space probably will as well).


Revision [8684]

Edited on 2005-05-29 11:08:53 by JavaWoman [move to subcategory]
Additions:
CategoryDevelopmentSuggestions
Deletions:
CategoryDevelopment


Revision [8510]

Edited on 2005-05-26 09:18:28 by DarTar [moving solved logout issue]
Deletions:
===Logout===
After Wikka has been installed.. I tested the login.. It was good..
But when I tried logout.. the logout button did not work.
Would anybody tells me why? Also how can I logout?
I want to solve the ougout problem.. help me.. please..
When I tried logout..
the new wikka page, UserSettings?action=logout, has been created.. without logout..
You can test the logout button in my UserSettings page.. here it is..
[[http://here.cherilove.co.kr/Wikka/wikka.php?wakka=UserSettings]]
~& Hi HeRe, it looks like a problem with your ModRewrite configuration. If it's on, the logout URL should be: ##""http://here.cherilove.co.kr/Wikka/wikka.php?wakka=UserSettings&action=logout""## (notice that ##?## is replaced by a ##&## in the URL). Check in your [[ConfigurationOptions configuration file]] that you have the following lines: --- %%(php)
"base_url" => "http://here.cherilove.co.kr/Wikka/wikka.php?wakka=",
"rewrite_mode" => "0",
%% --- I'm just guessing, though: your wikka installation is no more online -- DarTar ---(Note to the Crew, since this kind of issue occurs quite frequently - see also at the bottom of this page - maybe we should set up a dedicated workaround page - like CannotLogoutWorkaround -, even if the correct solution is already documented in the ModRewrite page).
~~& You are Right.. Thank you so much DarTar.. Now I can understand the Wikka more. Have a good night.. -- HeRe ^^*


Revision [8475]

Edited on 2005-05-25 18:58:16 by JavaWoman [List parsing bug? - fixed]
Additions:
~~&This is indeed an "end of page" problem: teh formatter has some code to close tags inadvertently left open, but does not do this for lists and indent (nor even fro *all* open tags). Fix coded and tested - this will be in 1.1.6.1. --JavaWoman


Revision [8446]

Edited on 2005-05-24 23:33:23 by JavaWoman [passwords containing $ nailed]
Additions:
~~&Solution is to use single quotes instead of double quotes so $ is not interpreted as the start of a variable name; involves some changes in the installer. Will appear in 1.1.6.1 --JavaWoman


Revision [8348]

Edited on 2005-05-20 13:12:09 by PivWan [Reply to viewcode handler bug]
Additions:
~~~& Okay, hadn't the whole story. So, it's a bug :) -- PivWan


Revision [8345]

Edited on 2005-05-20 11:05:40 by HeRe [Reply to viewcode handler bug]
Additions:
~~& You are Right.. Thank you so much DarTar.. Now I can understand the Wikka more. Have a good night.. -- HeRe ^^*
Deletions:
~~& You are Right.. Thank you so much.. Now I can understand the Wikka more. Have a good night.. ^^*


Revision [8344]

Edited on 2005-05-20 11:03:44 by HeRe [Reply to viewcode handler bug]
Additions:
~~& You are Right.. Thank you so much.. Now I can understand the Wikka more. Have a good night.. ^^*


Revision [8335]

Edited on 2005-05-20 06:35:39 by DarTar [replying to HeRe]
Additions:
%% --- I'm just guessing, though: your wikka installation is no more online -- DarTar ---(Note to the Crew, since this kind of issue occurs quite frequently - see also at the bottom of this page - maybe we should set up a dedicated workaround page - like CannotLogoutWorkaround -, even if the correct solution is already documented in the ModRewrite page).
Deletions:
%% --- I'm just guessing, though: your wikka installation is no more online -- DarTar ---(Note to the Crew, since this kind of issue occurs quite frequently, maybe we should set up a dedicated workaround page - like CannotLogoutWorkaround -, even if the correct solution is already documented in the ModRewrite page)


Revision [8334]

Edited on 2005-05-20 06:34:50 by DarTar [replying to HeRe]
Additions:
%% --- I'm just guessing, though: your wikka installation is no more online -- DarTar ---(Note to the Crew, since this kind of issue occurs quite frequently, maybe we should set up a dedicated workaround page - like CannotLogoutWorkaround -, even if the correct solution is already documented in the ModRewrite page)
Deletions:
%% --- I'm just guessing, though: your wikka installation is no more online -- DarTar ---(Note to the Crew, since this kind of issue occurs quite frequently, maybe we should set up a dedicated workaround page, even if the correct solution is already documented in the ModRewrite page)


Revision [8333]

Edited on 2005-05-20 06:33:16 by DarTar [replying to HeRe]
Additions:
~& Hi HeRe, it looks like a problem with your ModRewrite configuration. If it's on, the logout URL should be: ##""http://here.cherilove.co.kr/Wikka/wikka.php?wakka=UserSettings&action=logout""## (notice that ##?## is replaced by a ##&## in the URL). Check in your [[ConfigurationOptions configuration file]] that you have the following lines: --- %%(php)
Deletions:
~& Hi HeRe, it looks like a problem with your ModRewrite configuration. If it's on, the logout URL should be: ##""http://here.cherilove.co.kr/Wikka/wikka.php?wakka=UserSettings&action=logout""## (notice that #?# is replaced by a #&# in the URL). Check in your [[ConfigurationOptions configuration file]] that you have the following lines: --- %%(php)


Revision [8332]

Edited on 2005-05-20 06:32:38 by DarTar [replying to HeRe]
Additions:
~& Hi HeRe, it looks like a problem with your ModRewrite configuration. If it's on, the logout URL should be: ##""http://here.cherilove.co.kr/Wikka/wikka.php?wakka=UserSettings&action=logout""## (notice that #?# is replaced by a #&# in the URL). Check in your [[ConfigurationOptions configuration file]] that you have the following lines: --- %%(php)
Deletions:
~- Hi HeRe, it looks like a problem with your ModRewrite configuration. If it's on, the logout URL should be: ##""http://here.cherilove.co.kr/Wikka/wikka.php?wakka=UserSettings&action=logout""## (notice that #?# is replaced by a #&# in the URL). Check in your [[ConfigurationOptions configuration file]] that you have the following lines: --- %%(php)


Revision [8331]

Edited on 2005-05-20 06:32:12 by DarTar [replying to HeRe]
Additions:
~- Hi HeRe, it looks like a problem with your ModRewrite configuration. If it's on, the logout URL should be: ##""http://here.cherilove.co.kr/Wikka/wikka.php?wakka=UserSettings&action=logout""## (notice that #?# is replaced by a #&# in the URL). Check in your [[ConfigurationOptions configuration file]] that you have the following lines: --- %%(php)
"base_url" => "http://here.cherilove.co.kr/Wikka/wikka.php?wakka=",
"rewrite_mode" => "0",
%% --- I'm just guessing, though: your wikka installation is no more online -- DarTar ---(Note to the Crew, since this kind of issue occurs quite frequently, maybe we should set up a dedicated workaround page, even if the correct solution is already documented in the ModRewrite page)


Revision [8330]

Edited on 2005-05-20 02:58:47 by HeRe [replying to HeRe]
Additions:
Would anybody tells me why? Also how can I logout?
I want to solve the ougout problem.. help me.. please..
When I tried logout..
the new wikka page, UserSettings?action=logout, has been created.. without logout..
Deletions:
Would anybody tells me why? Also how can I logout? How can I solve it?
When I tried logout.. The new wikka page, UserSettings?action=logout, has been created.


Revision [8329]

Edited on 2005-05-20 02:55:23 by HeRe [replying to HeRe]
Additions:
Would anybody tells me why? Also how can I logout? How can I solve it?
You can test the logout button in my UserSettings page.. here it is..
Deletions:
Would anybody tells me why? Also how can I logout?
You can test my login page.. here it is..


Revision [8328]

Edited on 2005-05-20 02:53:12 by HeRe [replying to HeRe]
Additions:
===Logout===


Revision [8327]

Edited on 2005-05-20 02:51:05 by HeRe [replying to HeRe]
Additions:
After Wikka has been installed.. I tested the login.. It was good..
But when I tried logout.. the logout button did not work.
Would anybody tells me why? Also how can I logout?
When I tried logout.. The new wikka page, UserSettings?action=logout, has been created.
You can test my login page.. here it is..
[[http://here.cherilove.co.kr/Wikka/wikka.php?wakka=UserSettings]]


Revision [8276]

Edited on 2005-05-18 10:47:48 by JavaWoman [Comment re View Code Handler]
Additions:
~~&Actually, I suggested Rick reported it here since I **do** consider it a bug. It is a **page** handler so the handler should look for a page; I think it should return //something// at least. IMO the best solution would be to generate a warning like "Page does not exist" when the page isn't found, or use the "do you want to create it?" we use when accessing a non-exstant page. --JavaWoman


Revision [8272]

Edited on 2005-05-18 08:23:19 by PivWan [Comment regarding "View Code Handler issue"]
Additions:
~& Technically, it isn't a bug: Wikka tries to display original data concerning the page. As it doesn't exists, Wikka displays nothing. It isn't a bug but a non-existent feature of Wikka, so I would put this comment in SuggestionBox instead of here. JavaWoman? DarTar? What do you think of it? -- PivWan


Revision [8263]

Edited on 2005-05-17 21:34:26 by JavaWoman [Installer array_merge()]
Additions:
===Installer array_merge()===
//Mentioned in passing on #wikka by a user having actually other problems installing Wikka.//
Remember the array_merge() problem in wikka.php under PHP5? Solved in 1.1.6.0.
Guess what: the same problem still exists - but in the installer itself (##/setup/install.php## - line 7): the second argument is (again) not initialized so users get a warning stating "Argument #2 is not an array in /var/www/html/Wikka/setup/install.php on line 7".
We'd better solve it in the installer as well. --JavaWoman


Revision [8113]

Edited on 2005-05-14 04:59:38 by JsnX [reply to JavaWoman about purging of pages]
Additions:
~&That's correct. I'm not the author of this code, but the intention is clear to me. It's designed to be a performance improvement. Rather than call the Maintenance function for every single page view(!), it adds some randomness based on the remainder of GetMicroTime() divided by 3. For a busy site this could make a significant drop in MySQL queries. I have done some brief testing of this code and found that on average the Maintenance function was called about every four page views. For any site that has even moderate traffic, the Maintenance function will be triggered sufficiently. To answer your question, yes, this condition should be there. However, maybe there should be a configuration option that admins could tweak if they are obsessed and need certainty that pages get purged. -- JsnX


Revision [8058]

Edited on 2005-05-12 22:00:09 by RickLaChariteIII [bug]
Additions:
===View Code Handler issue===
The view code handler does not display any message if the page does not exist. [[http://wikka.jsnx.com/NonExistantPage/showcode Example]] -- Rick


Revision [8038]

Edited on 2005-05-12 07:33:42 by DarTar2 [adding empty mail bug]
Additions:
===Email deletion after registration===
On 1.1.6.0 a registered user can modify his or her settings and store an **empty email address**. The engine does not warn the user and accepts an empty value. This bug should be fixed or at least the behavior of UserSettings should be made consistent with the registration requirements (if an email is required, it is required also //after// registering). Note that this might break (beta-)actions based on user email, such as FeedbackActionUpgrade (to be checked)-- DarTar


Revision [7743]

Edited on 2005-04-30 16:21:03 by JavaWoman [page purge problem]
Additions:
===Purging of pages not always happening===
//reported by |Sam| on #wikka, writeup by me --JavaWoman//
Purging of pages doesn't always seem to happen. |Sam| had the page_purge_time set to 1 (which should purge page versions older than one day) but didn't see them being actually purge. Purging is done in the Maintenance() method in ##wikka.php## executed by the main Run() method. However, there is an extra condition here: %%(php)if(!($this->GetMicroTime()%3)) $this->Maintenance();%% I suspect this may cause the Maintenance() method not being executed. The intention of this (undocumented) condition isn't clear to me - should it really be there? --JavaWoman


Revision [7742]

Edited on 2005-04-30 16:14:37 by JavaWoman [another onyx-rss problem]
Additions:
Another problem with Onyx-RSS was just reported by |Sam| on #wikka: in spite of cacheing it seems quite slow, taking something like 2.5 seconds for rendering after retrieving a feed (compared to a normal page rendering time of 0.06 seconds). We should look at the efficiency (or not) of this class - maybe it's time to move to another one that's being actively maintained. --JavaWoman


Revision [7735]

Edited on 2005-04-29 18:03:45 by NilsLindenberg [copied two suggestions to SB, reply to JW and anonymus]
Additions:
~~&It wont do, since the link-table has no latest col ;). But shouldn't the delete-handler delete these links from the table anyway? --NilsLindenberg
~&Looks like mod_rewrite is configured incorrect, please take a look at ModRewrite! --NilsLindenberg
Deletions:
Bugs I've found:
- Security: I was wondering whether it would be possible to store IPs for registered users as well. That way you can ban them via .htaccess if necessary.
- ''Last known IP or every IP they ever connect from? I'd be willing to store one last known IP per user. '' - JsnX
- ''Last known IP please :) Thanks.'' - Sam
- ''I'd suggest adding *two* distinct fields to ##wikka_users##: Last Login IP/Hostname + Last Login Time'' - DarTar
- ''I was also thinking of a way to ban users directly from the wiki (much in the same way as referrers are added to the blacklist of spammers). This might turn out easier to implement than a //user deleting action// (which was one of the ideas discussed [[UserAdmin here]])'' - DarTar
- Security: Single-click restore of previous versions (without copying/pasting).
- ''Yes, this will be implemented at some point.'' - JsnX
- I should point out that there is an alternative to copying/pasting.
- Go to the revisions page.
- Click the date and time link that you would like to revert back to.
- Click the 'Re-edit this old revision' button.
- Click the 'Store' button.
Thanks - Sam


Revision [7731]

Edited on 2005-04-29 16:50:09 by OlivierPerron [copied two suggestions to SB, reply to JW and anonymus]
Additions:
~~&Same problem for me as well. I've modified wikka.php to use different session names (add: session_name($wakkaConfig["wakka_name"]); just above the session_start(); ) and different cookies ("wikka_user_name@".$this->config["wakka_name"] and "wikka_pass@".$this->config["wakka_name"]) as my 2 wikkas do have have different wakka_names. Seems to behave as expected now. --OlivierPerron
Deletions:
~~&Same problem for me as well. I've modified wikka.php to use different cookies ("wikka_user_name@".$this->config["wakka_name"] and "wikka_pass@".$this->config["wakka_name"]) as my 2 wikkas do have have different wakka_names, but this doesn't help. I've just figured out that my 2 wikkas are using the same PHPSESSID cookie... The solution must lie around this cookie... -- OlivierPerron
~~~&I think I've got it now. I've also had to change every $_SESSION["user"] to $_SESSION["user".$this->config["wakka_name"]]. However I'm still wondering if there is a need to differentiate also every $_SESSION["foo"] which is in the code? --OlivierPerron


Revision [7725]

Edited on 2005-04-29 15:56:18 by OlivierPerron [copied two suggestions to SB, reply to JW and anonymus]
Additions:
~~~&I think I've got it now. I've also had to change every $_SESSION["user"] to $_SESSION["user".$this->config["wakka_name"]]. However I'm still wondering if there is a need to differentiate also every $_SESSION["foo"] which is in the code? --OlivierPerron


Revision [7723]

Edited on 2005-04-29 15:33:58 by OlivierPerron [copied two suggestions to SB, reply to JW and anonymus]
Additions:
~~&Same problem for me as well. I've modified wikka.php to use different cookies ("wikka_user_name@".$this->config["wakka_name"] and "wikka_pass@".$this->config["wakka_name"]) as my 2 wikkas do have have different wakka_names, but this doesn't help. I've just figured out that my 2 wikkas are using the same PHPSESSID cookie... The solution must lie around this cookie... -- OlivierPerron
Deletions:
~~&Same problem for me as well. I've modified wikka.php to use different cookies ("wikka_user_name@".$this->config["wakka_name"] and "wikka_pass@".$this->config["wakka_name"]) as my 2 wikkas do have have different wakka_names, but this doesn't help. I've just figured out that my 2 wikkas are using the same SESSION cookie... The solution must lie around this cookie... -- OlivierPerron


Revision [7722]

Edited on 2005-04-29 15:22:39 by OlivierPerron [copied two suggestions to SB, reply to JW and anonymus]
Additions:
~~&Same problem for me as well. I've modified wikka.php to use different cookies ("wikka_user_name@".$this->config["wakka_name"] and "wikka_pass@".$this->config["wakka_name"]) as my 2 wikkas do have have different wakka_names, but this doesn't help. I've just figured out that my 2 wikkas are using the same SESSION cookie... The solution must lie around this cookie... -- OlivierPerron


Revision [7695]

Edited on 2005-04-28 20:57:46 by JavaWoman [RSS feed hangs browser]
Additions:
**Please post recently discovered bugs on the //top// of this page (just below this note).**
===RSS feed action hangs or crashes browser if feed does not exist===
//reported by velkr0 on #wikka, analysis and writeup by me -- JavaWoman//
**Problem**: When the rss action is included in a page with a feed URL that happens not to exist (or not exist any more), the page "hangs"; once in this state, editing the page also isn't possible: the hang continues until the browser times out or is closed.
The obvious cause is that neither the ""{{rss}}"" action nor the underlying onyx-rss class checks for //existence// of the resource the feed URL refers to. The problem is already hard to detect when you are first including a feed in a page and maybe make a typo in the feed URL. But if your Wikka provides a page with one or more feeds, and a feed suddenly disappears (or is down momentarily) the result will be very annoying for your visitors.
**Solution**: Either the onyx-rss class or the rss action should check for the availability of the feed (for instance with a HEAD request) before actually trying to retrieve it. Since the class provides caching, the best option would be to handle it in the class (by subclassing the necessary method(s)). If a version of the feed still exists in the cache that version could be displayed (probably this happens automatically anyway), otherwise an error message should be generated instead of the feed output. --JavaWoman
Deletions:
**Please post recently discovered bugs on the //top// of this page (just below this note).**---


Revision [7617]

Edited on 2005-04-26 10:34:10 by JavaWoman [Safari - WikiEdit problem added]
Additions:
====Safari and WikiEdit====
(//copied from SandBox - JavaWoman//)
Safari crashes when I use a formatting button. (DarTar has confirmed this.)
It looks like either Safari has a bug in their JavaScript implementation, or WikiEdit's JavaScript isn't (sufficiently) cross-browser, or both. While the browser shouldn't crash on encountering JavaScript it cannot handle, we certainly need an edit toolbar that's more cross-browser (it doesn't appear at all in Opera 7.2x on Windows). --JavaWoman


Revision [7610]

Edited on 2005-04-26 08:32:21 by JavaWoman [Wantedpages problem]
Additions:
====WantedPages problem====
The list of Wantedpages may be handy, but I just found the list is not sorted alphabetically, making it hard to scan. That's a "UI bug". The list should be sorted, at least - and preferably split up by starting letters, as in PageIndex (when all pages are shown). --JavaWoman


Revision [7464]

Edited on 2005-04-22 08:01:59 by JavaWoman [fixed sig]
Additions:
--MunehiroYamakawa
Deletions:
--~~~


Revision [7419]

Edited on 2005-04-20 12:19:08 by NilsLindenberg [copied non-bug to WikkaBugsResolved]
Deletions:
===Opera and layer===
Opera browser doesn't like a right layer a the end of a page :(
~&A "layer" is nothing but a div; Wikka's "float" boxes are floated divs. When a floated block is longer (vertically) than the section it precedes, it will (vertically) overlap with the next section. This is just standard CSS (the effect isn't limited to Opera either). To prevert this overlap happening at the end of a page (or section), add ""::c::"" at the end of the page (or section), which will create an empty div a with clear: both style. **Not a bug** - just standard CSS for which Wikka markup provides an appropriate mechanism. --JavaWoman


Revision [7267]

Edited on 2005-04-15 08:03:08 by MunehiroYamakawa [added handlers problem]
Additions:
====Problem with handlers====
I noted this problem with handlers. If you specify, for example
http://url/wiki/?wakka=HomePage/../../index
You can trick the include out of the /handlers/page directory. I'm not sure it can be a problem, but indeed it's weird.
--~~~


Revision [7176]

Edited on 2005-04-09 20:28:36 by TonyH [added handlers problem]
Additions:
~~& I found the problem - for the user registration you have to change wikka.config.php - the web based software I was using to edit the file had added some blank lines at the bottom of the config file. What this had to do with XML I am not sure but it works fine now.
Deletions:
~~& I found the problem - for the user registration you have to change wikka.config.php - the web based software I was using to edit the file had added some blank lines at the bottom of the config file. Whta this had to do with XML I am not sure but it works fine now.


Revision [7175]

Edited on 2005-04-09 20:27:41 by TonyH [added handlers problem]
Additions:
~~& I found the problem - for the user registration you have to change wikka.config.php - the web based software I was using to edit the file had added some blank lines at the bottom of the config file. Whta this had to do with XML I am not sure but it works fine now.


Revision [7174]

Edited on 2005-04-09 19:53:08 by TonyH [added handlers problem]
Additions:
~~& It is standard except for patches applied for UserRegistration and TableAction. I installed a second fresh wikka and it worked OK so I must have broken something.
Deletions:
~~& It is standard except for patches applied for UserRegistration and TableAction. I installed a fresh wikka and it worked OK so I must have broken something.


Revision [7173]

Edited on 2005-04-09 19:52:41 by TonyH [added handlers problem]
Additions:
~~& It is standard except for patches applied for UserRegistration and TableAction. I installed a fresh wikka and it worked OK so I must have broken something.
Deletions:
~~& It is standard except for adding the UserRegistration code. Which php file is generating the xml - I can upload the code again to be sure. Further update - If I save the link to disk and then look at it - it appears fine.


Revision [7172]

Edited on 2005-04-09 19:20:01 by TonyH [added handlers problem]
Additions:
~~& It is standard except for adding the UserRegistration code. Which php file is generating the xml - I can upload the code again to be sure. Further update - If I save the link to disk and then look at it - it appears fine.
Deletions:
~~& It is standard except for adding the UserRegistration code. Which php file is generating the xml - I can upload the code again to be sure.


Revision [7171]

Edited on 2005-04-09 19:14:53 by TonyH [added handlers problem]
Additions:
~~& It is standard except for adding the UserRegistration code. Which php file is generating the xml - I can upload the code again to be sure.
Deletions:
~~& It is standard apart except for adding the UserRegistration code.


Revision [7170]

Edited on 2005-04-09 19:12:53 by TonyH [added handlers problem]
Additions:
~~& It is standard apart except for adding the UserRegistration code.


Revision [7167]

Edited on 2005-04-09 16:07:12 by TimoK [Reply to TonyH]
Additions:
~& There is whitespace before the xml declaration, which is not allowed as far as I know. Not sure tho **why** it is there. Is that an out-of-the-box wikka 1.1.6.0?


Revision [7166]

Edited on 2005-04-09 13:35:33 by TonyH [Reply to TonyH]

No Differences

Revision [7165]

Edited on 2005-04-09 13:34:19 by TonyH [Reply to TonyH]
Additions:
====XML Feed Problem====
When clicking on the XML feed link at the bottom of the page - get the following :
XML Parsing Error: xml processing instruction not at start of external entity
Location: http://www.cataclysmos.org/wiki/RecentChanges/recentchanges.xml
Line Number 10, Column 1:<?xml version="1.0" encoding="ISO-8859-1"?>
^


Revision [7022]

Edited on 2005-03-31 00:07:27 by MonstoBrukes [Reply to TonyH]
Additions:
~~& Well, i wasn't sure if it was an actual bug or not. I thought it might be a server config issue on my part and i didn't want to clutter up this here bug page. Also, and this is totally my bad, it didn't really occur to me that it was Easter w'end and that ppl might have actual lives. Thanks to JavaWoman we snapped out a solution on irc and i added it to the page.


Revision [6996]

Edited on 2005-03-29 15:12:01 by NilsLindenberg [added error-message + comment]
Additions:
==== Problems with double double-quote html?====
//moved from SuggestionBox//
Received an error msg that was particularly perplexing. Since i wasn't sure where exactly to try and get help for it, i thought i'd post here tho i know it's off topic. **NonObjectMemberFunction**
PS if there is a better place to have posted this, i'd be happy to know what page that is.
~& How about this page? Btw, annoying people from whom you want help is always a bad idea... --NilsLindenberg


Revision [6933]

Edited on 2005-03-26 19:39:28 by PivWan [Idea for $ in mysql passwords]
Additions:
~& Did you tried to escape them? For example "john$doe" replaced by "john\$doe". AFAIK, it isn't a wikka bug but a php engine's side effect. All string beginning with $ are considered as variables and are interpreted as is. -- PivWan


Revision [6928]

Edited on 2005-03-26 19:08:04 by EltharielHdh [Idea for $ in mysql passwords]
Additions:
==== passwords containing $ aren't working====
The installation succeed but the wiki doesn't work(connection pb if the db password contains one or more dollars symbols '$'.
The error occur at the creation of the wakka object :
"The wiki is currently unavailable. Error : Unable to connect to the Mysql database"


Revision [6884]

Edited on 2005-03-24 17:47:58 by NilsLindenberg [add delayed messages]
Additions:
====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).


Revision [6882]

Edited on 2005-03-24 13:46:03 by KenDen [add delayed messages]
Additions:
%%[[mypath]]/wikka.php?wakka=UserSettings?action=logout%%
%%[[mypath]]/wikka.php?wakka=UserSettings&action=logout%%
Deletions:
[[mypath]]/wikka.php?wakka=UserSettings?action=logout
[[mypath]]/wikka.php?wakka=UserSettings&action=logout


Revision [6881]

Edited on 2005-03-24 13:45:15 by KenDen [add delayed messages]
Additions:
With Wikka Wakka Wiki 1.1.6.0. Php5
Deletions:
With Wikka Wakka Wiki 1.1.6.0.


Revision [6880]

Edited on 2005-03-24 13:44:38 by KenDen [add delayed messages]
Additions:
====Logout problem====
With Wikka Wakka Wiki 1.1.6.0.
Login.
Go to Preferences/Logout, click the logout button
=> it goes to:
[[mypath]]/wikka.php?wakka=UserSettings?action=logout
So, it tries to find the "UserSettings?action=logout" page, doesn't and propose to create it.
The path should be:
[[mypath]]/wikka.php?wakka=UserSettings&action=logout


Revision [6853]

Edited on 2005-03-23 13:37:58 by BarryKauler [add delayed messages]
Additions:
====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?


Revision [6839]

Edited on 2005-03-22 09:47:23 by JavaWoman [credit + layout]
Additions:
//Thanks to MrTrick for pointing out this problem//


Revision [6838]

Edited on 2005-03-22 09:19:44 by JavaWoman [ypot (uploaded files)]
Additions:
~2) Mozilla seems to pick up the suggested file name from the Content-Disposition header. (raw)urlencoding the file name here works, but then displays the name with the encoding; enclosing the file name in (double) quotes works better, showing the full file name with spaces. This has the advantage that the original file name is preserved - //provided// both the server OS and the downloading user's OS can handle such file names.---
Deletions:
~2) Mozilla seems to pick up the suggested file name from the Content-Disposition header. (raw)urlencoing the file name here works, but then displays the name with the encoding; enclosing the file name in (double) quotes works better, showing the full file name with spaces. This has the advantage that the original file name is preserved - //provided// both the server OS and the downloading user's OS can handle such file names.---


Revision [6837]

Edited on 2005-03-22 09:16:52 by JavaWoman [spaces in uploaded file names - description and solutions]
Additions:
It is possible to upload files with a space in the file name. However, when trying to download such a file things don't work as expected: in Mozilla browsers (Mozilla, Firefox, etc.) the suggested filename for the download is truncated at the first space.
Two possible solutions:
~1) Prevent that file names are //stored// with spaces in the name; simply replacing all spaces with underscores would do the trick and keep the file name recognizable. This has the advantage that no assumptions are being made about the server OS //or// the user's OS as to whether spaces in file names are valid.
~2) Mozilla seems to pick up the suggested file name from the Content-Disposition header. (raw)urlencoing the file name here works, but then displays the name with the encoding; enclosing the file name in (double) quotes works better, showing the full file name with spaces. This has the advantage that the original file name is preserved - //provided// both the server OS and the downloading user's OS can handle such file names.---
Take your pick ;-) -- JavaWoman
Deletions:
It is possible to upload files with a space in the file name. However, when trying to download such a file things don't work. //(more details later)// -- JavaWoman


Revision [6836]

Edited on 2005-03-22 08:11:50 by JavaWoman [new bug - more details later]
Additions:
===Spaces in uploaded files===
It is possible to upload files with a space in the file name. However, when trying to download such a file things don't work. //(more details later)// -- JavaWoman


Revision [6825]

Edited on 2005-03-21 20:19:11 by JavaWoman [ypots (frayed nerves today)]
Additions:
~~&The basic problem is that the installer does not use any system routines but instead JavaScript for validation. And the RE it uses for email validation is really, really braindead. Yes, very annoying as I've not seen the user back in #wikka either - we may have lost a user. I could have given a workaround if only I'd not been sleeping. --- Email library is not quite ready but getting close (needs some restructuring, basically); it will be a class, with several abstract methods so the installer should be able to use it as well (provided it can find the class file). And I'm learning some good tricks working on the sessions module (which might also be useful for Wikka). But the installer needs a major overhaul in any case. Sigh... --JavaWoman
Deletions:
~~&The basic problem is that the installer does not use any system routines but instead JavaScript for validation. And the RE it uses for email validation is really, really braindead. Yes, very annoying as I've not seen the user back in #wikka either - we may have lost a user. I could have given a workaround if only I'd not been sleeping. --- Email library is not quite ready but getting close (needs some restructuring, basically); it will be a class, with several abstract methods so the installer should be able to use it as well (provided it can find the class file). And I'm learnngi some good tricks worknig on teh sessions moduke (which might also be useful for Wikka). But the installer needs a major overhaul in any case. Sigh... --JavaWoman


Revision [6824]

Edited on 2005-03-21 20:16:03 by JavaWoman [reaction to temporary password retrieval problem]
Additions:
~~~~~~~~~~~&**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


Revision [6822]

Edited on 2005-03-21 17:42:51 by JavaWoman [reply re: admin email (validation)]
Additions:
~~&The basic problem is that the installer does not use any system routines but instead JavaScript for validation. And the RE it uses for email validation is really, really braindead. Yes, very annoying as I've not seen the user back in #wikka either - we may have lost a user. I could have given a workaround if only I'd not been sleeping. --- Email library is not quite ready but getting close (needs some restructuring, basically); it will be a class, with several abstract methods so the installer should be able to use it as well (provided it can find the class file). And I'm learnngi some good tricks worknig on teh sessions moduke (which might also be useful for Wikka). But the installer needs a major overhaul in any case. Sigh... --JavaWoman


Revision [6814]

Edited on 2005-03-21 13:35:16 by DarTar [Reply to JW on email validation]
Additions:
~& Gosh, this is //really// annoying. JW, any news from your general-purpose [[WikkaEmailToolkit email validation]] functions ;-) -- DarTar


Revision [6812]

Edited on 2005-03-21 13:28:48 by DarTar [Confirming passw retrieval problem for non-admins]
Additions:
~~~~~~~~~~& JsnX, I tried again to retrieve my password from one of my non-admin clones (like DarTar2) and I still receive no email -- DarTar
Deletions:
~~~~~~~~~~& YanB, is this problem still pending? -- DarTar


Revision [6807]

Edited on 2005-03-21 09:18:46 by DarTar [Reply to YanB]
Additions:
~~~~~~~~~~& YanB, is this problem still pending? -- DarTar


Revision [6806]

Edited on 2005-03-21 08:42:34 by JavaWoman [reply to Ian re: page purge]
Additions:
~~~&I'm good enough at SQL that I need the manual for that. ;-) As far as I can determine, you need two statements (semi pseudo code): 1) a ##select count(*) from pages where ...## to determine the current number of records; and 2) ##delete from pages where ... order by [timestamp] limit [$count - $pages_keep]##. You can't do a subquery in delete (yet) so the count must be a separate step (but it should be very fast). --JavaWoman


Revision [6805]

Edited on 2005-03-21 02:29:44 by IanAndolina [reply to JW]
Additions:
~~&Sounds good to me - can you think of an elegant way to modify the SQL query to only delete pages older than X that are also more than Xth on a list of revisions. I'm sure I can come up with something ugly ;) --IanAndolina


Revision [6804]

Edited on 2005-03-21 00:40:57 by BarkerJr [Added ACL Cancel Bug]
Additions:
===ACL Cancel===
If you edit the ACL on a page, click "Store ACLs", then edit the ACL and click "Cancel", it still reads "Access control lists updated.", even though the changes were canceled. This is due to the "Cancel" button causing the browser to navigate backwards, and a javascript popup. --BarkerJr


Revision [6797]

Edited on 2005-03-20 16:58:02 by JavaWoman [purging pages possible enhancement]
Additions:
===Alzheimers for Wikka?===
~&Instead of removing or modifying it (the configuration parameter, rather) we could refine it by introducing an extra parameter name something like "pages_keep" to set a maximum number of pages to be kept regardless (maximum, since it could be less if there are not that many versions in the first place). Setting one or the other to 0 could disable purging altogether. --JavaWoman
Deletions:
===Alzeimers for Wikka?===


Revision [6794]

Edited on 2005-03-20 14:54:27 by IanAndolina [question on page purging]
Additions:
===Alzeimers for Wikka?===
This is not a bug specifically - it is really a potential implentation weakness, but if a user specifies a page purge time in wikka.config: "pages_purge_time" => "100" and if that page is not edited for a while, then when that page is edited, the last copy will be deleted, leaving no archived copies at all. I think purge pages should delete old pages, but there should always be a minimum number of old copies preserved, otherwise the wiki becomes highly vulnerable to a content deletion attack. Would it be better to remove this feature, or modify it? --IanAndolina


Revision [6780]

Edited on 2005-03-19 07:22:55 by JavaWoman [installer bug]
Additions:
===Admin email at installation===
//reported in IRC while I was asleep, sorry - JW does have to sleep sometimes//
(Potential) User extremely frustrated when at installation he's entering a real and valid email address and the Installer rejects it with "Email appears incorrect". This is caused by the extremely brain-dead Javascript in the installer that accepts **nothing but lowercase letters** to appear before the '@'. To be anywhere like realistic it should be corrected to accept numbers, dots, hyphens and underscores as well.
--JavaWoman //(hoping the reporter shows up again so I can help him with a workaround)//


Revision [6652]

Edited on 2005-03-10 22:34:10 by YanB [emailpwd pbl persists]
Additions:
~~~~~~~~~&Negative... Tried with 2 different emails again, still nothing. (If only this was a joke.) --YanB


Revision [6639]

Edited on 2005-03-10 01:15:55 by JsnX [wee, email password fun]
Additions:
~~~~~~~~&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
Deletions:
OK, here's the fix:
Change these lines in **actions/emailpassword.php**:
$email = $this->Format($user['email']);
$md5pass = $this->Format($user['password']);
To:
$email = $user['email'];
$md5pass = $user['password'];
I'm puzzled why Costal felt it necessary to put the email address and password through Format(). *shrug* -- JsnX
~&I'm puzzled how this could even make a difference? Especially on the password, since if it made a difference you wouldn't be able to log in anyway. If you can, it can't be different and it can't be a fix. --JavaWoman


Revision [6638]

Edited on 2005-03-09 22:24:48 by JavaWoman [reaction email password "fix"]
Additions:
~&I'm puzzled how this could even make a difference? Especially on the password, since if it made a difference you wouldn't be able to log in anyway. If you can, it can't be different and it can't be a fix. --JavaWoman


Revision [6637]

Edited on 2005-03-09 20:08:59 by YanB [fix or fix? emailpwd bug strikes again]
Additions:
~~~~~~~&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


Revision [6636]

Edited on 2005-03-09 18:26:17 by JsnX [fix for email password action]
Additions:
OK, here's the fix:
Change these lines in **actions/emailpassword.php**:
$email = $this->Format($user['email']);
$md5pass = $this->Format($user['password']);
To:
$email = $user['email'];
$md5pass = $user['password'];
I'm puzzled why Costal felt it necessary to put the email address and password through Format(). *shrug* -- JsnX


Revision [6634]

Edited on 2005-03-09 15:28:05 by DarTar [Reply to JsnX - got the email]
Additions:
~~~~~~& JsnX, yep, I just received both -- DarTar


Revision [6633]

Edited on 2005-03-09 13:46:28 by JsnX [DarTar, re: forgotten password]
Additions:
~~~~~&DarTar, I just fiddled with the action and had it send emails to the DarTar and DarTar2 email addresses. Did the emails arrive? -- JsnX


Revision [6605]

Edited on 2005-03-08 16:27:41 by JavaWoman [reaction re: forgotten password mails]
Additions:
~~~~&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


Revision [6590]

Edited on 2005-03-08 09:18:11 by DarTar [Confirming password retrieval problem]
Additions:
~~~& 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 {{wikkaversion}}? 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


Revision [6580]

Edited on 2005-03-08 00:26:03 by YanB [reply to jsnx, confirming mental illness]
Additions:
~~&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


Revision [6579]

Edited on 2005-03-08 00:13:10 by JsnX [reply to YanB, modifed to inline comment]
Additions:
~&You are crazy. I just tested it... and it worked. *shrug* Does your email server do some sort of spam filtering?? -- JsnX
Deletions:
You are crazy. I just tested it... and it worked. *shrug* Does your email server do some sort of spam filtering?? -- JsnX


Revision [6578]

Edited on 2005-03-08 00:12:08 by JsnX [reply to YanB]
Additions:
You are crazy. I just tested it... and it worked. *shrug* Does your email server do some sort of spam filtering?? -- JsnX


Revision [6577]

Edited on 2005-03-07 22:28:40 by YanB [reply to YanB]
Additions:
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
Deletions:
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? --YanB


Revision [6576]

Edited on 2005-03-07 22:27:49 by YanB [reply to YanB]
Additions:
===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? --YanB


Revision [6418]

Edited on 2005-03-01 22:18:34 by JavaWoman [replies re GeSHi bugs (not Wikka bugs!)]
Additions:
~&Sounds also like a GeSHi problem rather than a Wikka bug. If anyone is installing (or has installed) GeSHi 1.0.6 I'd appreciate feedback on whether this cosmetic problem is solved as well. --JavaWoman
~&This is actually not a Wikka bug, but a problem in GeSHi itself - which only appears in rare cases. See CharsetNotSupportedWorkaround for more information. I think the latest GeSHi version (1.0.6) has addressed this problem. If you'd like to try this, make sure you remove the workaround code in Wikka when installing the new GeSHi version. --JavaWoman


Revision [6409]

Edited on 2005-03-01 15:16:45 by FreekDijkstra [Forgot to add my name (again)]
Deletions:


Revision [6408]

Edited on 2005-03-01 15:15:03 by FreekDijkstra [Added bug in GeSHi: comments in PHP]
Additions:
===Comments in formatted PHP code===
GeSHi has a habit of adding a trailing line if the PHP code contains a comment using ""//"" or ""#"".
For example %%(php) echo "hello world"; // How do you do?%% This does not happen if ""/* */"" is used for comments. For example %%(php) echo "hello world"; /* How do you do? */%%


Revision [6406]

Edited on 2005-03-01 12:41:52 by FreekDijkstra [Added bug in GeSHi: comments in PHP]
Additions:
-- FreekDijkstra


Revision [6405]

Edited on 2005-03-01 12:01:41 by FreekDijkstra [new bug: encoding of GeSHi]
Additions:
===Encoding of GeSHi===
My default installation of Wikka 1.1.6.0 did display the error
htmlentities(): charset `646' not supported, assuming iso-8859-1 in /home/www/WWW/files/research/air/wiki/3rdparty/plugins/geshi/geshi.php
on the FormattingRules page. I was able to fix this by adding the "set_encoding" line in the GeSHi_Highlight() function in wikka.php:
$geshi =& new GeSHi($sourcecode, $language, $this->config['geshi_languages_path']); # existing code
$geshi->set_encoding('UTF-8'); # set encoding (new line)%%


Revision [6355]

Edited on 2005-02-27 14:28:54 by YanB [new bug: encoding of GeSHi]
Additions:
~&Same problem. Is it possible to include in wikka.config.php a line in which you specify the default cookie prefix? I guess this could solve the problem. --YanB


Revision [6325]

Edited on 2005-02-25 16:43:28 by DarTar [User name matching bug]
Additions:
===User name matching===
(related to the //Category name matching// item below)
While [[RegisterActionTest testing]] the beta RegisterAction, I realized that using a username like **""DarTartar""** results in a //"Sorry, username already exists"// error. Looks like a problem in the RE used by the ##""LoadUser()""## function. I'll take a look at it ASAP.


Revision [6285]

Edited on 2005-02-24 09:55:18 by JeroenJansen [multiple wikka's security hole?]
Additions:
===Multiple wikka installations on one host: Login security hole?===
Okay. Say that I've installed multiple seperate installations of wikka on one host. If I do a login on wikka A, I can also
reach the pages of wikka B, whereas wikka B has an authentication table where the user account of wikka A does not exist!
My guess is that this behaviour occurs because the login cookies are set with path root. And as long the login cookies exist
Wikka doesn't care about authentication anymore??
-- JeroenJansen


Revision [6267]

Edited on 2005-02-23 14:12:34 by PolVazo [Advanced search results reveal confidential info]
Additions:
===Bug in Textsearch (expanded)===
As DotMG has pointed out, the input for this two actions isn't validated, making it a security-hole.
**Advanced search results reveal confidential info**
Results should be hidden or not shown if the user doesn't have read access to page IMHO. --PolVazo
Deletions:
===Bug in Textsearch(expanded)===
As DotMG has pointed out, the inoput for this two actions isn't validated, making it a security-hole.


Revision [6252]

Edited on 2005-02-22 19:59:12 by TammyCravit [Advanced search results reveal confidential info]
Additions:
===Category name matching===
Yes, I know the category system needs to be revamped, but I figured I'd report this anyway. If you have a category name that is a substring of another category name, pages referencing the second category will also appear in the first. In other words...I have a category named '""CategoryBookOne"", and another named ""CategoryBookOneJournal"". Pages that reference ""CategoryBookOneJournal"" also show up in the list of pages for ""CategoryBookOne"", which is not the behavior I expected or wanted.
-- TammyCravit


Revision [6228]

Edited on 2005-02-21 18:42:38 by JavaWoman [adding installer problems]
Additions:
===Installer problems===
Gathered from error reports in different places (including comments on WikkaInstallation, #wikka and IM) - neither new, but worth repeating and putting together, I think:
~-In at least some cases the "detected" base path misses a closing slash (resulting in links that don't work); the installer should check if the derived path has a final slash, and if not, add one, before presenting that to the user.
~-If PHP (and thus Wikka) cannot connect to MySQL the installer just "hangs" after the first screen and printing "Testing configuration"; this seems to be (at least partly) the result of having error messages from the MySQL statements suppressed with a @, which would be OK if the error message were handled afterwards - but this doesn't happen. Other mysql_xxx() calls in the installer also have the @ suppressing error messages. That should either be removed, or all error messages should be picked up and handled by the installer, at the very least by showing the message to the user. ---
~This is especially a problem for users new at MySQL or new even at PHP+MySQL for whom it won't be obvious where to start troubleshooting when the installer simply hangs.


Revision [6217]

Edited on 2005-02-21 07:00:04 by JavaWoman [adding sig and reply]
Additions:
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
Deletions:
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.


Revision [6212]

Edited on 2005-02-20 22:54:20 by BrendonB [adding sig and reply]
Additions:
===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.


Revision [6183]

Edited on 2005-02-20 03:37:15 by ChWatson [cew]
Additions:
===mod_rewrite issue===
When in edit mode using IIS if you click the help button the program doesn't take you to the FormattingRules page, but tries to go to the ""FormattingRules"" Directory, which does not exist.


Revision [6087]

Edited on 2005-02-17 14:09:21 by NilsLindenberg [fix for textsearch(expanded)]
Additions:
===Bug in Textsearch(expanded)===
As DotMG has pointed out, the inoput for this two actions isn't validated, making it a security-hole.
You can fix it by changing the line
$phrase = stripslashes($phrase);
into
$phrase = preg_quote($this->htmlspecialchars_ent(stripslashes($phrase)), "/");
You have to change both files (textsearch and textsearchexpanded). --NilsLindenberg


Revision [6082]

Edited on 2005-02-17 14:00:23 by NilsLindenberg [small correction on double-click-edit fix]
Additions:
<div class="page" <?php echo ((!$user || ($user["doubleclickedit"] == 'Y')) && $this->GetMethod
() == "show") ? "ondblclick=\"document.location='".$this->href("edit")."';\" " : "" ?>>
Deletions:
<div class="page" <?php echo ((!$user || ($user["doubleclickedit"] == 'Y')) && ($this->GetMethod
() == "show")) ? "ondblclick=\"document.location='".$this->href("edit")."';\" " : "" ?>>


Revision [6081]

Edited on 2005-02-17 13:56:29 by NilsLindenberg [fix for doubleclick-edit bug]
Additions:
~~&Heres the fix:
~~&add as **first** line in handlers/page/show.php:
~~&%%(php)
<?php $user = $this->GetUser(); ?>
~~&and change the second line to:
~~&%%(php)
<div class="page" <?php echo ((!$user || ($user["doubleclickedit"] == 'Y')) && ($this->GetMethod
() == "show")) ? "ondblclick=\"document.location='".$this->href("edit")."';\" " : "" ?>>
~~&--NilsLindenberg
Deletions:
~~&I think the bug is in the first line of handlers/page/show.php:
~~&%%(php) (!$user || ($user["doubleclickedit"] == 'Y')) && ($this->GetMethod() == "show")%%
~~&is used to make the distinction. but $user isn't defined and therefore has no value. So !$user is always true. We could replace the first expresion with !$this_>GetUser, but which function reads the usersettings from the table? (needed for the second part). --NilsLindenberg


Revision [6059]

Edited on 2005-02-16 22:09:37 by JavaWoman [reply re: Opera and layer (not a bug)]
Additions:
~&A "layer" is nothing but a div; Wikka's "float" boxes are floated divs. When a floated block is longer (vertically) than the section it precedes, it will (vertically) overlap with the next section. This is just standard CSS (the effect isn't limited to Opera either). To prevert this overlap happening at the end of a page (or section), add ""::c::"" at the end of the page (or section), which will create an empty div a with clear: both style. **Not a bug** - just standard CSS for which Wikka markup provides an appropriate mechanism. --JavaWoman


Revision [6017]

Edited on 2005-02-16 06:32:46 by DotMG [Suggesting preg_quote for NilsLindenberg's bug found on TextSearchExpanded]
Additions:
~&Php has a function : preg_quote that may help us. Or try this solution : DotMGTextSearchExpanded


Revision [6004]

Edited on 2005-02-15 14:05:09 by JsnX [Recent[ly]Comment[ed|s] actions should check for permission]
Additions:
===Recent[ly]Comment[ed|s] actions should check for permission===
Comments are being previewed even if users do not have access. A simple check needs to be added. -- JsnX
if ($this->HasAccess("comment"))


Revision [5977]

Edited on 2005-02-15 04:31:51 by BarkerJr [MySQL 5 Confusion]
Additions:
~~&I'm running MySQL 5 fine with the mysql_* functions. When you compile PHP, it's your choice to compile the mysql_* or mysqli_* functions. I chose to compile it with mysql_*, which is working fine for me. --BarkerJr


Revision [5919]

Edited on 2005-02-11 18:03:18 by JavaWoman ['tags in the edit-notes' moved here from SuggestionBox]
Additions:
===tags in the edit-notes===
I made a edit note: "removed a <?php (to much)" and got "removed a". Perhaps replacing <> would be the better option? --NilsLindenberg
~&Funny - I just stumbled over the same problem - only in the RecentChanges newsfeed: the <?php causes imbalanced tags there, and thus a syntax error: until that post has "aged" off of the feed, it can't be loaded any more! The [[http://feedvalidator.org/check?url=http%3a%2f%2fwikka.jsnx.com%2fRecentChanges%2frecentchanges.xml validation result]] clearly shows what the problem is. So yes, edit notes should be fed threough htmlspecialchars[_ent]() everywhere they're presented, and that includes the RSS feed! --JavaWoman
~~&And the WikiPing, too :) --NilsLindenberg
~&Oh is **that** what you removed Nils. I couldn't figure out using history what you did. Where did you take it from? And why? Did I have one more <?php than was necessary? In which code block? --GmBowen
~~&It was at the beginning of mail.php: %%(php) <?php <?php%%. I guess you overlooked it when you copied your new version to the page. Happent to me in another case, too. --NilsLindenberg


Revision [5820]

Edited on 2005-02-09 07:06:02 by IamBack [new category action clarification]
Additions:
~&Include pulls in a page that itself has the category action on it; the "official" version of this action assumes that the page it occurs on **is** a category. The "//experimental//" category action that is now active on this site no longer makes this assumption but recognizes that SandBox isn't a category page and defaults to the top category. See Sandbox for a an example (at this moment). --JavaWoman
~~~&Oops, sorry (corrected now) - I meant the new category action sees whether the page it's "sitting" on is a category page or not - if not it defaults to showing the list for the top-level category. --JavaWoman (aka IamBack)
Deletions:
~&Include pulls in a page that itself has the category action on it; the "official" version of this action assumes that the page it occurs on **is** a category. The "//experimental//" category action that is now active on this site no longer makes this assumption but recognizes that SandBox isn't an action and defaults to the top category. See Sandbox for a an example (at this moment). --JavaWoman


Revision [5814]

Edited on 2005-02-08 19:22:50 by GmBowen [new category action clarification]
Additions:
~~&I can see that it now works, but what do you mean that it "recognizes that Sandbox isn't an action".....do you mean target page? --GmBowen


Revision [5812]

Edited on 2005-02-08 16:59:56 by JavaWoman [new reply to GmBowen about include + category action: problem solved in experimental version]
Additions:
~&Include pulls in a page that itself has the category action on it; the "official" version of this action assumes that the page it occurs on **is** a category. The "//experimental//" category action that is now active on this site no longer makes this assumption but recognizes that SandBox isn't an action and defaults to the top category. See Sandbox for a an example (at this moment). --JavaWoman


Revision [5808]

Edited on 2005-02-08 15:41:13 by NilsLindenberg [reply to bug:double-click editing]
Additions:
=====Bugs/Issues discovered in Wikka!=====
{{lastedit show="3"}}
<<**Related pages**:
-for resolved bugs/issues see: WikkaBugsResolved
-workarounds for unusual problems and temporary fixes for known bugs listed at WikkaWorkarounds
-for issues related to Wikka layout refer to: WikkaCSS
-for feature suggestions rather than bugs, go to the SuggestionBox
-looking for help? check the [[WikkaDocumentation Wikka Documentation]]
<<>>==Attention:==
For problems with **foreach** in PHP version **4.3.10**:---See WikkaBugsResolved>>::c::
**Please post recently discovered bugs on the //top// of this page (just below this note).**---
::c::


===Opera and layer===
(copied from the sandbox --NilsLindenberg)
Opera browser doesn't like a right layer a the end of a page :(

----
===Missing language-support in the code formatter===
(copied from the sandbox --NilsLindenberg)

not support 2byte language in the Code formatters!!!!
%%(c)
// 한글이 깨지겠지
// 진짜 깨지네.. 흑흑.. 에디터창에서 깨지는 것도 열받는데..
...
%%

----
===Error on ./handlers/page/referrers_sites===
Line 46 :
- Code generates a double </a> for links.
- & in URL should be replaced by &amp;
=> %%(php) print("<td valign=\"top\">" . (($site != "unknown") ? "<a href=\"http://".$this->htmlspecialchars_ent($site)."\">".$this->htmlspecialchars_ent($site)."</a>" : $site) . /*"</a> ".*/($IsAdmin ? "[<a href=\"".$this->href("delete_referrer", "", "spam_site=").$this->htmlspecialchars_ent($site)."&redirect=".$this->GetMethod()."\">Blacklist</a>]" : "")."</td>");%%
Note: You cannot see this error by validating directly a page because W3C is not registered and it will not have the same output as you, in other words, code on line 46 won't be executed. But you can save the page on your hard disk and validate it.
--DotMG

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

----
===Accept-Encoding: gzip;q=0, deflate===
**Not really bug, but should be corrected for respect & compliance to RFC2616**
If a browser sends the header
Accept-Encoding: gzip;q=0, deflate
Which should be interpreted as : "I don't support gzip encoding, but I prefer deflate", Wikka will understand "The browser supports gzip-encoding", as it just searches for the text gzip in $_SERVER['HTTP_ACCEPT_ENCODING']. An example I use to treat it correctly is :
%%(php) function ParseHeaderLine($hl, $token=null)
{
$ar_hl = explode(',', $hl);
foreach ($ar_hl as $dotmg_idx => $val)
{
if (preg_match('/^\s*(.*?);\s*q\s*=\s*([0-9\.]*)/i', $val, $match))
{
$res[strtolower($match[1])] = doubleval($match[2]);
}
else
{
$res[strtolower($val)] = 1;
}
}
if ($token) return(isset($res[$token]) && ($res[$token] > 0)); #if $token is set, we return true or false
return ($res); # else we return the header parsed.
}%%
and
%%(php) if ($this->ParseHeaderLine($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ...%%
Note : This function might be useful to deal also with Accept-Language, when Wikka will be made effectively multilingual.
--DotMG

----
===1.1.6.0beta4: Simplified Chinese (or Unicode relative) in WikiEdit:===
A page contains unicode characters looks OK when viewed but displays ""''&#*****;''"" while edited in WikiEdit
Simplified Chinese Test:
中文是一种美丽的语言,除了具有音节上的美感,同样拥有视觉上的美感
In 1.1.5.3, I solved this problem by changed some line in ./handlers/page/edit.php
%%(php)
#from
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$body."</textarea><br />\n"
#to
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$this->htmlspecialchars_ent($body)."</textarea><br />\n"
%%
Wikka is wonderful! ZhuangYuyao
~&This workaround you outlined will work as well in Wikka 1.1.6.0. A real solution wil take some more investigation though, so we were unable to fix this for the current release. This is now under investigation. --JavaWoman

----
===Double-click editing===
I noticed: Turning off DoubleClick-editing does not work (double-clicks still go to edit-window) in IE 6.0 or Firefox 1.0.
Keep up the good work!
Cheers, MarkHissinkMuller
~&Yes, I noticed the same thing. This is a bug as of 1.1.6.0. --RyanKnoll
~~&I think the bug is in the first line of handlers/page/show.php:
~~&%%(php) (!$user || ($user["doubleclickedit"] == 'Y')) && ($this->GetMethod() == "show")%%
~~&is used to make the distinction. but $user isn't defined and therefore has no value. So !$user is always true. We could replace the first expresion with !$this_>GetUser, but which function reads the usersettings from the table? (needed for the second part). --NilsLindenberg

----
===$_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)
<?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
----
===PageIndex problem===
DarTar and I have recently created some test pages, testing page names related to how Wikka evaluates 'valid' page names: ,My,Page and ÄhnLich (yes, they both exist, even if they don't show up as such in this sentence!). Now look at where they show up on PageIndex... surely there shouldn't be **two** '#' indices??
--JavaWoman
~&I think that this is due to the encoding of the MySQL tables. I can't see how that would be fixed with a small touch on the code. If this is the matter then I hope that it also rings the i18n bell too. //Translation to Greek is my bussiness ;)//
~&""--""GeorgePetsagourakis
~~&Yes, my i18n bells were already loudly ringing... but you bring up a good point with MySQL. I hadn't thought about a real cause yet, just wanted to record what I saw before I got distracted again ;-). Sort order is a whole subject of its own within i18n .... --JavaWoman
----
===Install Note on Basic URL and CSS===
First, this may applied to my ISP only. When I installed, I have to use
the ?wakka= options. However, I have to add a / to the end of the
default Basic URL before append ?wakka= to it. So I think it maybe
helpful to modify the instruction to '... so it should include
the "/?wakka=" parameter...'
~&ArpY: Maybe this is caused by a config error. Please have a look at your config - is there a slash at the end of the base_url?

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

----
===Weirdness with Include===
Um, I don't know how to describe this really. Put ""{{include page="CategoryDocumentation"}}"" on the SandBox page....I can't figure out why it gives that output as Sandbox doesn't own anything.
~&''Looks like the weirdness is caused by the ""{{Category}}"" action which assumes the "current page" represents the category - and find pages "belonging to" a category by finding a mention of that page name. Good sign our category system does need an [[CategorySystemOverhaul overhaul]]! --JavaWoman''

----
===Backlinks / ""LoadPagesLinkingTo()""===
I just discovered that the ##""{{backlinks}}""## action may list pages that don't "exist" any more, in the sense that they (apparently) still are in the database but without any active version (seemingly as a result of a rename action. I added an example on [[JavaWoman my own page]] where you can see a supposed backlink from ReleaseNotes (which was replaced by WikkaReleaseNotes).

~&The cause is apparently in the ""LoadPagesLinkingTo()"" method which is used by ##""{{backlinks}}""## action. It currently is implemented like this:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' order by tag"); }
%% I think replacing this by:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' and latest = 'Y' order by tag"); }
%% might do the trick to avoid deceased pages - but please test!
~&--JavaWoman

----
====GetEnv is not a good idea!====
At ./wikka.php, you will see a line %%(php)<?php if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";?>%%
In the most cases, a website is hosted in a machine as a VirtualHost, this means that a number of websites share the same environment variables. If someone knows where your site is hosted, he can put his site at the same server, and use a script containing %%(php)<?php putenv('WAKKA_CONFIG=/home/hacker/config.php');?>%%. And all wikka sites on the same server will use his configuration file. The rest actions to take to hack your site will be as easy as eating sandwich.
Php doc says that an environment variable is altered only during the life of the script, but with my dev Easyphp's on windows, that is false. (I think a "new" environment variable keep its value, even on Linux).

I wanted to make a unique Wikka interface used by 3 sites on the same server. The best secure solution I found is to alter ./wikka.php like this :
%%(php)<?php
if (file_exists("wakka.config.php")) rename("wakka.config.php", "wikka.config.php");
#if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";
if (!$configfile && isset($GLOBALS['wikka_config'])) $configfile = $GLOBALS['wikka_config'];
if (!$configfile) $configfile = "wikka.config.php";
if (file_exists($configfile)) include($configfile);
%%
and put the 2 files sitenumber2.php and .htaccess below at the root of the server number 2:
__sitenumber2.php:__
%%(php)<?php
$GLOBALS['wikka_config'] = "/path/to/altered_config.php";
chdir("/path/to/basewikka");
include('wikka.php');
?>%%
__.htaccess:__
%%<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.*/[^\./]*[^/])$ $1/
RewriteRule ^(css|images|wikiedit2)/(.*)$ /path/to/basewikka/$1/$2 [L]
RewriteRule ^(.*)$ sitenumber2.php?wakka=$1 [QSA,L]
</IfModule>%%

--DotMG

~&''I've now written up my thoughts about a [[WikkaSecureConfig more secure way to handle Wikka's configuration]] (which should also provide also more flexibility). --JavaWoman''

----
===Expanded Text Search fails===
I tried an expanded Text-Search after [[http://wikka.jsnx.com/TextSearchExpanded?phrase=%2Bparameter+%2Blink +parameter +link]] and got the following error:

''Warning: Compilation failed: nothing to repeat at offset 1 in /.../actions/textsearchexpanded.php on line 33''

for every page.
--NilsLindenberg
~&''In my recent RE exploits I have found that a warning of this type comes up when a regular expression isn't quite correct (though not every attempt to match may bring up teh warning); haven't investigated further in textsearchexpanded.php though. --JavaWoman''

-----
=== Yet more formatter bugs ===
Looking at **formatters/wikka.php** to find the cause of the two bugs listed below (found one), I notice to my horror that a **lot** of the regular expressions used there are actually incorrect. They allow such things as using a comma to indent a line (in addition to a tab, or ~, at the start of a line: **demo** in the SandBox, and in the list **below**!), or a comma in a WikiName (even at the start) or in an InterWiki link. That can't have been the intention - it's simply a matter of incorrect RE syntax. I'd become sort of "sensitized" to this phenomenon looking at DarTar's RE on ValidPageNames earlier today - now I see where he found an example (see my comment on that page on his RE!).
,''Note: see also [[,My,Page]] - yup, that's a real page now. ;-)''

~&Rather than simply fixing all the REs (and other REs all over the place...) I'd like to propose a more fundamental solution:
~&-create a "library" of RE building blocks to be used in the Wikka core (for an example of what I mean with building blocks see my propopsal for an alternative RE on ValidPageNames); simply create a separate file with define()s for these building blocks, and include them at the start of the main wikka.php file;
~&-gather all RE used in the Wikka core here (extensions/plugins could have their own set of defines - as long as they don't have conflicting names);
~&-now use **only** these building blocks when using REs anywhere in the Wikka core.
~&This should make it much easier to create both //correct//, and //consistent// regular expressions; any (near)duplicates will be much easier to discover, and fix.
~&
~&Probably best to leave this to just **after** the coming release, so we have a stable code base again. I volunteer to undertake this work. (Unlike some people, I happen to like REs.) :)
~&--JavaWoman

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

~&Possible clue:
~&I just stumbled over the fact that the little list of "Useful pages" at the end of the default (installation-generated) ""HomePage"" had incorrect coding: The last list item (li) was not terminated, nor was the list itself (no closing ul tag). It took me a bit of trial and error to reproduce this - but have a look at my test code at the end of SandBox (now). Originally I thought that any list at the end of a page would be unterminated, but that turned out not to be the case. Then I hit on something else: the last list element on that default ""HomePage"" (not the one here) ands with a period. My test version on SandBox now also has the last element ending in a period ... and if you look at the (HTML) page source, you'll see it is indeed an unterminated list. Somehow that ending period (maybe in combination with end-of-page?) causes the Formatter never to close the list; take that ending period away, and it works normally. I tried a few variants, to check whether it might be an odd-even problem, but no: whether the number of list items is odd or even, if the last one ends in a period, the list isn't terminated.
~&
~&No difference whether it's anordered (ol) or unordered (ul) list, the formatter behaves the same way.
~&
~&And, BTW, if you look at the preview when editing, the HTML source of the **preview** actually contains a lot of Wiki code that shouldn't be there!
~&
~&I haven't dug in the Formatter yet to find the cause or whether end-of-page makes a difference...
~&--JavaWoman

----
=== 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.
--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 "**dan**gerous" - 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

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

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

----
Bugs I've found:
- Security: I was wondering whether it would be possible to store IPs for registered users as well. That way you can ban them via .htaccess if necessary.
- ''Last known IP or every IP they ever connect from? I'd be willing to store one last known IP per user. '' - JsnX
- ''Last known IP please :) Thanks.'' - Sam
- ''I'd suggest adding *two* distinct fields to ##wikka_users##: Last Login IP/Hostname + Last Login Time'' - DarTar
- ''I was also thinking of a way to ban users directly from the wiki (much in the same way as referrers are added to the blacklist of spammers). This might turn out easier to implement than a //user deleting action// (which was one of the ideas discussed [[UserAdmin here]])'' - DarTar


- Security: Single-click restore of previous versions (without copying/pasting).
- ''Yes, this will be implemented at some point.'' - JsnX
- I should point out that there is an alternative to copying/pasting.
- Go to the revisions page.
- Click the date and time link that you would like to revert back to.
- Click the 'Re-edit this old revision' button.
- Click the 'Store' button.

Thanks - Sam
----
- Mod_rewrite : take a look at FaviconDotIco and RobotsDotTxt

::c::
----
Deletions:
=====Bugs/Issues discovered in Wikka!=====
{{lastedit show="3"}}
<<**Related pages**:
-for resolved bugs/issues see: WikkaBugsResolved
-workarounds for unusual problems and temporary fixes for known bugs listed at WikkaWorkarounds
-for issues related to Wikka layout refer to: WikkaCSS
-for feature suggestions rather than bugs, go to the SuggestionBox
-looking for help? check the [[WikkaDocumentation Wikka Documentation]]
<<>>==Attention:==
For problems with **foreach** in PHP version **4.3.10**:---See WikkaBugsResolved>>::c::
**Please post recently discovered bugs on the //top// of this page (just below this note).**---
::c::


===Opera and layer===
(copied from the sandbox --NilsLindenberg)
Opera browser doesn't like a right layer a the end of a page :(

----
===Missing language-support in the code formatter===
(copied from the sandbox --NilsLindenberg)

not support 2byte language in the Code formatters!!!!
%%(c)
// 한글이 깨지겠지
// 진짜 깨지네.. 흑흑.. 에디터창에서 깨지는 것도 열받는데..
...
%%

----
===Error on ./handlers/page/referrers_sites===
Line 46 :
- Code generates a double </a> for links.
- & in URL should be replaced by &amp;
=> %%(php) print("<td valign=\"top\">" . (($site != "unknown") ? "<a href=\"http://".$this->htmlspecialchars_ent($site)."\">".$this->htmlspecialchars_ent($site)."</a>" : $site) . /*"</a> ".*/($IsAdmin ? "[<a href=\"".$this->href("delete_referrer", "", "spam_site=").$this->htmlspecialchars_ent($site)."&redirect=".$this->GetMethod()."\">Blacklist</a>]" : "")."</td>");%%
Note: You cannot see this error by validating directly a page because W3C is not registered and it will not have the same output as you, in other words, code on line 46 won't be executed. But you can save the page on your hard disk and validate it.
--DotMG

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

----
===Accept-Encoding: gzip;q=0, deflate===
**Not really bug, but should be corrected for respect & compliance to RFC2616**
If a browser sends the header
Accept-Encoding: gzip;q=0, deflate
Which should be interpreted as : "I don't support gzip encoding, but I prefer deflate", Wikka will understand "The browser supports gzip-encoding", as it just searches for the text gzip in $_SERVER['HTTP_ACCEPT_ENCODING']. An example I use to treat it correctly is :
%%(php) function ParseHeaderLine($hl, $token=null)
{
$ar_hl = explode(',', $hl);
foreach ($ar_hl as $dotmg_idx => $val)
{
if (preg_match('/^\s*(.*?);\s*q\s*=\s*([0-9\.]*)/i', $val, $match))
{
$res[strtolower($match[1])] = doubleval($match[2]);
}
else
{
$res[strtolower($val)] = 1;
}
}
if ($token) return(isset($res[$token]) && ($res[$token] > 0)); #if $token is set, we return true or false
return ($res); # else we return the header parsed.
}%%
and
%%(php) if ($this->ParseHeaderLine($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ...%%
Note : This function might be useful to deal also with Accept-Language, when Wikka will be made effectively multilingual.
--DotMG

----
===1.1.6.0beta4: Simplified Chinese (or Unicode relative) in WikiEdit:===
A page contains unicode characters looks OK when viewed but displays ""''&#*****;''"" while edited in WikiEdit
Simplified Chinese Test:
中文是一种美丽的语言,除了具有音节上的美感,同样拥有视觉上的美感
In 1.1.5.3, I solved this problem by changed some line in ./handlers/page/edit.php
%%(php)
#from
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$body."</textarea><br />\n"
#to
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$this->htmlspecialchars_ent($body)."</textarea><br />\n"
%%
Wikka is wonderful! ZhuangYuyao
~&This workaround you outlined will work as well in Wikka 1.1.6.0. A real solution wil take some more investigation though, so we were unable to fix this for the current release. This is now under investigation. --JavaWoman

----
===Double-click editing===
I noticed: Turning off DoubleClick-editing does not work (double-clicks still go to edit-window) in IE 6.0 or Firefox 1.0.
Keep up the good work!
Cheers, MarkHissinkMuller
~Yes, I noticed the same thing. This is a bug as of 1.1.6.0. --RyanKnoll

----
===$_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)
<?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
----
===PageIndex problem===
DarTar and I have recently created some test pages, testing page names related to how Wikka evaluates 'valid' page names: ,My,Page and ÄhnLich (yes, they both exist, even if they don't show up as such in this sentence!). Now look at where they show up on PageIndex... surely there shouldn't be **two** '#' indices??
--JavaWoman
~&I think that this is due to the encoding of the MySQL tables. I can't see how that would be fixed with a small touch on the code. If this is the matter then I hope that it also rings the i18n bell too. //Translation to Greek is my bussiness ;)//
~&""--""GeorgePetsagourakis
~~&Yes, my i18n bells were already loudly ringing... but you bring up a good point with MySQL. I hadn't thought about a real cause yet, just wanted to record what I saw before I got distracted again ;-). Sort order is a whole subject of its own within i18n .... --JavaWoman
----
===Install Note on Basic URL and CSS===
First, this may applied to my ISP only. When I installed, I have to use
the ?wakka= options. However, I have to add a / to the end of the
default Basic URL before append ?wakka= to it. So I think it maybe
helpful to modify the instruction to '... so it should include
the "/?wakka=" parameter...'
~&ArpY: Maybe this is caused by a config error. Please have a look at your config - is there a slash at the end of the base_url?

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

----
===Weirdness with Include===
Um, I don't know how to describe this really. Put ""{{include page="CategoryDocumentation"}}"" on the SandBox page....I can't figure out why it gives that output as Sandbox doesn't own anything.
~&''Looks like the weirdness is caused by the ""{{Category}}"" action which assumes the "current page" represents the category - and find pages "belonging to" a category by finding a mention of that page name. Good sign our category system does need an [[CategorySystemOverhaul overhaul]]! --JavaWoman''

----
===Backlinks / ""LoadPagesLinkingTo()""===
I just discovered that the ##""{{backlinks}}""## action may list pages that don't "exist" any more, in the sense that they (apparently) still are in the database but without any active version (seemingly as a result of a rename action. I added an example on [[JavaWoman my own page]] where you can see a supposed backlink from ReleaseNotes (which was replaced by WikkaReleaseNotes).

~&The cause is apparently in the ""LoadPagesLinkingTo()"" method which is used by ##""{{backlinks}}""## action. It currently is implemented like this:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' order by tag"); }
%% I think replacing this by:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' and latest = 'Y' order by tag"); }
%% might do the trick to avoid deceased pages - but please test!
~&--JavaWoman

----
====GetEnv is not a good idea!====
At ./wikka.php, you will see a line %%(php)<?php if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";?>%%
In the most cases, a website is hosted in a machine as a VirtualHost, this means that a number of websites share the same environment variables. If someone knows where your site is hosted, he can put his site at the same server, and use a script containing %%(php)<?php putenv('WAKKA_CONFIG=/home/hacker/config.php');?>%%. And all wikka sites on the same server will use his configuration file. The rest actions to take to hack your site will be as easy as eating sandwich.
Php doc says that an environment variable is altered only during the life of the script, but with my dev Easyphp's on windows, that is false. (I think a "new" environment variable keep its value, even on Linux).

I wanted to make a unique Wikka interface used by 3 sites on the same server. The best secure solution I found is to alter ./wikka.php like this :
%%(php)<?php
if (file_exists("wakka.config.php")) rename("wakka.config.php", "wikka.config.php");
#if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";
if (!$configfile && isset($GLOBALS['wikka_config'])) $configfile = $GLOBALS['wikka_config'];
if (!$configfile) $configfile = "wikka.config.php";
if (file_exists($configfile)) include($configfile);
%%
and put the 2 files sitenumber2.php and .htaccess below at the root of the server number 2:
__sitenumber2.php:__
%%(php)<?php
$GLOBALS['wikka_config'] = "/path/to/altered_config.php";
chdir("/path/to/basewikka");
include('wikka.php');
?>%%
__.htaccess:__
%%<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.*/[^\./]*[^/])$ $1/
RewriteRule ^(css|images|wikiedit2)/(.*)$ /path/to/basewikka/$1/$2 [L]
RewriteRule ^(.*)$ sitenumber2.php?wakka=$1 [QSA,L]
</IfModule>%%

--DotMG

~&''I've now written up my thoughts about a [[WikkaSecureConfig more secure way to handle Wikka's configuration]] (which should also provide also more flexibility). --JavaWoman''

----
===Expanded Text Search fails===
I tried an expanded Text-Search after [[http://wikka.jsnx.com/TextSearchExpanded?phrase=%2Bparameter+%2Blink +parameter +link]] and got the following error:

''Warning: Compilation failed: nothing to repeat at offset 1 in /.../actions/textsearchexpanded.php on line 33''

for every page.
--NilsLindenberg
~&''In my recent RE exploits I have found that a warning of this type comes up when a regular expression isn't quite correct (though not every attempt to match may bring up teh warning); haven't investigated further in textsearchexpanded.php though. --JavaWoman''

-----
=== Yet more formatter bugs ===
Looking at **formatters/wikka.php** to find the cause of the two bugs listed below (found one), I notice to my horror that a **lot** of the regular expressions used there are actually incorrect. They allow such things as using a comma to indent a line (in addition to a tab, or ~, at the start of a line: **demo** in the SandBox, and in the list **below**!), or a comma in a WikiName (even at the start) or in an InterWiki link. That can't have been the intention - it's simply a matter of incorrect RE syntax. I'd become sort of "sensitized" to this phenomenon looking at DarTar's RE on ValidPageNames earlier today - now I see where he found an example (see my comment on that page on his RE!).
,''Note: see also [[,My,Page]] - yup, that's a real page now. ;-)''

~&Rather than simply fixing all the REs (and other REs all over the place...) I'd like to propose a more fundamental solution:
~&-create a "library" of RE building blocks to be used in the Wikka core (for an example of what I mean with building blocks see my propopsal for an alternative RE on ValidPageNames); simply create a separate file with define()s for these building blocks, and include them at the start of the main wikka.php file;
~&-gather all RE used in the Wikka core here (extensions/plugins could have their own set of defines - as long as they don't have conflicting names);
~&-now use **only** these building blocks when using REs anywhere in the Wikka core.
~&This should make it much easier to create both //correct//, and //consistent// regular expressions; any (near)duplicates will be much easier to discover, and fix.
~&
~&Probably best to leave this to just **after** the coming release, so we have a stable code base again. I volunteer to undertake this work. (Unlike some people, I happen to like REs.) :)
~&--JavaWoman

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

~&Possible clue:
~&I just stumbled over the fact that the little list of "Useful pages" at the end of the default (installation-generated) ""HomePage"" had incorrect coding: The last list item (li) was not terminated, nor was the list itself (no closing ul tag). It took me a bit of trial and error to reproduce this - but have a look at my test code at the end of SandBox (now). Originally I thought that any list at the end of a page would be unterminated, but that turned out not to be the case. Then I hit on something else: the last list element on that default ""HomePage"" (not the one here) ands with a period. My test version on SandBox now also has the last element ending in a period ... and if you look at the (HTML) page source, you'll see it is indeed an unterminated list. Somehow that ending period (maybe in combination with end-of-page?) causes the Formatter never to close the list; take that ending period away, and it works normally. I tried a few variants, to check whether it might be an odd-even problem, but no: whether the number of list items is odd or even, if the last one ends in a period, the list isn't terminated.
~&
~&No difference whether it's anordered (ol) or unordered (ul) list, the formatter behaves the same way.
~&
~&And, BTW, if you look at the preview when editing, the HTML source of the **preview** actually contains a lot of Wiki code that shouldn't be there!
~&
~&I haven't dug in the Formatter yet to find the cause or whether end-of-page makes a difference...
~&--JavaWoman

----
=== 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.
--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 "**dan**gerous" - 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

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

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

----
Bugs I've found:
- Security: I was wondering whether it would be possible to store IPs for registered users as well. That way you can ban them via .htaccess if necessary.
- ''Last known IP or every IP they ever connect from? I'd be willing to store one last known IP per user. '' - JsnX
- ''Last known IP please :) Thanks.'' - Sam
- ''I'd suggest adding *two* distinct fields to ##wikka_users##: Last Login IP/Hostname + Last Login Time'' - DarTar
- ''I was also thinking of a way to ban users directly from the wiki (much in the same way as referrers are added to the blacklist of spammers). This might turn out easier to implement than a //user deleting action// (which was one of the ideas discussed [[UserAdmin here]])'' - DarTar


- Security: Single-click restore of previous versions (without copying/pasting).
- ''Yes, this will be implemented at some point.'' - JsnX
- I should point out that there is an alternative to copying/pasting.
- Go to the revisions page.
- Click the date and time link that you would like to revert back to.
- Click the 'Re-edit this old revision' button.
- Click the 'Store' button.

Thanks - Sam
----
- Mod_rewrite : take a look at FaviconDotIco and RobotsDotTxt

::c::
----


Revision [5667]

Edited on 2005-02-05 21:35:54 by JavaWoman [repairing Chinese (sigh)]
Additions:
A page contains unicode characters looks OK when viewed but displays ""''&#*****;''"" while edited in WikiEdit
中文是一种美丽的语言,除了具有音节上的美感,同样拥有视觉上的美感
Deletions:
A page contains unicode characters looks OK when viewed but displays ''&#*****;'' while edited in WikiEdit
??????????,??????????,??????????


Revision [5646]

Edited on 2005-02-05 09:38:29 by RyanKnoll [verified the doubleclick "off" option is broken]
Additions:
~Yes, I noticed the same thing. This is a bug as of 1.1.6.0. --RyanKnoll


Revision [5545]

Edited on 2005-02-03 20:52:45 by NilsLindenberg [resolved bugs moved]
Deletions:
- 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. ''Deeper analysis shows that WikiPage is meant to be uncreated by default, my apologies. WikiName is found on UserSettings (when you don't enter a valid username) and FormattingRules by default.''
- 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?).''


Revision [5475]

Edited on 2005-02-02 11:32:53 by NilsLindenberg [another copy from the sandbox]
Additions:
===Opera and layer===
Opera browser doesn't like a right layer a the end of a page :(


Revision [5467]

Edited on 2005-02-02 10:26:40 by NilsLindenberg [copied bug from sandbox]
Additions:
===Missing language-support in the code formatter===
(copied from the sandbox --NilsLindenberg)
not support 2byte language in the Code formatters!!!!
%%(c)
// 한글이 깨지겠지
// 진짜 깨지네.. 흑흑.. 에디터창에서 깨지는 것도 열받는데..
...


Revision [5429]

Edited on 2005-02-01 11:16:05 by NilsLindenberg [layout]
Additions:
~&I think that this is due to the encoding of the MySQL tables. I can't see how that would be fixed with a small touch on the code. If this is the matter then I hope that it also rings the i18n bell too. //Translation to Greek is my bussiness ;)//
~&""--""GeorgePetsagourakis
~~&Yes, my i18n bells were already loudly ringing... but you bring up a good point with MySQL. I hadn't thought about a real cause yet, just wanted to record what I saw before I got distracted again ;-). Sort order is a whole subject of its own within i18n .... --JavaWoman
~&''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''
~&''Looks like the weirdness is caused by the ""{{Category}}"" action which assumes the "current page" represents the category - and find pages "belonging to" a category by finding a mention of that page name. Good sign our category system does need an [[CategorySystemOverhaul overhaul]]! --JavaWoman''
~&The cause is apparently in the ""LoadPagesLinkingTo()"" method which is used by ##""{{backlinks}}""## action. It currently is implemented like this:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' order by tag"); }
%% I think replacing this by:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' and latest = 'Y' order by tag"); }
~&--JavaWoman
~&''I've now written up my thoughts about a [[WikkaSecureConfig more secure way to handle Wikka's configuration]] (which should also provide also more flexibility). --JavaWoman''
~&''In my recent RE exploits I have found that a warning of this type comes up when a regular expression isn't quite correct (though not every attempt to match may bring up teh warning); haven't investigated further in textsearchexpanded.php though. --JavaWoman''
~&Rather than simply fixing all the REs (and other REs all over the place...) I'd like to propose a more fundamental solution:
~&-create a "library" of RE building blocks to be used in the Wikka core (for an example of what I mean with building blocks see my propopsal for an alternative RE on ValidPageNames); simply create a separate file with define()s for these building blocks, and include them at the start of the main wikka.php file;
~&-gather all RE used in the Wikka core here (extensions/plugins could have their own set of defines - as long as they don't have conflicting names);
~&-now use **only** these building blocks when using REs anywhere in the Wikka core.
~&This should make it much easier to create both //correct//, and //consistent// regular expressions; any (near)duplicates will be much easier to discover, and fix.
~&
~&Probably best to leave this to just **after** the coming release, so we have a stable code base again. I volunteer to undertake this work. (Unlike some people, I happen to like REs.) :)
~&--JavaWoman
~&Possible clue:
~&I just stumbled over the fact that the little list of "Useful pages" at the end of the default (installation-generated) ""HomePage"" had incorrect coding: The last list item (li) was not terminated, nor was the list itself (no closing ul tag). It took me a bit of trial and error to reproduce this - but have a look at my test code at the end of SandBox (now). Originally I thought that any list at the end of a page would be unterminated, but that turned out not to be the case. Then I hit on something else: the last list element on that default ""HomePage"" (not the one here) ands with a period. My test version on SandBox now also has the last element ending in a period ... and if you look at the (HTML) page source, you'll see it is indeed an unterminated list. Somehow that ending period (maybe in combination with end-of-page?) causes the Formatter never to close the list; take that ending period away, and it works normally. I tried a few variants, to check whether it might be an odd-even problem, but no: whether the number of list items is odd or even, if the last one ends in a period, the list isn't terminated.
~&
~&No difference whether it's anordered (ol) or unordered (ul) list, the formatter behaves the same way.
~&
~&And, BTW, if you look at the preview when editing, the HTML source of the **preview** actually contains a lot of Wiki code that shouldn't be there!
~&
~&I haven't dug in the Formatter yet to find the cause or whether end-of-page makes a difference...
~&--JavaWoman
~&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
--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
~&(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
Deletions:
I think that this is due to the encoding of the MySQL tables. I can't see how that would be fixed with a small touch on the code.
If this is the matter then I hope that it also rings the i18n bell too. //Translation to Greek is my bussiness ;)//
""--""GeorgePetsagourakis
~Yes, my i18n bells were already loudly ringing... but you bring up a good point with MySQL. I hadn't thought about a real cause yet, just wanted to record what I saw before I got distracted again ;-). Sort order is a whole subject of its own within i18n .... --JavaWoman
~''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''
~''Looks like the weirdness is caused by the ""{{Category}}"" action which assumes the "current page" represents the category - and find pages "belonging to" a category by finding a mention of that page name. Good sign our category system does need an [[CategorySystemOverhaul overhaul]]! --JavaWoman''
The cause is apparently in the ""LoadPagesLinkingTo()"" method which is used by ##""{{backlinks}}""## action. It currently is implemented like this:
%%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' order by tag"); }
I think replacing this by:
%%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' and latest = 'Y' order by tag"); }
''I've now written up my thoughts about a [[WikkaSecureConfig more secure way to handle Wikka's configuration]] (which should also provide also more flexibility). --JavaWoman''
~''In my recent RE exploits I have found that a warning of this type comes up when a regular expression isn't quite correct (though not every attempt to match may bring up teh warning); haven't investigated further in textsearchexpanded.php though. --JavaWoman''
Rather than simply fixing all the REs (and other REs all over the place...) I'd like to propose a more fundamental solution:
,-create a "library" of RE building blocks to be used in the Wikka core (for an example of what I mean with building blocks see my propopsal for an alternative RE on ValidPageNames); simply create a separate file with define()s for these building blocks, and include them at the start of the main wikka.php file;
,-gather all RE used in the Wikka core here (extensions/plugins could have their own set of defines - as long as they don't have conflicting names);
,-now use **only** these building blocks when using REs anywhere in the Wikka core.
This should make it much easier to create both //correct//, and //consistent// regular expressions; any (near)duplicates will be much easier to discover, and fix.
Probably best to leave this to just **after** the coming release, so we have a stable code base again. I volunteer to undertake this work. (Unlike some people, I happen to like REs.) :)
Possible clue:
I just stumbled over the fact that the little list of "Useful pages" at the end of the default (installation-generated) ""HomePage"" had incorrect coding: The last list item (li) was not terminated, nor was the list itself (no closing ul tag). It took me a bit of trial and error to reproduce this - but have a look at my test code at the end of SandBox (now). Originally I thought that any list at the end of a page would be unterminated, but that turned out not to be the case. Then I hit on something else: the last list element on that default ""HomePage"" (not the one here) ands with a period. My test version on SandBox now also has the last element ending in a period ... and if you look at the (HTML) page source, you'll see it is indeed an unterminated list. Somehow that ending period (maybe in combination with end-of-page?) causes the Formatter never to close the list; take that ending period away, and it works normally. I tried a few variants, to check whether it might be an odd-even problem, but no: whether the number of list items is odd or even, if the last one ends in a period, the list isn't terminated.
No difference whether it's anordered (ol) or unordered (ul) list, the formatter behaves the same way.
And, BTW, if you look at the preview when editing, the HTML source of the **preview** actually contains a lot of Wiki code that shouldn't be there!
I haven't dug in the Formatter yet to find the cause or whether end-of-page makes a difference...
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
~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
(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...)
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


Revision [5367]

Edited on 2005-01-30 07:53:27 by JavaWoman ["target" -> SuggestionBox (not a bug)]
Deletions:
==="target=" in external links?===
Is there a way to include a target in a link, so that the Link opens in a new window?


Revision [5340]

Edited on 2005-01-28 16:56:15 by GregorLindner ["target" -> SuggestionBox (not a bug)]
Additions:
==="target=" in external links?===
Is there a way to include a target in a link, so that the Link opens in a new window?
??????????,??????????,??????????
~''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''
Deletions:
中文是一种美丽的语言,除了具有音节上的美感,同样拥有视觉上的美感
~''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''


Revision [5305]

Edited on 2005-01-28 08:58:08 by DotMG [</a></a> and & inside URL in handler referrers_sites]
Additions:
- & in URL should be replaced by &amp;
Deletions:
- & in URL should be replaced by &


Revision [5304]

Edited on 2005-01-28 08:53:51 by DotMG [handler referrers_sites is not valid XHTML.]
Additions:
===Error on ./handlers/page/referrers_sites===
Line 46 :
- Code generates a double </a> for links.
- & in URL should be replaced by &
=> %%(php) print("<td valign=\"top\">" . (($site != "unknown") ? "<a href=\"http://".$this->htmlspecialchars_ent($site)."\">".$this->htmlspecialchars_ent($site)."</a>" : $site) . /*"</a> ".*/($IsAdmin ? "[<a href=\"".$this->href("delete_referrer", "", "spam_site=").$this->htmlspecialchars_ent($site)."&redirect=".$this->GetMethod()."\">Blacklist</a>]" : "")."</td>");%%
Note: You cannot see this error by validating directly a page because W3C is not registered and it will not have the same output as you, in other words, code on line 46 won't be executed. But you can save the page on your hard disk and validate it.


Revision [5286]

Edited on 2005-01-28 02:41:41 by GmBowen [problem with wikiedit]
Additions:
===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


Revision [5252]

Edited on 2005-01-26 21:47:28 by JavaWoman [reference to WikkaWorkarounds; moved WikkaOptimization ref. to SuggestionBox]
Additions:
-workarounds for unusual problems and temporary fixes for known bugs listed at WikkaWorkarounds
Deletions:
-a new page dedicated for optimization : WikkaOptimization (???)


Revision [5232]

Edited on 2005-01-26 18:36:35 by JavaWoman [reply about Unicode problem]
Additions:
~&This workaround you outlined will work as well in Wikka 1.1.6.0. A real solution wil take some more investigation though, so we were unable to fix this for the current release. This is now under investigation. --JavaWoman


Revision [5179]

Edited on 2005-01-25 15:53:43 by DotMG [Bug with Accept-Encoding: gzip;q=0, deflate]
Additions:
===Accept-Encoding: gzip;q=0, deflate===
**Not really bug, but should be corrected for respect & compliance to RFC2616**
If a browser sends the header
Accept-Encoding: gzip;q=0, deflate
Which should be interpreted as : "I don't support gzip encoding, but I prefer deflate", Wikka will understand "The browser supports gzip-encoding", as it just searches for the text gzip in $_SERVER['HTTP_ACCEPT_ENCODING']. An example I use to treat it correctly is :
%%(php) function ParseHeaderLine($hl, $token=null)
{
$ar_hl = explode(',', $hl);
foreach ($ar_hl as $dotmg_idx => $val)
{
if (preg_match('/^\s*(.*?);\s*q\s*=\s*([0-9\.]*)/i', $val, $match))
{
$res[strtolower($match[1])] = doubleval($match[2]);
}
else
{
$res[strtolower($val)] = 1;
}
}
if ($token) return(isset($res[$token]) && ($res[$token] > 0)); #if $token is set, we return true or false
return ($res); # else we return the header parsed.
}%%
and
%%(php) if ($this->ParseHeaderLine($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ...%%
Note : This function might be useful to deal also with Accept-Language, when Wikka will be made effectively multilingual.
===1.1.6.0beta4: Simplified Chinese (or Unicode relative) in WikiEdit:===
Deletions:
**1.1.6.0beta4: Simplified Chinese (or Unicode relative) in WikiEdit:**


Revision [5153]

Edited on 2005-01-25 02:03:29 by ZhuangYuyao [Bug with Accept-Encoding: gzip;q=0, deflate]
Additions:
Wikka is wonderful! ZhuangYuyao


Revision [5152]

Edited on 2005-01-25 02:01:06 by ZhuangYuyao [Bug with Accept-Encoding: gzip;q=0, deflate]
Additions:
**1.1.6.0beta4: Simplified Chinese (or Unicode relative) in WikiEdit:**
A page contains unicode characters looks OK when viewed but displays ''&#*****;'' while edited in WikiEdit
Simplified Chinese Test:
中文是一种美丽的语言,除了具有音节上的美感,同样拥有视觉上的美感
In 1.1.5.3, I solved this problem by changed some line in ./handlers/page/edit.php
#from
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$body."</textarea><br />\n"
#to
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$this->htmlspecialchars_ent($body)."</textarea><br />\n"


Revision [5021]

Edited on 2005-01-23 21:02:01 by JavaWoman [moved latest addition to the TOP]
Additions:
===Double-click editing===


Revision [5016]

Edited on 2005-01-23 20:03:05 by MarkHissinkMuller [moved latest addition to the TOP]
Additions:
I noticed: Turning off DoubleClick-editing does not work (double-clicks still go to edit-window) in IE 6.0 or Firefox 1.0.
Keep up the good work!
Cheers, MarkHissinkMuller


Revision [4401]

Edited on 2005-01-11 02:05:31 by JsnX [removed Googleform bug]
Deletions:
===Googleform action===
The googleform action assumes that "short open tags" can be used for PHP. But this is not the case on every installation and is actually discouraged. If they are indeed disabled (##short_open_tag = Off## in ##php.ini##), the googleform action will not work.
See also http://php.net/manual/en/ini.sect.language-options.php#ini.short-open-tag.
Fix: replace ##<?=$q ?>## by **##<?php echo $q;?>##** in the value attribute of the form (line 14).


Revision [4385]

Edited on 2005-01-10 20:09:01 by ArpY [removed Googleform bug]
Additions:
~&ArpY: Maybe this is caused by a config error. Please have a look at your config - is there a slash at the end of the base_url?


Revision [4253]

Edited on 2005-01-08 04:00:32 by JoshJohn [$Request problem]
Additions:
===$_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)
<?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


Revision [4227]

Edited on 2005-01-07 19:12:01 by ChristianBarthelemy [Removed my problem using mod_rewrite (not a bug)]
Deletions:
===Simple wiki URL problem===
Typing "http://MyWikkaSite/WikkaPage" does not work and I have to type "http://MyWikkaSite/wikka.php?wakka=WikkaPage".
This seems to be a bug solved by 1.1.6.0 (no problem on this site) as I have it with my current installation 1.1.5.3 and I checked that other WikkaSites have it as well. I coulnd't find anything in the WikkaReleaseNotes either.
Any idea where this could comes from?
~''It simply depends on whether "rewriting" is on - check your config and .htaccess files. See also ModRewrite. --JavaWoman''
~~"I am afraid this doesn't work anymore - to be certain, I installed a brand new wikka 1.1.5.3 and id didn't worked either. --ChristianBarthelemy"
ChristianBarthelemy, I mean this in the politest way possible: ModRewrite has been thoroughly tested with Wikka. There is no mention in the WikkaReleaseNotes of fixing a ModRewrite bug because there is no ModRewrite bug. I'm trying to be helpful when I suggest that you take a look at your web host for the problem. You say that other sites have this problem. A more accurate statement would be that other sites do not have mod_rewrite enabled. Not all web hosts enable mod_rewrite or configure it correctly. -- JsnX
~''Please forgive my lack of understanding, I should have explain things differently. Do you have any idea why it wouldn't work on my installation? I have a windows 2K base, Apache+PhP+MySql and no trouble so far with my Wikka. As I fear I could have broke something with some additional code of mine, I tried a new setup from scratch and still have the problem. JavaWoman mentioned something about the .htaccess files but this is not necessary on Windows I think. Anyway, as I understand you are disturbed having this "problem" described in this page feel free to remove it."
In Wikka, as distributed, the .htaccess file(s) take care of the rewriting, so if you want to use mod_rewrite, .htaccess //is// necessary - unless you copy the content into a section in httpd.conf (if you have root access). Without the appropriate mod-rewrite statements in either .htaccess or httpd.conf no rewriting will take place. -- JavaWoman


Revision [4147]

Edited on 2005-01-07 11:45:40 by JavaWoman [reply to Christian]
Additions:
In Wikka, as distributed, the .htaccess file(s) take care of the rewriting, so if you want to use mod_rewrite, .htaccess //is// necessary - unless you copy the content into a section in httpd.conf (if you have root access). Without the appropriate mod-rewrite statements in either .htaccess or httpd.conf no rewriting will take place. -- JavaWoman


Revision [4136]

Edited on 2005-01-07 11:23:23 by ChristianBarthelemy [Answer to Jason]
Additions:
~''Please forgive my lack of understanding, I should have explain things differently. Do you have any idea why it wouldn't work on my installation? I have a windows 2K base, Apache+PhP+MySql and no trouble so far with my Wikka. As I fear I could have broke something with some additional code of mine, I tried a new setup from scratch and still have the problem. JavaWoman mentioned something about the .htaccess files but this is not necessary on Windows I think. Anyway, as I understand you are disturbed having this "problem" described in this page feel free to remove it."


Revision [4114]

Edited on 2005-01-07 00:10:48 by JsnX [reply to ChristianBarthelemy about mod_rewrite]
Additions:
ChristianBarthelemy, I mean this in the politest way possible: ModRewrite has been thoroughly tested with Wikka. There is no mention in the WikkaReleaseNotes of fixing a ModRewrite bug because there is no ModRewrite bug. I'm trying to be helpful when I suggest that you take a look at your web host for the problem. You say that other sites have this problem. A more accurate statement would be that other sites do not have mod_rewrite enabled. Not all web hosts enable mod_rewrite or configure it correctly. -- JsnX


Revision [4112]

Edited on 2005-01-06 22:46:10 by ChristianBarthelemy [Anyone else has problem with ModRewrite?]
Additions:
~~"I am afraid this doesn't work anymore - to be certain, I installed a brand new wikka 1.1.5.3 and id didn't worked either. --ChristianBarthelemy"


Revision [4110]

Edited on 2005-01-06 21:30:46 by JavaWoman [reply to Christian]
Additions:
~''It simply depends on whether "rewriting" is on - check your config and .htaccess files. See also ModRewrite. --JavaWoman''


Revision [4109]

Edited on 2005-01-06 21:14:05 by JavaWoman [reply to Mike]
Additions:
~~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''
Deletions:
~~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.


Revision [4104]

Edited on 2005-01-06 20:33:18 by GmBowen [reply to JW.]
Additions:
~~''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.
Deletions:
~~''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 askgin 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''


Revision [4102]

Edited on 2005-01-06 20:27:06 by ChristianBarthelemy [Typing "http://MyWikkaSite/WikkaPage" does not work and I have to type "http://MyWikk]
Additions:
===Simple wiki URL problem===
Typing "http://MyWikkaSite/WikkaPage" does not work and I have to type "http://MyWikkaSite/wikka.php?wakka=WikkaPage".
This seems to be a bug solved by 1.1.6.0 (no problem on this site) as I have it with my current installation 1.1.5.3 and I checked that other WikkaSites have it as well. I coulnd't find anything in the WikkaReleaseNotes either.
Any idea where this could comes from?


Revision [3979]

Edited on 2005-01-04 20:55:52 by JavaWoman [reply to George]
Additions:
""--""GeorgePetsagourakis
~Yes, my i18n bells were already loudly ringing... but you bring up a good point with MySQL. I hadn't thought about a real cause yet, just wanted to record what I saw before I got distracted again ;-). Sort order is a whole subject of its own within i18n .... --JavaWoman
Deletions:
--GeorgePetsagourakis


Revision [3974]

Edited on 2005-01-04 20:22:31 by GeorgePetsagourakis [reply2jw]
Additions:
I think that this is due to the encoding of the MySQL tables. I can't see how that would be fixed with a small touch on the code.
If this is the matter then I hope that it also rings the i18n bell too. //Translation to Greek is my bussiness ;)//
--GeorgePetsagourakis


Revision [3973]

Edited on 2005-01-04 19:32:00 by JavaWoman [new: PageIndex problem]
Additions:
===PageIndex problem===
DarTar and I have recently created some test pages, testing page names related to how Wikka evaluates 'valid' page names: ,My,Page and ÄhnLich (yes, they both exist, even if they don't show up as such in this sentence!). Now look at where they show up on PageIndex... surely there shouldn't be **two** '#' indices??


Revision [3972]

Edited on 2005-01-04 19:26:15 by JavaWoman [nother try about floating ∞s]
Additions:
~~''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 askgin 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''


Revision [3945]

Edited on 2005-01-03 23:22:53 by JavaWoman [nother floating reply]
Additions:
~~~~~''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''


Revision [3938]

Edited on 2005-01-03 22:00:48 by GmBowen [reply to JW]
Additions:
~~~~''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''


Revision [3937]

Edited on 2005-01-03 21:17:42 by JavaWoman [reply to GmBowen]
Additions:
~~~''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''


Revision [3936]

Edited on 2005-01-03 21:06:40 by GmBowen [reply to JW]
Additions:
~~''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''
Deletions:
~~''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.) --GmBowen''


Revision [3935]

Edited on 2005-01-03 20:58:21 by GmBowen [reply to JW]
Additions:
~~''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.) --GmBowen''


Revision [3934]

Edited on 2005-01-03 20:47:06 by JavaWoman [more on floating ∞s]
Additions:
~~''TEST: Please try with my stylesheet again, to see if that makes any difference now (I tweaked it). --JavaWoman''


Revision [3931]

Edited on 2005-01-03 19:55:06 by GmBowen [reply to JW]
Additions:
~~~~''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''


Revision [3930]

Edited on 2005-01-03 19:44:37 by JavaWoman [More ?? about the floating ∞s]
Additions:
~~~''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''


Revision [3929]

Edited on 2005-01-03 19:31:57 by GmBowen [reply to JW]
Additions:
~''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''
Deletions:
~''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 mor 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''


Revision [3928]

Edited on 2005-01-03 19:25:15 by JavaWoman [another ? about the floating ∞s]
Additions:
~''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 mor 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''
Deletions:
~''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 mor like a browser problem than a Wikka problem... --JavaWoman''


Revision [3927]

Edited on 2005-01-03 19:21:46 by JavaWoman [? about floating external link image]
Additions:
~''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 mor like a browser problem than a Wikka problem... --JavaWoman''


Revision [3926]

Edited on 2005-01-03 19:18:12 by JavaWoman [layout]
Additions:
**Please post recently discovered bugs on the //top// of this page (just below this note).**---
===Install Note on Basic URL and CSS===
Deletions:
=====Install Note on Basic URL and CSS=====
**Please post recently discovered bugs on the //top// of this page.**---


Revision [3925]

Edited on 2005-01-03 19:02:50 by DuncanHsu [Add bug: 'Install Note on Basic URL and CSS']
Additions:
=====Install Note on Basic URL and CSS=====
First, this may applied to my ISP only. When I installed, I have to use
the ?wakka= options. However, I have to add a / to the end of the
default Basic URL before append ?wakka= to it. So I think it maybe
helpful to modify the instruction to '... so it should include
the "/?wakka=" parameter...'


Revision [3923]

Edited on 2005-01-03 16:04:37 by GmBowen [floating "link" images on page]
Additions:
===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.
http://gmbowen.educ.unb.ca/wikitest/bug.jpg
http://gmbowen.educ.unb.ca/wikitest/bug2.jpg
http://gmbowen.educ.unb.ca/wikitest/bug3.jpg


Revision [3915]

Edited on 2005-01-03 10:41:29 by JavaWoman [include weirdness is category weirdness]
Additions:
Um, I don't know how to describe this really. Put ""{{include page="CategoryDocumentation"}}"" on the SandBox page....I can't figure out why it gives that output as Sandbox doesn't own anything.
~''Looks like the weirdness is caused by the ""{{Category}}"" action which assumes the "current page" represents the category - and find pages "belonging to" a category by finding a mention of that page name. Good sign our category system does need an [[CategorySystemOverhaul overhaul]]! --JavaWoman''
Deletions:
Um, I don't know how to describe this really. Put ""{{include page="CategoryDocumentation"}}"" on the SandBox page....I can't figure out why it gives that output as Sandbox doesn't own anything.


Revision [3890]

Edited on 2005-01-02 18:38:26 by GmBowen [weirdness with "include" action]
Additions:
===Weirdness with Include===
Um, I don't know how to describe this really. Put ""{{include page="CategoryDocumentation"}}"" on the SandBox page....I can't figure out why it gives that output as Sandbox doesn't own anything.


Revision [3849]

Edited on 2004-12-30 23:51:38 by NilsLindenberg [MyChanges alphabetical sort doesn't work moved to WikkaBugsResolved]
Deletions:
===MyChanges alphabetical sort doesn't work===
When using MyChanges action and clicking on the "order alphabetically" link the system tries to go at ""http://mywebsite/wikka/wikka.php?wakka=MyChanges?alphabetically=1"" and proposes to create the page. I uploaded again the MyChanges.php action from the current Wikka release (1.1.5.3) without solving anything as it was excatly the same code.
The action ""{{userchanges}}"" works perfectly.
--ChristianBarthelemy
Find this line:
%%(php) print("<strong>This is a list of pages you've edited, ordered by the time of your last change (<a href=\"".$this->href("", $tag)."?alphabetically=1\">order alphabetically</a>).</strong><br /><br />\n"); %%
And change it to this:
%%(php) print("<strong>This is a list of pages you've edited, ordered by the time of your last change (<a href=\"".$this->href("", $tag, "alphabetically=1")."\">order alphabetically</a>).</strong><br /><br />\n"); %%
This change will be included in version 1.1.6.0. -- JsnX


Revision [3844]

Edited on 2004-12-30 23:36:35 by NilsLindenberg [TromboneFreakus questions moved to WikkaBugsResolved and the FAQ]
Deletions:
===Comments don't work===
I have a Wikka setup very basically at http://www.student.ru.nl/markjansen/Wikka/
At the bottom of each page, there's this link [Add comment]. However, this link is wrong.
It points to wikka.php?wakka=HomePage**?**show_comments=1#comments
It should however point to:
wikka.php?wakka=HomePage**&**show_comments=1#comments
I tried to fix this by editing the file handlers/page/show.php, but I couldn't figure it out.
''look in your wikka.config.php: if you have 'rewrite_mode' => '1', set it to '0'. That should solve the problem?'' --NilsLindenberg
''You don't need to edit the handlers, because the "?" vs. "&" option is handled by core functions. Nils' suggestion should work '' --DarTar
Yup, this works. Thanks!
And isn't it possible to have the comments shown by default for every user?
''at the moment not. maybe if someone has time... do you mean every registered user, or every user? '' --NilsLindenberg
''I don't understand the question. Can you please be more specific? '' --DarTar
Oops, I thought they didn't show up by default, but it apperently does.
And will there be translations?
''An internalization/localization project is currently under discussion, but it requires a major overhaul of the code, so don't expect it to appear in the very next releases'' -- DarTar
Please help me. Thanks!! - TromboneFreakus


Revision [3829]

Edited on 2004-12-29 21:32:05 by TromboneFreakus [TromboneFreakus questions moved to WikkaBugsResolved and the FAQ]
Additions:
Yup, this works. Thanks!
Oops, I thought they didn't show up by default, but it apperently does.


Revision [3780]

Edited on 2004-12-28 15:30:07 by JavaWoman [Moving Foreach in php version 4.3.10 to WikkaBugsResolved]
Additions:
<<>>==Attention:==
For problems with **foreach** in PHP version **4.3.10**:---See WikkaBugsResolved>>::c::
Deletions:
<<::c::
===Foreach in php version 4.3.10===
Has anybody tested php version 4.3.10?
My server has migrated to version 4.3.10 of PHP. And from now, it seems that the syntax
%%(php)<?php foreach ($array as $element) ?>%% is not correct, and should be replaced by
%%(php)<?php foreach ($array as $index => $element)?>%%.
-- DotMG
''Where did you get this info? Can you please give a pointer to the php documentation? -- DarTar''
''Do you have a reference (URL) for this? This is pretty scary, I'd have to check and change tons of code (at least as soon as my hoster makes a new version available...) --JavaWoman''
''Found something here: http://www.zend.com/zend/week/week215.php#Heading5 --JavaWoman''
''More here:
~-http://bugs.php.net/bug.php?id=31134
~-http://bugs.php.net/bug.php?id=31108 ---("Ran into the same problem with 'foreach' during preliminary testing...---The solution is to ensure that your ZendOptimizer has been upgraded to a minimum of 2.5.7...")
Looks like changing the syntax is only a workaround in case a new Zend version cannot be installed --JavaWoman''
~-Please see ForeachBugInPhp4dot3dot10 --DotMG
~''More extensive comments on the (misnamed!) page referred to above, but in short: As can be seen from the references I gave above, **there is no bug**. //All// bug reports in the PHP bugtracker have been been (rightly) classiified as "Bogus". The (clever) "correction" presesented above is not a correction, but merely a **temporary workaround**. The **real fix** is to disable ""ZendOptimizer"" (or other accellerator used, they are also affected) or upgrade it to the latest version.---If/Once the latest version of the accellerator is in place, make sure you **empty the accellerator's cache**: existing cahed files will still have the error.''
~''**The Wikka code base should NOT be changed with respect to foreach usage.**
~An //installation// might be temporarily helped with DotMG's workaround, though. --JavaWoman''


Revision [3778]

Edited on 2004-12-28 15:23:11 by JavaWoman [additional note about PHP accelleration wrt PHP 4.3.10 / layout]
Additions:
<<**Related pages**:
<<::c::
~''More extensive comments on the (misnamed!) page referred to above, but in short: As can be seen from the references I gave above, **there is no bug**. //All// bug reports in the PHP bugtracker have been been (rightly) classiified as "Bogus". The (clever) "correction" presesented above is not a correction, but merely a **temporary workaround**. The **real fix** is to disable ""ZendOptimizer"" (or other accellerator used, they are also affected) or upgrade it to the latest version.---If/Once the latest version of the accellerator is in place, make sure you **empty the accellerator's cache**: existing cahed files will still have the error.''
~''**The Wikka code base should NOT be changed with respect to foreach usage.**
Deletions:
>>**Related pages**:
>>
~''More extensive comments on the (misnamed!) page referred to above, but in short: As can be seen from the references I gave above, **there is no bug**. //All// bug reports in the PHP bugtracker have been been (rightly) classiified as "Bogus". The (clever) "correction" presesented above is not a correction, but merely a **temporary workaround**. The **real fix** is to disable ""ZendOptimizer"" (or other accelerator used, they are also affected) or upgrade it to the latest version.''
~''**The Wikka code base should not be changed with respect to foreach usage.**


Revision [3775]

Edited on 2004-12-28 13:19:57 by DotMG [Add link to WikkaOptimization]
Additions:
>>**Related pages**:
-a new page dedicated for optimization : WikkaOptimization (???)
>>
::c::
Deletions:
<<**Related pages**:
<<::c::


Revision [3771]

Edited on 2004-12-28 10:20:11 by JavaWoman [not a bug!]
Additions:
~-Please see ForeachBugInPhp4dot3dot10 --DotMG
~''More extensive comments on the (misnamed!) page referred to above, but in short: As can be seen from the references I gave above, **there is no bug**. //All// bug reports in the PHP bugtracker have been been (rightly) classiified as "Bogus". The (clever) "correction" presesented above is not a correction, but merely a **temporary workaround**. The **real fix** is to disable ""ZendOptimizer"" (or other accelerator used, they are also affected) or upgrade it to the latest version.''
~''**The Wikka code base should not be changed with respect to foreach usage.**
~An //installation// might be temporarily helped with DotMG's workaround, though. --JavaWoman''
Deletions:
~-Please see ForeachBugInPhp4dot3dot10


Revision [3768]

Edited on 2004-12-28 06:29:57 by DotMG [Answering about foreach bug in php 4.3.10]
Additions:
~-Please see ForeachBugInPhp4dot3dot10


Revision [3757]

Edited on 2004-12-27 15:42:04 by JavaWoman [more on foreach bug]
Additions:
''More here:
~-http://bugs.php.net/bug.php?id=31134
~-http://bugs.php.net/bug.php?id=31108 ---("Ran into the same problem with 'foreach' during preliminary testing...---The solution is to ensure that your ZendOptimizer has been upgraded to a minimum of 2.5.7...")
Looks like changing the syntax is only a workaround in case a new Zend version cannot be installed --JavaWoman''


Revision [3723]

Edited on 2004-12-27 10:11:41 by JavaWoman [more about PHP bug]
Additions:
''Found something here: http://www.zend.com/zend/week/week215.php#Heading5 --JavaWoman''


Revision [3721]

Edited on 2004-12-27 10:01:49 by JavaWoman [layout]

No Differences

Revision [3720]

Edited on 2004-12-27 09:57:15 by JavaWoman [query for DotMG]
Additions:
''Do you have a reference (URL) for this? This is pretty scary, I'd have to check and change tons of code (at least as soon as my hoster makes a new version available...) --JavaWoman''


Revision [3717]

Edited on 2004-12-27 09:41:45 by DarTar [Replying to DotMG and TromboneFreakus]
Additions:
{{lastedit show="3"}}
''Where did you get this info? Can you please give a pointer to the php documentation? -- DarTar''
''You don't need to edit the handlers, because the "?" vs. "&" option is handled by core functions. Nils' suggestion should work '' --DarTar
''I don't understand the question. Can you please be more specific? '' --DarTar
''An internalization/localization project is currently under discussion, but it requires a major overhaul of the code, so don't expect it to appear in the very next releases'' -- DarTar


Revision [3715]

Edited on 2004-12-27 08:32:40 by DotMG [Maybe a bug on PHP version 4.3.10 (foreach doesn't work well).]
Additions:
===Foreach in php version 4.3.10===
Has anybody tested php version 4.3.10?
My server has migrated to version 4.3.10 of PHP. And from now, it seems that the syntax
%%(php)<?php foreach ($array as $element) ?>%% is not correct, and should be replaced by
%%(php)<?php foreach ($array as $index => $element)?>%%.
-- DotMG


Revision [3712]

Edited on 2004-12-26 23:37:23 by NilsLindenberg [reply to TromboneFreakus]
Additions:
''look in your wikka.config.php: if you have 'rewrite_mode' => '1', set it to '0'. That should solve the problem?'' --NilsLindenberg
Deletions:
''look in your wikka.config.php: do you have 'rewrite_mode' => '0', ?'' --NilsLindenberg


Revision [3710]

Edited on 2004-12-26 23:28:34 by NilsLindenberg [reply to TromboneFreakus]
Additions:
''look in your wikka.config.php: do you have 'rewrite_mode' => '0', ?'' --NilsLindenberg
''at the moment not. maybe if someone has time... do you mean every registered user, or every user? '' --NilsLindenberg


Revision [3692]

Edited on 2004-12-26 20:20:50 by TromboneFreakus [reply to TromboneFreakus]
Additions:
Please help me. Thanks!! - TromboneFreakus
Deletions:
Please help me. Thanks!!


Revision [3690]

Edited on 2004-12-26 20:19:42 by TromboneFreakus [reply to TromboneFreakus]

No Differences

Revision [3689]

Edited on 2004-12-26 20:18:34 by TromboneFreakus [added bug with comments]
Additions:
===Comments don't work===
I have a Wikka setup very basically at http://www.student.ru.nl/markjansen/Wikka/
At the bottom of each page, there's this link [Add comment]. However, this link is wrong.
It points to wikka.php?wakka=HomePage**?**show_comments=1#comments
It should however point to:
wikka.php?wakka=HomePage**&**show_comments=1#comments
I tried to fix this by editing the file handlers/page/show.php, but I couldn't figure it out.
And isn't it possible to have the comments shown by default for every user?
And will there be translations?
Please help me. Thanks!!


Revision [3483]

Edited on 2004-12-19 18:11:37 by JavaWoman [ypot in backlinks bug]
Additions:
I just discovered that the ##""{{backlinks}}""## action may list pages that don't "exist" any more, in the sense that they (apparently) still are in the database but without any active version (seemingly as a result of a rename action. I added an example on [[JavaWoman my own page]] where you can see a supposed backlink from ReleaseNotes (which was replaced by WikkaReleaseNotes).
Deletions:
I just discoverd that the ##""{{backlinks}}""## action may list pages that don't "exist" any more, in the sense that they (apparently) still are in the database but without any active version (seemingly as a result of a rename action. I added an example on [[JavaWoman my own page]] where you can see a supposed backlink from ReleaseNotes (which was replaced by WikkaReleaseNotes).


Revision [3482]

Edited on 2004-12-19 18:10:30 by JavaWoman [backlinks bug added]
Additions:
===Backlinks / ""LoadPagesLinkingTo()""===
I just discoverd that the ##""{{backlinks}}""## action may list pages that don't "exist" any more, in the sense that they (apparently) still are in the database but without any active version (seemingly as a result of a rename action. I added an example on [[JavaWoman my own page]] where you can see a supposed backlink from ReleaseNotes (which was replaced by WikkaReleaseNotes).
The cause is apparently in the ""LoadPagesLinkingTo()"" method which is used by ##""{{backlinks}}""## action. It currently is implemented like this:
%%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' order by tag"); }
I think replacing this by:
%%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' and latest = 'Y' order by tag"); }
%% might do the trick to avoid deceased pages - but please test!


Revision [3461]

Edited on 2004-12-19 11:43:36 by JavaWoman [comment about "Expanded Text Search" bug]
Additions:
~''In my recent RE exploits I have found that a warning of this type comes up when a regular expression isn't quite correct (though not every attempt to match may bring up teh warning); haven't investigated further in textsearchexpanded.php though. --JavaWoman''


Revision [3455]

Edited on 2004-12-18 21:49:07 by JavaWoman [added reference to the SuggestionBox]
Additions:
-for feature suggestions rather than bugs, go to the SuggestionBox


Revision [3453]

Edited on 2004-12-18 21:47:13 by JavaWoman [User Control moved from here to SuggestionBox (not-a-bug)]
Additions:
**Please post recently discovered bugs on the //top// of this page.**---
Deletions:
**Please post recently discovered bugs on the //top// of this page.**
---
====User Control====
Is there an easy way to not allow registration? I would like to have it so that I can control the registration process, not let just anyone sign-up.


Revision [3452]

Edited on 2004-12-18 21:35:29 by BooYa [User Control moved from here to SuggestionBox (not-a-bug)]
Additions:
====User Control====
Is there an easy way to not allow registration? I would like to have it so that I can control the registration process, not let just anyone sign-up.


Revision [3290]

Edited on 2004-12-16 08:09:16 by JavaWoman [reference to WikkaSecureConfig]
Additions:
''I've now written up my thoughts about a [[WikkaSecureConfig more secure way to handle Wikka's configuration]] (which should also provide also more flexibility). --JavaWoman''


Revision [3219]

Edited on 2004-12-15 08:46:45 by JavaWoman [latest to the top]
Additions:
**Please post recently discovered bugs on the //top// of this page.**
Deletions:
Please post recently discovered bugs on the //top// of this page.


Revision [3217]

Edited on 2004-12-15 05:35:20 by DotMG [GetEnv : a security bug]
Additions:
====GetEnv is not a good idea!====
At ./wikka.php, you will see a line %%(php)<?php if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";?>%%
In the most cases, a website is hosted in a machine as a VirtualHost, this means that a number of websites share the same environment variables. If someone knows where your site is hosted, he can put his site at the same server, and use a script containing %%(php)<?php putenv('WAKKA_CONFIG=/home/hacker/config.php');?>%%. And all wikka sites on the same server will use his configuration file. The rest actions to take to hack your site will be as easy as eating sandwich.
Php doc says that an environment variable is altered only during the life of the script, but with my dev Easyphp's on windows, that is false. (I think a "new" environment variable keep its value, even on Linux).
I wanted to make a unique Wikka interface used by 3 sites on the same server. The best secure solution I found is to alter ./wikka.php like this :
%%(php)<?php
if (file_exists("wakka.config.php")) rename("wakka.config.php", "wikka.config.php");
#if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";
if (!$configfile && isset($GLOBALS['wikka_config'])) $configfile = $GLOBALS['wikka_config'];
if (!$configfile) $configfile = "wikka.config.php";
if (file_exists($configfile)) include($configfile);
%%
and put the 2 files sitenumber2.php and .htaccess below at the root of the server number 2:
__sitenumber2.php:__
%%(php)<?php
$GLOBALS['wikka_config'] = "/path/to/altered_config.php";
chdir("/path/to/basewikka");
include('wikka.php');
?>%%
__.htaccess:__
%%<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.*/[^\./]*[^/])$ $1/
RewriteRule ^(css|images|wikiedit2)/(.*)$ /path/to/basewikka/$1/$2 [L]
RewriteRule ^(.*)$ sitenumber2.php?wakka=$1 [QSA,L]
</IfModule>%%
--DotMG


Revision [3199]

Edited on 2004-12-14 22:18:07 by JavaWoman [layout]
Additions:
-looking for help? check the [[WikkaDocumentation Wikka Documentation]]
===Googleform action===
-----
===Problem with "History"??===
Deletions:
-looking for help? check the [[HelpInfo Wikka Documentation]]
==Googleform action==
==Problem with "History"??==


Revision [3197]

Edited on 2004-12-14 21:57:17 by JavaWoman [googleform action]
Additions:
==Googleform action==
The googleform action assumes that "short open tags" can be used for PHP. But this is not the case on every installation and is actually discouraged. If they are indeed disabled (##short_open_tag = Off## in ##php.ini##), the googleform action will not work.
See also http://php.net/manual/en/ini.sect.language-options.php#ini.short-open-tag.
Fix: replace ##<?=$q ?>## by **##<?php echo $q;?>##** in the value attribute of the form (line 14).


Revision [2970]

Edited on 2004-12-08 14:50:08 by DarTar [Minor edit]
Additions:
-looking for help? check the [[HelpInfo Wikka Documentation]]
"" [ (20:46 CEST?) [history?] - TextSearch?phrase=ElVitoWakkaWiki? ? ppp-82-135-6-82.mnet-online.de ]"" which seems kinda wrong. -- Mike (aka GmBowen)
Deletions:
"" [ (20:46 CEST∞) [history∞] - TextSearch?phrase=ElVitoWakkaWiki∞ ⇒ ppp-82-135-6-82.mnet-online.de ]"" which seems kinda wrong. -- Mike (aka GmBowen)


Revision [2941]

Edited on 2004-12-07 22:46:24 by JsnX [MyChanges alphabetical sort fix]
Additions:
Find this line:
%%(php) print("<strong>This is a list of pages you've edited, ordered by the time of your last change (<a href=\"".$this->href("", $tag)."?alphabetically=1\">order alphabetically</a>).</strong><br /><br />\n"); %%
And change it to this:
%%(php) print("<strong>This is a list of pages you've edited, ordered by the time of your last change (<a href=\"".$this->href("", $tag, "alphabetically=1")."\">order alphabetically</a>).</strong><br /><br />\n"); %%
This change will be included in version 1.1.6.0. -- JsnX


Revision [2940]

Edited on 2004-12-07 21:43:09 by ChristianBarthelemy [MyChanges alphabetical sort doesn't work]
Additions:
===MyChanges alphabetical sort doesn't work===
When using MyChanges action and clicking on the "order alphabetically" link the system tries to go at ""http://mywebsite/wikka/wikka.php?wakka=MyChanges?alphabetically=1"" and proposes to create the page. I uploaded again the MyChanges.php action from the current Wikka release (1.1.5.3) without solving anything as it was excatly the same code.
The action ""{{userchanges}}"" works perfectly.
--ChristianBarthelemy


Revision [2858]

Edited on 2004-12-05 14:48:26 by JsnX [fixed apos; thing]
Additions:
''Warning: Compilation failed: nothing to repeat at offset 1 in /.../actions/textsearchexpanded.php on line 33''
Looking at **formatters/wikka.php** to find the cause of the two bugs listed below (found one), I notice to my horror that a **lot** of the regular expressions used there are actually incorrect. They allow such things as using a comma to indent a line (in addition to a tab, or ~, at the start of a line: **demo** in the SandBox, and in the list **below**!), or a comma in a WikiName (even at the start) or in an InterWiki link. That can't have been the intention - it's simply a matter of incorrect RE syntax. I'd become sort of "sensitized" to this phenomenon looking at DarTar's RE on ValidPageNames earlier today - now I see where he found an example (see my comment on that page on his RE!).
,''Note: see also [[,My,Page]] - yup, that's a real page now. ;-)''
Rather than simply fixing all the REs (and other REs all over the place...) I'd like to propose a more fundamental solution:
,-gather all RE used in the Wikka core here (extensions/plugins could have their own set of defines - as long as they don't have conflicting names);
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...
I just stumbled over the fact that the little list of "Useful pages" at the end of the default (installation-generated) ""HomePage"" had incorrect coding: The last list item (li) was not terminated, nor was the list itself (no closing ul tag). It took me a bit of trial and error to reproduce this - but have a look at my test code at the end of SandBox (now). Originally I thought that any list at the end of a page would be unterminated, but that turned out not to be the case. Then I hit on something else: the last list element on that default ""HomePage"" (not the one here) ands with a period. My test version on SandBox now also has the last element ending in a period ... and if you look at the (HTML) page source, you'll see it is indeed an unterminated list. Somehow that ending period (maybe in combination with end-of-page?) causes the Formatter never to close the list; take that ending period away, and it works normally. I tried a few variants, to check whether it might be an odd-even problem, but no: whether the number of list items is odd or even, if the last one ends in a period, the list isn't terminated.
No difference whether it's anordered (ol) or unordered (ul) list, the formatter behaves the same way.
And, BTW, if you look at the preview when editing, the HTML source of the **preview** actually contains a lot of Wiki code that shouldn't be there!
I haven't dug in the Formatter yet to find the cause or whether end-of-page makes a difference...
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.
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.
Please correct me if I'm missing something. -- JsnX 26 Nov 2004
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.
PS: I tried it with the IE. If you block cookies, you can't login.
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
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 "**dan**gerous" - 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?
%% 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
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).
Bugs I've found:
- 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. ''Deeper analysis shows that WikiPage is meant to be uncreated by default, my apologies. WikiName is found on UserSettings (when you don't enter a valid username) and FormattingRules by default.''
- 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?).''
- ''Last known IP or every IP they ever connect from? I'd be willing to store one last known IP per user. '' - JsnX
- ''Last known IP please :) Thanks.'' - Sam
- ''I'd suggest adding *two* distinct fields to ##wikka_users##: Last Login IP/Hostname + Last Login Time'' - DarTar
- ''I was also thinking of a way to ban users directly from the wiki (much in the same way as referrers are added to the blacklist of spammers). This might turn out easier to implement than a //user deleting action// (which was one of the ideas discussed [[UserAdmin here]])'' - DarTar
- ''Yes, this will be implemented at some point.'' - JsnX
- Click the 'Re-edit this old revision' button.
- Click the 'Store' button.
Deletions:
===Entity problem===
Ever since the Unicode rendering buglet was fixed (as near as I can figure) whenever I save code and then re-open the file characters such as the quotation marks are replaced by their codes (e.g., ""'"")...this is true with the /showpagecode handler too....and they're SHOWN as those codes when the page is saved (not as the character). Check out the front page under "download" and you'll see what I mean. Ugh. Crud, it did it in the lines just below too (under Expanded Text Search) (More bizarrely, firefox renders the pages properly (so the codes are switched to the characters in showing, but in the editor now shows the codes....like, I did not write the contraction of the words THEY ARE above with the code but the character....but now it is showing as the code even in the editor in firefox), but IE (6.0.2800.1106) does not and shows the code (um, I cannot write apostrophes etc to SHOW this eh?...this is very awkward to write about) -- GmBowen
''Warning: Compilation failed: nothing to repeat at offset 1 in /.../actions/textsearchexpanded.php on line 33''
Looking at **formatters/wikka.php** to find the cause of the two bugs listed below (found one), I notice to my horror that a **lot** of the regular expressions used there are actually incorrect. They allow such things as using a comma to indent a line (in addition to a tab, or ~, at the start of a line: **demo** in the SandBox, and in the list **below**!), or a comma in a WikiName (even at the start) or in an InterWiki link. That can't have been the intention - it's simply a matter of incorrect RE syntax. I'd become sort of "sensitized" to this phenomenon looking at DarTar's RE on ValidPageNames earlier today - now I see where he found an example (see my comment on that page on his RE!).
,''Note: see also [[,My,Page]] - yup, that's a real page now. ;-)''
Rather than simply fixing all the REs (and other REs all over the place...) I'd like to propose a more fundamental solution:
,-gather all RE used in the Wikka core here (extensions/plugins could have their own set of defines - as long as they don't have conflicting names);
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...
I just stumbled over the fact that the little list of "Useful pages" at the end of the default (installation-generated) ""HomePage"" had incorrect coding: The last list item (li) was not terminated, nor was the list itself (no closing ul tag). It took me a bit of trial and error to reproduce this - but have a look at my test code at the end of SandBox (now). Originally I thought that any list at the end of a page would be unterminated, but that turned out not to be the case. Then I hit on something else: the last list element on that default ""HomePage"" (not the one here) ands with a period. My test version on SandBox now also has the last element ending in a period ... and if you look at the (HTML) page source, you'll see it is indeed an unterminated list. Somehow that ending period (maybe in combination with end-of-page?) causes the Formatter never to close the list; take that ending period away, and it works normally. I tried a few variants, to check whether it might be an odd-even problem, but no: whether the number of list items is odd or even, if the last one ends in a period, the list isn't terminated.
No difference whether it's anordered (ol) or unordered (ul) list, the formatter behaves the same way.
And, BTW, if you look at the preview when editing, the HTML source of the **preview** actually contains a lot of Wiki code that shouldn't be there!
I haven't dug in the Formatter yet to find the cause or whether end-of-page makes a difference...
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.
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.
Please correct me if I'm missing something. -- JsnX 26 Nov 2004
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.
PS: I tried it with the IE. If you block cookies, you can't login.
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
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 "**dan**gerous" - 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?
%% 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
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).
Bugs I've found:
- 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. ''Deeper analysis shows that WikiPage is meant to be uncreated by default, my apologies. WikiName is found on UserSettings (when you don't enter a valid username) and FormattingRules by default.''
- 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?).''
- ''Last known IP or every IP they ever connect from? I'd be willing to store one last known IP per user. '' - JsnX
- ''Last known IP please :) Thanks.'' - Sam
- ''I'd suggest adding *two* distinct fields to ##wikka_users##: Last Login IP/Hostname + Last Login Time'' - DarTar
- ''I was also thinking of a way to ban users directly from the wiki (much in the same way as referrers are added to the blacklist of spammers). This might turn out easier to implement than a //user deleting action// (which was one of the ideas discussed [[UserAdmin here]])'' - DarTar
- ''Yes, this will be implemented at some point.'' - JsnX
- Click the 'Re-edit this old revision' button.
- Click the 'Store' button.


Revision [2857]

Edited on 2004-12-05 14:05:56 by GmBowen [better fix this fast as it affects saves/edits...]
Additions:
Ever since the Unicode rendering buglet was fixed (as near as I can figure) whenever I save code and then re-open the file characters such as the quotation marks are replaced by their codes (e.g., ""'"")...this is true with the /showpagecode handler too....and they're SHOWN as those codes when the page is saved (not as the character). Check out the front page under "download" and you'll see what I mean. Ugh. Crud, it did it in the lines just below too (under Expanded Text Search) (More bizarrely, firefox renders the pages properly (so the codes are switched to the characters in showing, but in the editor now shows the codes....like, I did not write the contraction of the words THEY ARE above with the code but the character....but now it is showing as the code even in the editor in firefox), but IE (6.0.2800.1106) does not and shows the code (um, I cannot write apostrophes etc to SHOW this eh?...this is very awkward to write about) -- GmBowen
Deletions:
Ever since the Unicode rendering buglet was fixed (as near as I can figure) whenever I save code and then re-open the file characters such as the quotation marks are replaced by their codes (e.g., ""'"")...this is true with the /showpagecode handler too....and they're SHOWN as those codes when the page is saved (not as the character). Check out the front page under "download" and you'll see what I mean. Ugh. Crud, it did it in the lines just below too (under Expanded Text Search) (More bizarrely, firefox renders the p