Revision [5179]

This is an old revision of WikkaBugs made by DotMG on 2005-01-25 15:53:43.

 

Bugs/Issues discovered in Wikka!

Last edited by DotMG:
Bug with Accept-Encoding: gzip;q=0, deflate
Tue, 25 Jan 2005 15:53 UTC [diff]

Related pages:
  • for issues related to Wikka layout refer to: WikkaCSS
  • for feature suggestions rather than bugs, go to the SuggestionBox
Attention:
For problems with foreach in PHP version 4.3.10:
See WikkaBugsResolved
 

Please post recently discovered bugs on the top of this page (just below this note).

 


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

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

$_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 ;)
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...'


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


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


GetEnv is not a good idea!

At ./wikka.php, you will see a line
<?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 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
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');
?>

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

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

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


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:



Thanks - Sam




 


CategoryDevelopment
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki