Revision [12542]
This is an old revision of WikkaBugs made by DarTar on 2006-01-05 22:24:47.
Bugs/Issues discovered in Wikka!
New Wikka Tracker available
We are happy to announce that Wikka has just opened a dedicated issue tracker. We are currently migrating open issues, bugs and feature requests from this site to the new server but this migration isn't complete yet.
Meanwhile, if you have something to report:
First check if your issue is already being discussed on this page:
- If so: check if it has a link to a tracker ID:
- If so: follow that link and add your comment there
- If not: add your comment to the issue on this page
- If not: please use the issue tracker to report your new bug or issue.
Thanks for your understanding.
Read this first:
- 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
Bugs reported on the tracker
Spaces in uploaded files
Ticket:46UserSettings for Doubleclick Editing doesn't work
Ticket:3PasswordForgotten / emailpassword problem with Konqueror (Form-Action missing)
Ticket:41Wikiedit: Problem with some date strings
Ticket:74history bug
Ticket:75usersettings.php
Ticket:76Accesskey on comments
Ticket:77Wakka formatter: Indenting on first line
Ticket:13No Registration Wikki
Ticket:79Email deletion after registration
Ticket:47Valid Email Addresses
Ticket:80List parsing bug?
Ticket:13Expanded Text Search fails
Ticket:17passwords containing $ aren't working
Ticket:5Bug in Textsearch (expanded)
Ticket:9WantedPages problem
Ticket:49Retrieving user-information (Session Leakage)
Ticket:81Multiple wikka installations on one host: Login security hole?
Ticket:81Reuse of Username when multiple wikkas on single server
Ticket:81Safari and WikiEdit
Ticket:83Formatter-bug in the comments
Ticket:84Indenting not working properly in handlers/page/edit.php
Ticket:85Missing language-support in the code formatter
Ticket:851.1.6.0beta4: Simplified Chinese (or Unicode relative) in WikiEdit:
Ticket:85Advanced search results reveal confidential info
Ticket:86Recent[ly]Comment[ed|s] actions should check for permission
Ticket:87Accept-Encoding: gzip;q=0, deflate
Ticket:88Error on ./handlers/page/referrers_sites
Ticket:1Windows Paths With {{files}} Action
Ticket:89Yet more formatter bugs
Ticket:34Admin email at installation
Ticket:80Bugs still to be checked/migrated
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.but which is interesting,on your official site of Wikka,there is no this problem with IE blank.is there something wrong with the File permission?(exhausted with it),but when refresh the blank page,it displayed.
- Details like the versions of your IE, your webserver and Mysql (and perhaps a link to the page) would be helpfull! NilsLindenberg
remote (or local) won't load Wikka
I just installed Wikka and it works fine on the localhost.But if I want to access it from another machine, being it on the LAN or internet, I got an error message saying "connection refused when attempting to contact localhost."
my config setting is
"base_url" => "http://localhost/wikka/wikka.php?wakka=",
"rewrite_mode" => "0",
If I change the localhost to mydomain.com, I can access it from internet, but I can't load it on my localhost.
It's one or the other. Is there anything I did wrong?
- Hi, this is a problem that depends on your server configuration and how it resolves virtual hosts. It is in no way a Wikka bug. You should contact your network administrator to address this issue -- DarTar
- I don't think so. I tried MediaWiki and it works fine. I can serve my web pages and that's fine. My server is behind a cable modem and a router. All ports are forwarded correctly. But I really think that the "base_url" syntex caused this problem.
- Since you say you can access your site from the Internet if you use "base_url" => "http://mydomain.com/wikka/wikka.php?wakka=", you could simply edit your hosts file on your local machine and map mydomain.com to 1.0.0.127 - that way you can access the site on your local machine the same way as from the Internet. For accessing it from other machines on your LAN you may need to add a similar mapping (to the hosting machine's local IP address) to access it from there. -- JavaWoman
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 tomNow.. 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...
Wikiedit: Link to the Formatting-rules (using IIS and not using mod-rewrite)
from 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:
by this:
if (substr_count($_SERVER["SERVER_SOFTWARE"],"IIS") > 0) {
~& echo '<SCRIPT>window.location.href = "'.$url.'";</SCRIPT>';
} else {
~& header("Location: ".$url);
}
~& echo '<SCRIPT>window.location.href = "'.$url.'";</SCRIPT>';
} else {
~& header("Location: ".$url);
}
-- MarceloArmonas (sorry, i don't write in english)
Wrong Links
I get Links likehttp://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.
.htaccess settings yields consistent error 403 on Apache
Original issue: running Apache 2.0.54, with the presence of .htaccess file I kept getting error 403. Originally I moved .htaccess and set the base page in the conf to using the long url. After looking around I realized that the fix, in some instances (see requirements below) is to set the option FollowSymLinks to on in your .htaccess file.Problem: your Apache configuration files don't have FollowSymLinks on
Solution: use the .htaccess below IFF (if, and only if) you have the following options set in the configuration file for the directory: AllowOverride Options or AllowOverride All, because you're going to need to override the settings in your local .htaccess file.
### STOP REFERRER SPAM
SetEnvIfNoCase Referer ".*(adultsite|picturesplace|learnthebiz|pi-o|erotica|ghettoinc|port5|bulk-email|camgirls|paris-hilton|modelos|kredit|handyflirt24|versicherung|wwww|erotower|krank|x-1000|flirtnet|blowjob|agedwife|in-the-vip|boysfirsttime|milf|captain-stabbin|tranny|Kontakt|erotik|fetish|frauen|hardcore|fick|krankenversicherung|jinnan-cross|8thstreet|xxx|XXX|ficken|fuck).*" BadReferrer
order deny,allow
deny from env=BadReferrer
<IfModule mod_rewrite.c>
Options +FollowSymLinks
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.*/[^\./]*[^/])$ $1/
RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L]
</IfModule>
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
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
Looking at the generated code, an empty line within a multi-line comment (with line numbers) results in this code:
while an empty line elsewhere results in
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. 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
Purging of pages not always happening
reported by |Sam| on #wikka, writeup by me --JavaWomanPurging 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:
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 -- JavaWomanProblem: 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
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?
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. --BarkerJrAlzheimers 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
Email forgotten password action
I tried with 2 different emails on this site (jsnx.com) to have a temporary password sent to me ('Forgot password?' etc.), and I never received anything. I have the same problem with other wikkas on several servers. Am I crazy, or does this action actually send something which... nobody ever receives? :-( --YanB
- You are crazy. I just tested it... and it worked. *shrug* Does your email server do some sort of spam filtering?? -- JsnX
- I must be crazy then! All the mail servers I use have some sort of spam filtering (who doesn't?), but this kind of 'reminder email' has always gone through these filters. I checked my spam box too. I tried with 2 different emails running on 2 different systems (IOW, I registered with 2 different emails)... And I never received anything with either one. Any idea? --YanB
- JsnX, DarTar must suffer the same illness, then. I tried to retrieve my password, both as DarTar (with admin privs) and DarTar2 (ordinary user). They use different email addresses, none of them received anything from this server. Maybe a problem with the upgrade of this site to version n/a? Or a new security restriction on PHP mail() at JsnX's hoster ? BTW we need to modify the current password retrieval action: redirecting the user to HomePage after submitting his username makes no sense. We need to display a confirmation message or an error message, after the server has tried to send an email. -- DarTar
- I just tested it - one account had an email addres that I'd forgotten was somehow filtered (though server logs show the mail did arrive on the server); email for the other account arrived. And after I changed that filtered email address for the other account, an new attempt got an email for that as well. Doesn't look lik a problem at this server or with 1.1.6.0 to me. --JavaWoman
- Negative... Tried with 2 different emails again, still nothing. (If only this was a joke.) --YanB
- 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
echo "hello world"; // How do you do?
This does not happen if /* */ is used for comments. For example
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)
$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". --JavaWomanWikka 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)
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.
--JavaWomanPHP5 + 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
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 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. 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
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. -- GmBowenDouble-click editing
Ticket:3There 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:
"doubleclickedit" => "Y", # set to "N" to disable double-click editing
and change the proposed line for the show handler above to:
- <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
)
*/
?>
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
Install Note on Basic URL and CSS
First, this may applied to my ISP only. When I installed, I have to usethe ?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
- 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
- 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
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:
-
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:
-
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!
- 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 lineIn 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 . 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
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);
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
$GLOBALS['wikka_config'] = "/path/to/altered_config.php";
chdir("/path/to/basewikka");
include('wikka.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
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.
- 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..
- I'm using a freshly installed copy of Windows XP SP2 with Privacy set to medium--and all other settings are at the defaults--and it works. There must be another cause in your environment beyond having Privacy set to medium. -- JsnX
User search - should be case-sensitive
I was going through user pages, and looked at the homepage by user DaN; clicking on the name does the TextSearch thing: http://wikka.jsnx.com/TextSearch?phrase=DaN which brings up a surprising number of pages, none of which have actually been touched by DaN, it seems (at least non of the ones I checked). Using the browser to search in some of the listed pages (and their revision history) I found hits on words like "dangerous" - and nothing else. This way, the user search feature isn't all that useful, I'm afraid. A whole-word search may be difficult, but could we at least make it (optionally) case-sensitive so that a search for a user name or page name doesn't bring up a host of spurious results?- (That homepage looks at least marginally like spam to me - has DaN done anything else but post a link to an obviously commercial site? Just wondering...)
- -- JavaWoman
- Actually it is really easy to do a whole-word search--just include the item in double quotes. This info can be found at the bottom of the text search page in the Tips section. To address your issue, I added a regular expression to the search function:
-
if (preg_match('/[A-Z]/', $phrase)) $phrase = "\"".$phrase."\"";
- If a capital letter is found in the search phrase, the search phrase will be automatically enclosed in double quotes for you. This seems to fix what you didn't like, but shouldn't cause too much unexpected behaviour for others. Let me know what you think. -- JsnX 27 Nov 2004
CategoryDevelopmentSuggestions