Revision [12545]

This is an old revision of WikkaBugs made by 83.119.39.77 on 2006-01-06 08:35:37.

 

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

Note:
For problems with foreach in PHP version 4.3.10:
See WikkaBugsResolved
 


Bugs reported on the tracker done

Ticket:46

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

history bug

Ticket:75

usersettings.php

Ticket:76

Accesskey on comments

Ticket:77

Wakka formatter: Indenting on first line

Ticket:13

No Registration Wikki

Ticket:79

Email deletion after registration

Ticket:47

Valid Email Addresses

Ticket:80

List parsing bug?

Ticket:13

Expanded Text Search fails

Ticket:17

passwords containing $ aren't working

Ticket:5

Bug in Textsearch (expanded)

Ticket:9

WantedPages problem

Ticket:49

Retrieving user-information (Session Leakage)

Ticket:81

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

Formatter-bug in the comments

Ticket:84

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

Ticket:85

Missing language-support in the code formatter

Ticket:85

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

Ticket:85

Advanced search results reveal confidential info

Ticket:86

Recent[ly]Comment[ed|s] actions should check for permission

Ticket:87

Accept-Encoding: gzip;q=0, deflate

Ticket:88

Error on ./handlers/page/referrers_sites

Ticket:1

Windows Paths With {{files}} Action

Ticket:89

Yet more formatter bugs

Ticket:34

Admin email at installation

Ticket:80

Encoding of GeSHi

See CharsetNotSupportedWorkaround

MySQL issue

Ticket:90

Ticket:91

Login/Logout problem in Windows IIS

Ticket:92

Purging should not remove the whole history of a page

Ticket:93

Installer array_merge()

Ticket:94

Bugs still to be checked/migrated todo 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.


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?


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


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


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



.htaccess settings yields consistent error 403 on Apache

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

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

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

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

order deny,allow
deny from env=BadReferrer

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


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



Code display problem

The following combination of conditions triggers the problem:
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:
<li><div class="de1"><span class="coMULTI"></span></div></li>

while an empty line elsewhere results in
<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


View Code Handler issue

The view code handler does not display any message if the page does not exist. Example -- Rick

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


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


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


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


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


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)


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


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


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.


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


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


Double-click editing

Ticket:3

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:
    "doubleclickedit" => "Y",      # set to "N" to disable double-click editing

and change the proposed line for the show handler above to:
  1. <div class="page" <?php echo (((!$user && $this->config['doubleclickedit'] == "Y") || ($user['doubleclickedit'] == 'Y')) && $this->GetMethod
  2. () == "show") ? "ondblclick=\"document.location='".$this->href("edit")."';\" " : "" ?>>

--JavaWoman


$_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


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


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


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.


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



GetEnv is not a good idea!
I have several users that have trouble staying logged in using ie 6.0.XX.
--GregorLindner





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?




CategoryDevelopmentSuggestions
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki