Revision [3779]

This is an old revision of WikkaBugsResolved made by JavaWoman on 2004-12-28 15:29:07.

 

Resolved bugs


For open Bugs/Issues look at WikkaBugs.
 



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 foreach ($array as $element) ?>
is not correct, and should be replaced by
<?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:
Looks like changing the syntax is only a workaround in case a new Zend version cannot be installed --JavaWoman


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


Feedback Action bug

A bug was preventing the feedback action from working in installs with no rewrite rules. The bug is fixed in WikkaReleaseNotes Wikka 1.1.6.0

original
$form = '<p>Fill in the form below to send us your comments:</p>
        <form method="post" action="'
.$this->tag.'?mail=result">
        Name: <input name="name" value="'
.$_POST["name"].' "type="text" /><br />
        Email: <input name="email" value="'
.$_POST["email"].'" type="text" /><br />
        Comments:<br />
        <textarea name="comments" rows="15" cols="45">'
.$_POST["comments"].'</textarea><br />
        <input type="submit" value="Send" />
        </form>'
;


modified
$form = '<p>Fill in the form below to send us your comments:</p>'.
        $this->FormOpen().
        '\nName: <input name="name" value="'.$_POST["name"].'" type="text" /><br />'.
        '\n<input type="hidden" name="mail" value="result">'.
        '\nEmail: <input name="email" value="'.$_POST["email"].'" type="text" /><br />'.
        '\nComments:<br />\n<textarea name="comments" rows="15" cols="40">'.$_POST["comments"].'</textarea><br / >'.
        '\n<input type="submit" value="Send"/>'.
        $this->FormClose();



original
if ($_GET["mail"]=="result") {



modified
if ($_POST["mail"]=="result") {


-- DarTar, 08 Dec 04



Unicode rendering buglet
See my latest edit in the Sandbox labeled [Unicode bug?] - someone was trying to create a link in Unicode, and I tried a bit more: Unicode characters (Chinese, Korean) are rendered just fine when they occur in plain text; but in a forced link when they occur in the link text they are escaped.
(Just in case the (Korean) example disappears:
Hmmm - SandBox 안되려나 - Unicode rendered in plain text but not for link text (안되려나)? Looks like a bug to me.)
Same problem in comments. (See also SandBox.)
--JavaWoman

Link text was being passed through htmlspecialchars in $wakka->Link to prevent HTML from being inserted into pages through forced links. However, PHP's builtin htmlspecialchars function messes up Unicode.

I've added a custom function to Wikka which performs the same task as htmlspecialchars, but will leave Unicode untouched.

    function htmlspecialchars_unicode($text="")
    {
        $text = preg_replace('/&(?!#[0-9]+;)/s', '&amp;', $text);
        $text = str_replace('<', '&lt;', $text);
        $text = str_replace('>', '&gt;', $text);
        $text = str_replace('"', '&quot;', $text);

        return $text;
    }

-- JsnX



See latest comments on the SandBox page. there was a bit of text with [[]] embedded in the middle of a word; somehow the formatter dropped a lot of source right after that bit (chopping off in the middle of that word) , seemingly picking up only at the next forced link (???) - anyway, a whole lot of content didn't appear at all and there were unclosed tags as well, causing HTML-rendering problems.

Fixed the SandBox page content (for) now, but we should look at what the Formatter does with an "empty forced link" - my guess is it expects (via RE) some content after [[ and only sees a ]] much later as the closing of the forced link. (I haven't looked at the Formatter code yet.)

... later ...

I think I found it. Near the end of formatters/wikka.php we have a preg_replace_callback() call, with a whole range of REs to recognize the things to be acted on. It contains this line (part of the full RE) to match a forced link:
    "\[\[[^\[].*?\]\]|".
- this does indeed expect at least one (not-[) character after the opening two [[; I think this could be replaced with:
    "\[\[[^\[]*?\]\]|".
which would also match an empty set of [[]]. Looking at the portion that actually handles forced links, it looks to me an empty set of [[]] would simply not match the more prcise RE for a forced link there, and thus result in an empty string.

Please test, but I think this would fix it.
--JavaWoman

JavaWoman, this does appear to take care of the described problem without effecting any existing forced links. Thanks for pointing this out. Your suggested fix has been added to Wikka 1.1.6.0. -- JsnX



WikiEdit UTF-8 Bug

I'm actually not sure if this is a Wikka Bug or not, but I'll put it out there. If the Character Set encoding in Internet Explorer 6 is set to Unicode (UTF-8) the Wikiedit Toolbar does not display and a JavaScript Runtime Error occurs on the page. (You have to doubleclick the little yellow exclamation point icon in the bottom left corner to see the actual error message.) If you right click in the page, select encoding, and change the encoding to Western European (ISO), then the Wikiedit Toolbar appears. If I configure the Default CharSet to be iso-8859-1 in my httpd.conf file, then everything works fine. If I set the default charset to be UTF-8, then I get the error. Is this normal behavior with UTF-8 encoding? -- RichardTerry

I think I've fixed this, have a look at http://www.euroburners.org/wikka/wikiedit2/wikiedit2.js I've removed some comments that had non UTF-8 chars in them. --DaveBradshaw

Dave, this does appear to take care of the described problem. Thanks for pointing this out. Your suggested fix has been added to Wikka 1.1.6.0. -- JsnX



Strikethrough rendering

Strikethrough seems to highlight the selected text like this instead of striking through it. Looks like Wikka uses the deletions class from wikka.css instead of the strikethrough class.
.strikethrough {color: #888; text-decoration: line-through;}
.deletions {color: #876; background-color: #FFCC99;}

--RichardTerry

(see new code below)
--NilsLindenberg (no own computer, no installed wikka :(

Marking "a strikethrough" as "deletion" in order to get a certain rendering is just a roundabout way to go back to presentational markup instead of structural, semantic markup! The class should indicate its purpose (i.e., real clasification!); so if the purpose is "strikethrough" rather than "deletion", it should indeed be a separate class. In the CSS you then have the freedom to either style both classes the same, or to style them differently.
See also my remarks about "markup of diff pages" in the SuggestionBox!
-- JavaWoman


Yes, I have read your remarks in the SB. But this is (hopefully, as i can't test it) an easy solution for the problem, as long as it isn't modified towards your suggestions.

The problem is, that there is no handling for "deletion". Instead, "strikethrough" is missused for it. To change this:

change in formaters/wakka.php

static $trigger_inserted = 0;
static $trigger_center = 0;

to
static $trigger_inserted = 0;
static $trigger_deleted = 0;
static $trigger_center = 0;

and

$trigger_bold = $trigger_center = $trigger_floatl = $trigger_inserted = $trigger_italic =$trigger_keys = 0;

to
$trigger_bold = $trigger_center = $trigger_floatl = $trigger_inserted = $trigger_deleted = $trigger_italic =$trigger_keys = 0;

and

// strikethrough
else if ($thing == "++" || $thing == "&yen;&yen;") 
{
 return (++$trigger_strike % 2 ? "<span class=\"deletions\">" : "</span>");
} 

to
// strikethrough
else if ($thing == "++") 
{
return (++$trigger_strike % 2 ? "<span class=\"strikethrough\">" : "</span>");
} 

and add (after //inserted))

// deletions
else if ($thing == "&yen;&yen;") 
{
return (++$trigger_deleted % 2 ? "<span class=\"deletions\">" : "</span>");
} 



Missing Pages
Is there a reason why missing pages are marked through <a href="..."><span class="missingpage">Page name</span></a> instead of <a class="missingpage">Page name</a>? This makes control on hover behavior difficult.
-- DarTar

None that I know of. I made the change. Better now? -- JsnX



  if (event.altKey && !event.ctrlKey) Key=Key+4096;
  if ((event.ctrlKey) && !event.altKey) Key=Key+2048;


Added your suggestion in Wikka 1.1.5.4. Thanks for pointing this out. -- JsnX





I'm being picky here (again!). I've noticed that the double-click edit event is used on the BODY tag. One issue I've experienced is that while entering a comment, I couldn't double-click a word (to highlight and replace it) without triggering the edit screen. My suggestion is to put it on the DIV class="page" tag. -- Sam

Added your suggestion in Wikka 1.1.5.4. Thanks for pointing this out. -- JsnX



Underline in headers
In the category user, there is a header (Wikka User locations:) which is also underlined. But the underlinig does not stop ad the end of the header but goes on for the whole page. NilsLindenberg

 "\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]\S*\b|".  

After the colon it's matching anything not whitespace. Hmm, fine and dandy, but as we see it matches the underscore and things get messed up.
Here's what I changed it to:
 "\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:](?![=_])\S*\b|". 

I'm using negative lookahead to say that I don't want it to match an equal sign or underscore. You guys know I'm dangerous with regular expressions, so if someone can explain to me why this is a bad idea and recommend another solution, I'm listening. However I should note, the interwiki problem is still resolved and the underline problem is fixed also, so it seems successful.


array_merge
Array_merge seems to work different in php5, which leeds to the following error:

array_merge() [function.array-merge]: Argument #2 is not an array in [Wikipath]\wikka.php on line 910

As a comment on http://www.php.net/manual/en/function.array-merge.php points out (01-Nov-2003 01:08 ):

In all PHP 4 versions the above function deals gracefully with paramaters which are NOT arrays(). So if you pass a string or number it will be automagically converted to an one-element array as described in the manual section about Types and "implicit typecasting". So if you ever happen to put an empty/unset variable (NULL value) as parameter, array_merge() will still collapse the other arrays as intended.
PHP4 does not carry if both strings are arrays, but php5 seem to do ("From PHP5beta2 on this behaviour changed, and PHP will correctly issue a E_WARNING message, whenever one of the paramters isn't an array.")

the following change in wikka.php was successfull:
if (file_exists("wakka.config.php"))
{
rename("wakka.config.php", "wikka.config.php");
} else {
$wakkaConfig = array();
} 


Added your suggestion in Wikka 1.1.5.4. Thanks for pointing this out. -- JsnX


Interwiki is broken

Interwiki links are broken if they are not CamelCased, like WikiPedia:Albert_Einstein will not work, but WikiPedia:CamelCase would. Wikipedia heavily relays on FreeLinks, which converts "Albert Einstein" to "Albert_Einstein". --DavidCollantes

There are in fact two causes for this:
  1. the evaluation order in Link() is wrong: it evaluates a WikiName before it evaluates a possible Interwiki link; since a WikiName is a substring of an an Interwiki link, the latter should be matched first;
  1. the RE used to match an Interwiki assumes only WikiNames after the colon; since an Interwiki link actually appends a string to a pre-defined part of a URL, we should allow anything that is allowed in a URL - not just WikiNames.
An extra complication is that the REs used are occuring in three different places - a nice case for using a central "repository" for REs in a set of define() statements rather than having them scattered all over the code!

Without addressing the last issue of the scattered REs, the following changes will fix this problem:
1. wikka.php -- Link() method - change near the start as follows:
<?php
        // is this an interwiki link?
        if (preg_match("/^([A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+)[:](\S*)$/", $tag, $matches))
        {
            $url = $this->GetInterWikiUrl($matches[1], $matches[2]);
        }
        // is this a wiki link?
        elseif (preg_match("/^[A-Za-z0-9]+$/", $tag))
        {
            if ($_SESSION["linktracking"] && $track) $this->TrackLinkTo($tag);
            $linkedPage = $this->LoadPage($tag);
            // return ($linkedPage ? "<a href=\"".$this->Href($method, $linkedPage['tag'])."\">".$text."</a>" : "<span class=\"missingpage\">".$text."</span><a href=\"".$this->Href("edit", $tag)."\" title=\"Create this page\">?</a>");
            return ($linkedPage ? "<a href=\"".$this->Href($method, $linkedPage['tag'])."\" title=\"$title\">".$text."</a>" : "<a href=\"".$this->Href("edit", $tag)."\" title=\"Create this page\"><span class=\"missingpage\">".$text."</span></a>");
        }
        elseif (preg_match("/^(http|https|ftp):\/\/([^\\s\"<>]+)$/", $tag))
        {
            $url = $tag; // this is a vaild external URL
        }
        // is this a full link? ie, does it contain alpha-numeric characters?
?>

2. formatters/wakka.php
2.1 // interwiki links! section - change line that does the matching as follows:
<?php
        else if (preg_match("/^[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]\S*$/s", $thing))

?>

2.2 preg_replace_callback() - change this (near the end):
<?php
    "\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]([A-Z,a-z,0-9,ÄÖÜ,ßäöü]*)\b|".
?>

into this:
<?php
    "\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]\S*\b|".
?>

Explanation: in general (apart from the changed evaluation order - correct in wakka.php but incorrect in wikka.php) we simply allow any character that is not whitespace: somewhat lenient but the allowable characters in a URL is quite a large set and partially dependent on in which part of the URL they occur; allowing simply non-whitespace is a reasonable shortcut, IMO

Note that fix 1. will already work for forced Interwiki links; the two parts of fix 2. are needed as well (both together) to make it work for Interwiki links simply inserted as text (as in David's example).
-- JavaWoman

Fixed in Wikka 1.1.5.4 and above. Thanks for pointing this out. -- JsnX

Password change problem

If spaces are entered on passwords, it does not works and no feedback is given to users. I tried on the "Change Password" part, not on the new user registration. --DavidCollantes

Simple fix:
Around line 96 in actions/usersettings.php change this:
        <?php
        if (isset($error))
        {
            print("<tr><td></td><td><div class=\"error\">".$this->Format($passerror)."</div></td></tr>\n");
        }
        ?>

to this:
        <?php
        if (isset($passerror))
        {
            print("<tr><td></td><td><div class=\"error\">".$this->Format($passerror)."</div></td></tr>\n");
        }
        ?>

-- JavaWoman

Yup. Thanks for pointing this out. Fixed in Wikka 1.1.5.4 and above. -- JsnX


Security bug in UserSettings (minor)
[Moved this back up again and edited since as of 1.1.5.3 it's only half fixed: only one of the assignments has been changed into a comparison operator. Sorry, I should have noticed before]
The file actions/usersettings.php contains a function for a logged in user to change their password; looking at the code, the apparent intention is to verify the user's current password before accepting the new one:
Line 35:
<?php ...
    else if (($user["password"] = md5($_POST["oldpass"])) || ($user["password"] == $_POST["oldpass"]))
?>

Unfortunately, this test always succeeds since it does an assignment instead of a comparison - and since the boolean operator is OR (
) it doesn't matter if the second term is (now) a comparison: just the single assignment in the first term will make it always evaluate as TRUE. This presents a security risk in (semi) public situations where someone might "take over" a logged-in user's account. The code should be corrected as:
<?php ...
    else if (($user["password"] == md5($_POST["oldpass"])) || ($user["password"] == $_POST["oldpass"]))
?>

-- JavaWoman

Fixed in Wikka 1.1.5.4 and above. Thanks for pointing this out. -- JsnX

Code formatters and smart titles
Something dodgy has been done to this site's header.php. The code to extract document titles from the downloaded version is MUCH different from what you are showing here. Take a look at the document titles on HtmlAreaEditing and GmBowen. That's code in there! What's going on? This issue has been addressed in 1.1.5.1 via Mod040fSmartPageTitles. However the regex pattern needs to refined to avoid code samples (e.g. GmBowen)

The issue of code formatters has been adressed in 1.1.5.3 -- DarTar


XHTML not valid
Also in actions/usersettings.php: the state for "on" checkboxes is generated as 'checked'; to be valid XHTML such a boolean attribuet needs to be written as 'checked="checked"'.
JavaWoman

Both bugs are now fixed, and will be in the next release. Thanks! - JsnX



I've discovered a weird sort of bug. When I attempt to create a page whose name contains the string CategoriesExplained, I get a 403 error on wikka.php (no re-writing enabled) when I attempt to preview or store this information. I was trying to create a page named WikiCategoriesExplained on my site (attempting to replace the irritatingly named WikiCategory). I've managed to replicate this bug on this site (click CategoriesExplained here then click Preview. -- Sam
It's not really a Wikka bug. Edit the .htaccess in your root Wikka directory. Remove the word sex from within the line that starts with 'SetEnvIfNoCase'. I've taken care of this for the next release. - JsnX

  • ACLs bug (reproduced here - SdfdsfaSdasd): when you change the read access to "!*" (stop all), the only way to revert this back to "*" is:
    • Give rights to a new user (so ACL for read access says "ban all, but allow access for SdfdsfaSdasd")
    • Save ACL
  • Another ACL bug: you can't changed ownership of a page to Nobody. This may be because of the Not Null aspect of the tables, but frankly, it's quite irritating! I have removed this option from my own installation of acl.php.


2) The WantedPages page uses the linking_to query-string. The character preceding this should be a "?" if URL re-writing is enabled, but a "&" if not. For example, if I use the default wikka.php?wikka=WantedPages?linking_to=TestMe, this will attempt to create a new page. This bug may be already addressed at Mod032bModRewrite, but frankly, I can't understand it.


  • the new tab conversion in the formatters/wakka.php replaces not only four successive space characters with a tab, but any whitespace which a tab itself used to be one. replace the metachar "\s" in the square brackets with a real space like this:
$text = preg_replace("/\n[ ]{4}/", "\n\t", $text);

then program listings with levels indented four and more times will be rendered correctly again.

    • Yup. That's originally how I had it, but then mucked it up for some reason. Resolved in 1.1.4.1. Thanks for pointing it out. -- JsnX


  • Homepage is not CSS valid -- Fixed.

  • Mod_rewrite : I'm waiting for 1.1.4, but This is a bug I found at 1.1.0 : every Rewrite directive in each .htaccess file should be enclosed in <IfModule mod_rewrite.c>, </IfModule>; because if you just add IfModule in ./.htaccess, no image, no js, no css will be downloaded because the server will send an http 500 error. So, what you are saying is that the .htaccess file in the root directory is okay, but I need to add the Ifmodule conditional to the other .htaccess files in the css, image, and wikiedit2 directories as follows? ...
Yes! (You can try to disable mod_rewrite by commenting the corresponding LoadModule in httpd.conf)
More about Mod_rewrite : take a look at FaviconDotIco and RobotsDotTxt [DotMG]
<IfModule mod_rewrite.c>
RewriteEngine off
</IfModule>


Version Wikka Wakka Wiki 1.0.4:
    • Acknowledged. -- JsnX 5/27/04 ..... Fixed in Wikka 1.0.5. -- JsnX 5/29/04


bug in redesigned acl-handling?


am i wrong or does the $wakka->hasaccess routine (v. 1.1.3) only check the user-rights against the present page, regardless if the parameter $tag is set or not? i haven't had a closer look, but as i understood, the check against $this->acls[$privilege."_acl"] only returns the right value, if $tag == $this->tag and else should be passed over to the loadacl-function as wakka did. -- DreckFehler

  • Fixed in 1.1.3.1 and above. -- JsnX



formatters don't care about diff-tags

none of the formatters which are triggered by the %%double-percent tag%% observes the tags that are inserted by the diff-engine, although the main-formatter wakka.php delegates all rendering to these formatters. an example is shown here:

http://wikka.jsnx.com/FeedbackAction/diff?a=828&b=792

just search for "pound" or "++" on that page.

in most cases this issue can be solved by a simple str_replace. an exception is the php-highlighter. see the link below for a solution.

but fixing that problem rises another! i'm unhappy with the "++" tag used by the diff-engine to mark deletions. the double-plus is also the increment operator of php (and other languages) and can't be distiguished from the diff-tags. this problem is addressed in the following sample code too:

http://mindwiki.de/wikka_bug_-_formatters_to_care_about_diff-engine/diff?a=387&b=384

that page might be an example what this bugfix is good for, but it also shows up the limits. naturally the sample-code contains those diff-tags which it is dealing with. that obviously screws up the diff-engine again. so take care not only to paste-n-copy the code snippets from the link above ;)

  • Fixed in 1.1.3.3 and above. -- JsnX

Problem with newpage action
On CreateNewPage...If you click on the button to create a page when there is nothing in the text box you are still taken to a new page asking you if you if you want to edit the new page....the code really needs a check to make sure there is text in the box. -- Mike (aka GmBowen)
It should be:
    <?php
// author: costal martignier
// beschreibung: erstellt eine seite
// parameter: keine
// lizenz: GPL
// email: wakkaactions@martignier.net
// url: http://knowledge.martignier.net

if ($_POST['submitted'] == true && $_POST['pagename'] != '')
{
   $pagename = $_POST['pagename'];
   $url = $this->config['base_url'];
   $this->redirect($url.$pagename."/edit");
}
else
{  
   echo '<br />';
   echo '<form action="" method="post">
        <input type="hidden" name="submitted" value="true" />
        <input type="text" name="pagename" size="50"/>
        <input type="submit" value="Create and Edit" />
     </form>'
;  
}
?>



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