Wikka : WikkaBugsResolved

HomePage :: Categories :: Index :: Changes :: Comments :: Documentation∞ :: Blog∞ :: Login/Register
Most recent edit on 2008-06-24 02:18:34 by NilsLindenberg [archival note]

Additions:
This is an archival page from the earlier time of development. Please use only the Tracker∞ for everything related to bugs or feature requests.

Deletions:
If you have encountered a problem and know of or want to propose a solution, do not post your solution here, but at WikkaBugs where it will be noted and reviewed by the Wikka developers and other Wikka users and may possibly improved or amended: an issue is not "resolved" until the solution has found its way into released or in to-be-released code!
 



Edited on 2008-01-28 00:16:01 by JavaWoman [Modified links pointing to docs server]

Additions:
The bug is fixed in Wikka 1.1.6.0∞

Deletions:
The bug is fixed in Wikka 1.1.6.0


Edited on 2007-12-12 12:20:28 by JavaWoman [preventing unintended wanted pages links]

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

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


Edited on 2007-04-19 13:26:57 by BrianKoontz [Restored]

Additions:

WikiEdit : Ctrl+5 executed twice

When I type Ctrl+4 (h4), the current line is surrounded by === and ===, that's OK. But when I type Ctrl+5 (h5), What I get is ==== and ====, as if I've typed Ctrl+3. On a relatively slow computer, I saw that the WikiEdit engine added == twice. --DotMG I saw the source of the problem : Find the checkKey() prototype in file protoedit.js, and just add "k==53+2048 ||":
ProtoEdit.prototype.checkKey = function (k) {
if (k==85+4096 || k==73+4096 || k==49+2048 || k==50+2048 || k==51+2048 || k==52+2048 || k==53+2048 ||
k==76+4096 || k==76+2048 || k==78+2048 || k==79+2048 || k==66+2048 || k==83+2048 ||

--DotMG

GetCookie() bug

The GetCookie() method in wikka.php does not check whether a named cookie actually exists; this results in a NOTICE and then even partially unstyled pages; this turned up with the (beta) skins feature. (That's why I call a notice a "lurking bug". :))
Fixed already on this site; in wikka.php, change:
  1.     function GetCookie($name) { return $_COOKIE[$name]; }


to:
    function GetCookie($name)
    {
        if (isset($_COOKIE[$name]))
        {
            return $_COOKIE[$name];
        }
        else
        {
            return FALSE;
        }
    }


I've also made corresponding changes to actions/editskin.php, actions/header.php, actions/myskin.php, actions/selectskin.php and actions/skin.php in the beta versions as implemented on this server. (See also WikkaBetaFeatures.) --JavaWoman

Fatal error: Call to a member function on a non-object

moved from SuggestionBox
Received an error msg that was particularly perplexing. Since i wasn't sure where exactly to try and get help for it, i thought i'd post here tho i know it's off topic. NonObjectMemberFunction
PS if there is a better place to have posted this, i'd be happy to know what page that is.
Problems with double double-quote html?
This fix will be in the next version of Wikka; version 1.1.6.0 still has the bug.
See also NonObjectMemberFunction for the original report
Description of the problem
Wikka outputs "Fatal error: Call to a member function on a non-object in /your/full/path/to/wikka/formatters/wakka.php on line 186"
This occurs with the configuration in wikka.config.php double_doublequote_html" => "disabled and trying to view a page where double double-quotes have been used and stored.
Solution
When double_doublequote_html" => "disabled configuration is set, the current version of wikka then refers to the incorrect class when parsing ddq.
FIND in formatters/wakka.php
return $this->htmlspecialchars_ent($matches[1]);

REPLACE WITH
return $wakka->htmlspecialchars_ent($matches[1]);

This statement is never touched as long as double_doublequote_html" =>" is not set to disabled ~&Thanks JavaWoman for your solution, thanks TimoK for trying. --MonstoBrukes ===Googleform action=== The googleform action assumes that "short open tags" can be used for PHP. But this is not the case on every installation and is actually discouraged. If they are indeed disabled (##short_open_tag = Off## in ##php.ini##), the googleform action will not work. See also http://php.net/manual/en/ini.sect.language-options.php#ini.short-open-tag. Fix: replace #### by **####** in the value attribute of the form (line 14). -- JavaWoman ''This change was included in version 1.1.6.0. -- JsnX'' ===MyChanges alphabetical sort doesn't work=== When using MyChanges action and clicking on the "order alphabetically" link the system tries to go at http://mywebsite/wikka/wikka.php?wakka=MyChanges?alphabetically=1"" and proposes to create the page. I uploaded again the MyChanges.php action from the current Wikka release (1.1.5.3) without solving anything as it was excatly the same code.
The action {{userchanges}} works perfectly.
--ChristianBarthelemy
Find this line:
        print("<strong>This is a list of pages you've edited, ordered by the time of your last change (<a href=\"".$this->href("", $tag)."?alphabetically=1\">order alphabetically</a>).</strong><br /><br />\n");   

And change it to this:
        print("<strong>This is a list of pages you've edited, ordered by the time of your last change (<a href=\"".$this->href("", $tag, "alphabetically=1")."\">order alphabetically</a>).</strong><br /><br />\n");   

This change was included in version 1.1.6.0. -- JsnX

check of user-names against page-names

This was added to Wikka in version 1.1.6.0.
New usernames should be checked against existing page names. This was prompted by a new user named 'HomePage'.
For wikka.php:
<?php
    /**
    * Check by name if a page exists.
    *
    * @author        {@link http://wikka.jsnx.com/JavaWoman JavaWoman}
    * @copyright    Copyright © 2004, Marjolein Katsma
    * @license        http://www.gnu.org/copyleft/lesser.html GNU Lesser General Public License
    * @version        1.0
    *
    * @access        public
    * @uses        Wakka::Query()
    *
    * @param        string  $page  page name to check
    * @return        boolean  TRUE if page exists, FALSE otherwise
    */
    function ExistsPage($page)
    {
        $count = 0;
        $query =     "SELECT COUNT(tag)
                    FROM ".$this->config['table_prefix']."pages
                    WHERE tag='".mysql_real_escape_string($page)."'";
        if ($r = $this->Query($query))
        {
            $count = mysql_result($r,0);
            mysql_free_result($r);
        }
        return ($count > 0) ? TRUE : FALSE;
    }
?>

For actions/usersettings.php - insert after line 151:
<?php
        if ($this->ExistsPage($name))
            $error = 'Sorry, this ""WikiName"" is reserved for a page. Please choose a different name';
?>

and change if on the next line to elseif. That should do it, I think. -- JavaWoman
Feedback Action bug
The bug is fixed in Wikka 1.1.6.0
A bug was preventing the feedback action from working in installs with no rewrite rules.
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 - 안되려나 - 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', '&', $text);
        $text = str_replace('<', '<', $text);
        $text = str_replace('>', '>', $text);
        $text = str_replace('"', '"', $text);
        return $text;
    }

-- JsnX
A somewhat different solution was implemented in Wikka 1.1.6.0.
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

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

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 :( 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 == "¥¥") 
{
 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 == "¥¥") 
{
return (++$trigger_deleted % 2 ? "<span class=\"deletions\">" : "</span>");
}

Entering { on French keyboard

When I want to write { with my keyboard, the javascript is supposing I was typing Ctrl+Shift+4, so it encloses the actual line by ===. The same ennoying happens for ~, # and [. [DotMG] Added your suggestion in Wikka 1.1.5.4. Thanks for pointing this out. -- JsnX

Underline in headers

In the CategoryUsers, 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
(This is in UserMap now --JW)
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();
}

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

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

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

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?

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

ACL bugs

ACLs bug (reproduced here - SdfdsfaSdasd): when you change the read access to "!*" (stop all), the only way to revert this back to "*" is: 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.
-- Sam

mod_rewrite and query string

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.
If there is Rewriting on then you must config in wikka.config.php: "base_url" => "http://yourserver/Wikka/", not "base_url" => "http://yourserver/Wikka/wikka.php?wakka=", --BuXul

Tab conversion

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.

Invalid code

Homepage is not CSS valid

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. 
<IfModule mod_rewrite.c>
RewriteEngine off
</IfModule>

Version Wikka Wakka Wiki 1.0.4:
External links 'eat' the closing bracket: (see http://www.cnn.com∞) [MarkHissinkMuller]

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

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

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>';   
}
?>

Older topic

Older topic

Not-a-bug

Mod-rewrite problems

Incorrect onfiguration of rewrite_mode in Wikka causes all sorts of weird problems; Logout problem and Comments don't work are certainly in that class (TextSearch won't work either); the Problem with "History"?? below is most likely in the same class.
While none of these are strictly speaking bugs, the frequency with which such problems are reported (mostly on #wikka these days) indicates that there actually is a problem with how Wikka handles rewrite mode that must be resolved: the Wikka itself needs two parameters to match, and then it still has to match the actual state of mod_rewrite being active as well. We should try to resolve this in the next (after 1.1.6.0) version with the highest priority. --JavaWoman

Logout problem

With Wikka Wakka Wiki 1.1.6.0. Php5
Login.
Go to Preferences/Logout, click the logout button
=> it goes to:
[[mypath]]/wikka.php?wakka=UserSettings?action=logout

So, it tries to find the "UserSettings?action=logout" page, doesn't and propose to create it.
The path should be:
[[mypath]]/wikka.php?wakka=UserSettings&action=logout
same problem
Moved from comment on WikkaBugs: same problem
why when i try to logut i have this page?
I.A.F.S Faq : UserSettings?action=logout LeFaqdiIafs :: Categories :: PageIndex :: RecentChanges :: RecentlyCommented :: Change settings/Logout :: You are CaTo
This page doesn't exist yet. Maybe you want to create it?
-- 213.215.153.30 (2005-03-14 14:02:36) If there is Rewriting on then you must config in wikka.config.php: "base_url" => "http://yourserver/Wikka/", not "base_url" => "http://yourserver/Wikka/wikka.php?wakka=", --BuXul

Comments don't work

I have a Wikka setup very basically at http://www.student.ru.nl/markjansen/Wikka/∞
At the bottom of each page, there's this link [Add comment]. However, this link is wrong.
It points to wikka.php?wakka=HomePage?show_comments=1#comments
It should however point to:
wikka.php?wakka=HomePage&show_comments=1#comments
I tried to fix this by editing the file handlers/page/show.php, but I couldn't figure it out.
Please help me. Thanks!! - TromboneFreakus Yup, this works. Thanks!
-- TromboneFreakus

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)

XML Feed Problem

When clicking on the XML feed link at the bottom of the page - get the following :
XML Parsing Error: xml processing instruction not at start of external entity
Location: http://www.cataclysmos.org/wiki/RecentChanges/recentchanges.xml∞
Line Number 10, Column 1:<?xml version="1.0" encoding="ISO-8859-1"?>
^

Opera and layer

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

Foreach in php version 4.3.10

NOTE: Not a bug!
 
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 The Wikka code base should NOT be changed with respect to foreach usage.
An installation might be temporarily helped with DotMG's workaround, though. This would be needed only if you are faced with an uncooperative hoster who won't provide any of the now-known solutions with respect to accellerator usage! (Maybe you should find a new host. :)) --JavaWoman

Page creation problem (403)

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 here then click Preview. -- Sam CategoryDevelopmentSuggestions CategoryDevelopmentArchive

Deletions:



Edited on 2007-04-19 10:43:52 by 203.145.131.158

Additions:


Deletions:

WikiEdit : Ctrl+5 executed twice

When I type Ctrl+4 (h4), the current line is surrounded by === and ===, that's OK. But when I type Ctrl+5 (h5), What I get is ==== and ====, as if I've typed Ctrl+3. On a relatively slow computer, I saw that the WikiEdit engine added == twice. --DotMG I saw the source of the problem : Find the checkKey() prototype in file protoedit.js, and just add "k==53+2048 ||":
ProtoEdit.prototype.checkKey = function (k) {
if (k==85+4096 || k==73+4096 || k==49+2048 || k==50+2048 || k==51+2048 || k==52+2048 || k==53+2048 ||
k==76+4096 || k==76+2048 || k==78+2048 || k==79+2048 || k==66+2048 || k==83+2048 ||

--DotMG

GetCookie() bug

The GetCookie() method in wikka.php does not check whether a named cookie actually exists; this results in a NOTICE and then even partially unstyled pages; this turned up with the (beta) skins feature. (That's why I call a notice a "lurking bug". :))
Fixed already on this site; in wikka.php, change:
  1.     function GetCookie($name) { return $_COOKIE[$name]; }


to:
    function GetCookie($name)
    {
        if (isset($_COOKIE[$name]))
        {
            return $_COOKIE[$name];
        }
        else
        {
            return FALSE;
        }
    }


I've also made corresponding changes to actions/editskin.php, actions/header.php, actions/myskin.php, actions/selectskin.php and actions/skin.php in the beta versions as implemented on this server. (See also WikkaBetaFeatures.) --JavaWoman

Fatal error: Call to a member function on a non-object

moved from SuggestionBox
Received an error msg that was particularly perplexing. Since i wasn't sure where exactly to try and get help for it, i thought i'd post here tho i know it's off topic. NonObjectMemberFunction
PS if there is a better place to have posted this, i'd be happy to know what page that is.
Problems with double double-quote html?
This fix will be in the next version of Wikka; version 1.1.6.0 still has the bug.
See also NonObjectMemberFunction for the original report
Description of the p