Revision history for WikkaBugsResolved
Additions:
''This is an archival page from the earlier time of development. Please use only the [[http://www.wush.net/trac/wikka Tracker]] for everything related to bugs or feature requests.''
Deletions:
Revision [19436]
Edited on 2008-01-28 00:16:01 by JavaWoman [Modified links pointing to docs server]Additions:
''The bug is fixed in [[Docs:WikkaReleaseNotes Wikka 1.1.6.0]]''
Deletions:
Revision [17825]
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:
Additions:
~& There's a bug in the ##Method()##-method in wikka.php.
~& The calls to ##strstr()## and ##strrpos()## have a wrong order of arguments. I think, it can be a **security issue**, since we have access to arbitrary .php-files on the server. Even user-uploaded ones...
~& See fix below.
~&
~& Change line 795 in wikka.php to
~& %%(php) if (strstr($method,'/')) %%
~& And line 797 to
~& %%(php) $method = substr($method, strrpos($method, '/' )+1); %%
~& -- PhilippAHartmann
===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
~&Confirmed - we'll look into this. --JavaWoman
I saw the source of the problem : Find the checkKey() prototype in file ##protoedit.js##, and just add "##""k==53+2048 ||""##":
%%(javascript)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:
%%(php;599) function GetCookie($name) { return $_COOKIE[$name]; }
%%
---to:
%%(php) 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.
~& How about this page? Btw, annoying people from whom you want help is always a bad idea... --NilsLindenberg
~~& Well, i wasn't sure if it was an actual bug or not. I thought it might be a server config issue on my part and i didn't want to clutter up this here bug page. Also, and this is totally my bad, it didn't really occur to me that it was Easter w'end and that ppl might have actual lives. Thanks to JavaWoman we snapped out a solution on irc and i added it to the page.
==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 ##<?=$q ?>## by **##<?php echo $q;?>##** 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:
%%(php) 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:
%%(php) 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)<?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)<?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 [[WikkaReleaseNotes Wikka 1.1.6.0]]''
A bug was preventing the feedback action from working in installs with no rewrite rules.
**original**
%%(php)
$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**
%%(php)
$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**
%%(php)
if ($_GET["mail"]=="result") {
%%
**modified**
%%(php)
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.
%%(php) 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.''
=== Forced links Formatter bug ===
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: %%(php) "\[\[[^\[].*?\]\]|".%% --- this does indeed expect at least one (not-[) character after the opening two ""[[""; I think this could be replaced with: %%(php) "\[\[[^\[]*?\]\]|".
%% --- 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 misused 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 == "¥¥")
{
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 [. {{colour c="#707070" text="[DotMG]"}}
~&Can you give me some more detail on this one. I'm not sure what you mean or how to replicate the bug. -- JsnX 5/27/04
~&Is anyone else seeing this? -- JsnX 5/29/04
~~&I have a french azerty keyboard, and to type ""{"", I combine keys Alt Gr and 4. But when I try this inside the box, I have my line enclosed with ""==="", as I typed Ctrl + Shift + 4, and the character ""{"" doesn' t appear as expected! It's because of Javascript. {{colour c="#707070" text="[DotMG]"}}
~~~&I'm not encountering any problems with my swedish keyboard. Can use the full range of Alt Gr symbols: @£$?{[]}\. -- JockeAndersson 6/1/04
~~~~&Ok, I corrected it myself. wikiedit2/wikiedit2.js --DotMG: %% 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''
===Underline in headers===
In the Category""""Users, 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//)
~&The problem instigator is the colon on that line. As soon as the colon is removed it works fine. So, the next question is: why is it causing a problem? And the answer is, the formatter sees the colon and thinks we are trying to specify an Interwiki link. If we really trace the problem we find that this can be traced back to JavaWoman! :) Take a look at her suggestions to fix interwiki links on WikkaBugsResolved. Here's the regular expression recommended to match interwiki links: --- %% "\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. --JsnX
==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;
~~2) the RE used to match an Interwiki assumes only [[WikiName]]s 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 [[WikiName]]s.
~&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)<?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)<?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)<?php
"\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]([A-Z,a-z,0-9,ÄÖÜ,ßäöü]*)\b|".
?>%%
into this:
%%(php)<?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)
<?php
if (isset($error))
{
print("<tr><td></td><td><div class=\"error\">".$this->Format($passerror)."</div></td></tr>\n");
}
?>
%%--- to this: %%(php)
<?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)<?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)<?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 (//1.1.5.3//)
===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:
- Give rights to a new user (so ACL for read access says "ban all, but allow access for SdfdsfaSdasd")
- Save ACL
- Edit ACL, deleting SdfdsfaSdasd and the exclamation mark
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.
~&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
===Invalid code===
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 {{colour c="#707070" text="[DotMG]"}}
%%
<IfModule mod_rewrite.c>
RewriteEngine off
</IfModule>
%%
===External links===
Version Wikka Wakka Wiki 1.0.4:
External links 'eat' the closing bracket: (see http://www.cnn.com) {{colour c="#707070" text="[MarkHissinkMuller]"}}
~&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)
<?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===
- There are two related bugs in the productionised code. WikiName and WikiPage need to be created to "complete" the group of default pages. If you can't be bothered to create them, register them in WantedPages by default please.
&Deeper analysis shows that WikiPage is meant to be uncreated by default, my apologies. WikiName is found on UserSettings (when you don't enter a valid username) and FormattingRules by default.
===Older topic===
- I mean, I can't even figure out how to get the file uploader running! Let alone figure out whether it's been implemented! I can see the files.php page, but where does it get executed??
&Oops apparently, it's ""{{files}}"", I'm an idiot! But let's see some documentation for this! Btw, the default uploads directory is not created in installation (is this a security precaution?).
====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%%
~&Looks like mod_rewrite is configured incorrect, please take a look at ModRewrite! --NilsLindenberg
~&Not a bug -- JavaWoman
==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)
~&@213.215.153.30: do you have mod_rewrite enabled? -- NilsLindenberg (2005-03-15 16:04:59)
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
~&look in your wikka.config.php: if you have 'rewrite_mode' => '1', set it to '0'. That should solve the problem? --NilsLindenberg
~&You don't need to edit the handlers, because the "?" vs. "&" option is handled by core functions. Nils' suggestion should work --DarTar
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)
~&I suspect this was caused by a (temporary) configuration problem with rewrite_mode (which will cause odd URLs for TextSearch); none of the changes afterwards show this problem. Classified as not-a-bug. --JavaWoman
===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"?>
^
~& There is whitespace before the xml declaration, which is not allowed as far as I know. Not sure tho **why** it is there. Is that an out-of-the-box wikka 1.1.6.0?
~~& It is standard except for patches applied for UserRegistration and TableAction. I installed a second fresh wikka and it worked OK so I must have broken something.
~~& I found the problem - for the user registration you have to change wikka.config.php - the web based software I was using to edit the file had added some blank lines at the bottom of the config file. What this had to do with XML I am not sure but it works fine now.
===Opera and layer===
(copied from the sandbox --NilsLindenberg)
Opera browser doesn't like a right layer a the end of a page :(
~&A "layer" is nothing but a div; Wikka's "float" boxes are floated divs. When a floated block is longer (vertically) than the section it precedes, it will (vertically) overlap with the next section. This is just standard CSS (the effect isn't limited to Opera either). To prevert this overlap happening at the end of a page (or section), add ""::c::"" at the end of the page (or section), which will create an empty div a with clear: both style. **Not a bug** - just standard CSS for which Wikka markup provides an appropriate mechanism. --JavaWoman
===Foreach in php version 4.3.10===
<<==NOTE: Not a bug!==<<::c::
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)<?php foreach ($array as $element) ?>%% is not correct, and should be replaced by
%%(php)<?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:
~~-http://bugs.php.net/bug.php?id=31134
~~-http://bugs.php.net/bug.php?id=31108 ---("Ran into the same problem with 'foreach' during preliminary testing...---The solution is to ensure that your ZendOptimizer has been upgraded to a minimum of 2.5.7...")
~&Looks like changing the syntax is only a workaround in case a new Zend version cannot be installed --JavaWoman
~~-Please see ForeachBugInPhp4dot3dot10 --DotMG
~&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 cached files will still have the error: the pages must be recompiled.
**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 [[http://wiki.samuelooi.com 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
CategoryDevelopmentSuggestions CategoryDevelopmentArchive
~& The calls to ##strstr()## and ##strrpos()## have a wrong order of arguments. I think, it can be a **security issue**, since we have access to arbitrary .php-files on the server. Even user-uploaded ones...
~& See fix below.
~&
~& Change line 795 in wikka.php to
~& %%(php) if (strstr($method,'/')) %%
~& And line 797 to
~& %%(php) $method = substr($method, strrpos($method, '/' )+1); %%
~& -- PhilippAHartmann
===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
~&Confirmed - we'll look into this. --JavaWoman
I saw the source of the problem : Find the checkKey() prototype in file ##protoedit.js##, and just add "##""k==53+2048 ||""##":
%%(javascript)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:
%%(php;599) function GetCookie($name) { return $_COOKIE[$name]; }
%%
---to:
%%(php) 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.
~& How about this page? Btw, annoying people from whom you want help is always a bad idea... --NilsLindenberg
~~& Well, i wasn't sure if it was an actual bug or not. I thought it might be a server config issue on my part and i didn't want to clutter up this here bug page. Also, and this is totally my bad, it didn't really occur to me that it was Easter w'end and that ppl might have actual lives. Thanks to JavaWoman we snapped out a solution on irc and i added it to the page.
==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 ##<?=$q ?>## by **##<?php echo $q;?>##** 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:
%%(php) 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:
%%(php) 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)<?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)<?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 [[WikkaReleaseNotes Wikka 1.1.6.0]]''
A bug was preventing the feedback action from working in installs with no rewrite rules.
**original**
%%(php)
$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**
%%(php)
$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**
%%(php)
if ($_GET["mail"]=="result") {
%%
**modified**
%%(php)
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.
%%(php) 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.''
=== Forced links Formatter bug ===
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: %%(php) "\[\[[^\[].*?\]\]|".%% --- this does indeed expect at least one (not-[) character after the opening two ""[[""; I think this could be replaced with: %%(php) "\[\[[^\[]*?\]\]|".
%% --- 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 misused 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 == "¥¥")
{
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 [. {{colour c="#707070" text="[DotMG]"}}
~&Can you give me some more detail on this one. I'm not sure what you mean or how to replicate the bug. -- JsnX 5/27/04
~&Is anyone else seeing this? -- JsnX 5/29/04
~~&I have a french azerty keyboard, and to type ""{"", I combine keys Alt Gr and 4. But when I try this inside the box, I have my line enclosed with ""==="", as I typed Ctrl + Shift + 4, and the character ""{"" doesn' t appear as expected! It's because of Javascript. {{colour c="#707070" text="[DotMG]"}}
~~~&I'm not encountering any problems with my swedish keyboard. Can use the full range of Alt Gr symbols: @£$?{[]}\. -- JockeAndersson 6/1/04
~~~~&Ok, I corrected it myself. wikiedit2/wikiedit2.js --DotMG: %% 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''
===Underline in headers===
In the Category""""Users, 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//)
~&The problem instigator is the colon on that line. As soon as the colon is removed it works fine. So, the next question is: why is it causing a problem? And the answer is, the formatter sees the colon and thinks we are trying to specify an Interwiki link. If we really trace the problem we find that this can be traced back to JavaWoman! :) Take a look at her suggestions to fix interwiki links on WikkaBugsResolved. Here's the regular expression recommended to match interwiki links: --- %% "\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. --JsnX
==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;
~~2) the RE used to match an Interwiki assumes only [[WikiName]]s 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 [[WikiName]]s.
~&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)<?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)<?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)<?php
"\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]([A-Z,a-z,0-9,ÄÖÜ,ßäöü]*)\b|".
?>%%
into this:
%%(php)<?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)
<?php
if (isset($error))
{
print("<tr><td></td><td><div class=\"error\">".$this->Format($passerror)."</div></td></tr>\n");
}
?>
%%--- to this: %%(php)
<?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)<?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)<?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 (//1.1.5.3//)
===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:
- Give rights to a new user (so ACL for read access says "ban all, but allow access for SdfdsfaSdasd")
- Save ACL
- Edit ACL, deleting SdfdsfaSdasd and the exclamation mark
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.
~&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
===Invalid code===
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 {{colour c="#707070" text="[DotMG]"}}
%%
<IfModule mod_rewrite.c>
RewriteEngine off
</IfModule>
%%
===External links===
Version Wikka Wakka Wiki 1.0.4:
External links 'eat' the closing bracket: (see http://www.cnn.com) {{colour c="#707070" text="[MarkHissinkMuller]"}}
~&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)
<?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===
- There are two related bugs in the productionised code. WikiName and WikiPage need to be created to "complete" the group of default pages. If you can't be bothered to create them, register them in WantedPages by default please.
&Deeper analysis shows that WikiPage is meant to be uncreated by default, my apologies. WikiName is found on UserSettings (when you don't enter a valid username) and FormattingRules by default.
===Older topic===
- I mean, I can't even figure out how to get the file uploader running! Let alone figure out whether it's been implemented! I can see the files.php page, but where does it get executed??
&Oops apparently, it's ""{{files}}"", I'm an idiot! But let's see some documentation for this! Btw, the default uploads directory is not created in installation (is this a security precaution?).
====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%%
~&Looks like mod_rewrite is configured incorrect, please take a look at ModRewrite! --NilsLindenberg
~&Not a bug -- JavaWoman
==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)
~&@213.215.153.30: do you have mod_rewrite enabled? -- NilsLindenberg (2005-03-15 16:04:59)
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
~&look in your wikka.config.php: if you have 'rewrite_mode' => '1', set it to '0'. That should solve the problem? --NilsLindenberg
~&You don't need to edit the handlers, because the "?" vs. "&" option is handled by core functions. Nils' suggestion should work --DarTar
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)
~&I suspect this was caused by a (temporary) configuration problem with rewrite_mode (which will cause odd URLs for TextSearch); none of the changes afterwards show this problem. Classified as not-a-bug. --JavaWoman
===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"?>
^
~& There is whitespace before the xml declaration, which is not allowed as far as I know. Not sure tho **why** it is there. Is that an out-of-the-box wikka 1.1.6.0?
~~& It is standard except for patches applied for UserRegistration and TableAction. I installed a second fresh wikka and it worked OK so I must have broken something.
~~& I found the problem - for the user registration you have to change wikka.config.php - the web based software I was using to edit the file had added some blank lines at the bottom of the config file. What this had to do with XML I am not sure but it works fine now.
===Opera and layer===
(copied from the sandbox --NilsLindenberg)
Opera browser doesn't like a right layer a the end of a page :(
~&A "layer" is nothing but a div; Wikka's "float" boxes are floated divs. When a floated block is longer (vertically) than the section it precedes, it will (vertically) overlap with the next section. This is just standard CSS (the effect isn't limited to Opera either). To prevert this overlap happening at the end of a page (or section), add ""::c::"" at the end of the page (or section), which will create an empty div a with clear: both style. **Not a bug** - just standard CSS for which Wikka markup provides an appropriate mechanism. --JavaWoman
===Foreach in php version 4.3.10===
<<==NOTE: Not a bug!==<<::c::
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)<?php foreach ($array as $element) ?>%% is not correct, and should be replaced by
%%(php)<?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:
~~-http://bugs.php.net/bug.php?id=31134
~~-http://bugs.php.net/bug.php?id=31108 ---("Ran into the same problem with 'foreach' during preliminary testing...---The solution is to ensure that your ZendOptimizer has been upgraded to a minimum of 2.5.7...")
~&Looks like changing the syntax is only a workaround in case a new Zend version cannot be installed --JavaWoman
~~-Please see ForeachBugInPhp4dot3dot10 --DotMG
~&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 cached files will still have the error: the pages must be recompiled.
**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 [[http://wiki.samuelooi.com 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
CategoryDevelopmentSuggestions CategoryDevelopmentArchive
Deletions:
Additions:
~
Deletions:
~& The calls to ##strstr()## and ##strrpos()## have a wrong order of arguments. I think, it can be a **security issue**, since we have access to arbitrary .php-files on the server. Even user-uploaded ones...
~& See fix below.
~&
~& Change line 795 in wikka.php to
~& %%(php) if (strstr($method,'/')) %%
~& And line 797 to
~& %%(php) $method = substr($method, strrpos($method, '/' )+1); %%
~& -- PhilippAHartmann
===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
~&Confirmed - we'll look into this. --JavaWoman
I saw the source of the problem : Find the checkKey() prototype in file ##protoedit.js##, and just add "##""k==53+2048 ||""##":
%%(javascript)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:
%%(php;599) function GetCookie($name) { return $_COOKIE[$name]; }
%%
---to:
%%(php) 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.
~& How about this page? Btw, annoying people from whom you want help is always a bad idea... --NilsLindenberg
~~& Well, i wasn't sure if it was an actual bug or not. I thought it might be a server config issue on my part and i didn't want to clutter up this here bug page. Also, and this is totally my bad, it didn't really occur to me that it was Easter w'end and that ppl might have actual lives. Thanks to JavaWoman we snapped out a solution on irc and i added it to the page.
==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 ##<?=$q ?>## by **##<?php echo $q;?>##** 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:
%%(php) 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:
%%(php) 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)<?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)<?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 [[WikkaReleaseNotes Wikka 1.1.6.0]]''
A bug was preventing the feedback action from working in installs with no rewrite rules.
**original**
%%(php)
$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**
%%(php)
$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**
%%(php)
if ($_GET["mail"]=="result") {
%%
**modified**
%%(php)
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.
%%(php) 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.''
=== Forced links Formatter bug ===
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: %%(php) "\[\[[^\[].*?\]\]|".%% --- this does indeed expect at least one (not-[) character after the opening two ""[[""; I think this could be replaced with: %%(php) "\[\[[^\[]*?\]\]|".
%% --- 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 misused 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 == "¥¥")
{
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 [. {{colour c="#707070" text="[DotMG]"}}
~&Can you give me some more detail on this one. I'm not sure what you mean or how to replicate the bug. -- JsnX 5/27/04
~&Is anyone else seeing this? -- JsnX 5/29/04
~~&I have a french azerty keyboard, and to type ""{"", I combine keys Alt Gr and 4. But when I try this inside the box, I have my line enclosed with ""==="", as I typed Ctrl + Shift + 4, and the character ""{"" doesn' t appear as expected! It's because of Javascript. {{colour c="#707070" text="[DotMG]"}}
~~~&I'm not encountering any problems with my swedish keyboard. Can use the full range of Alt Gr symbols: @£$?{[]}\. -- JockeAndersson 6/1/04
~~~~&Ok, I corrected it myself. wikiedit2/wikiedit2.js --DotMG: %% 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''
===Underline in headers===
In the Category""""Users, 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//)
~&The problem instigator is the colon on that line. As soon as the colon is removed it works fine. So, the next question is: why is it causing a problem? And the answer is, the formatter sees the colon and thinks we are trying to specify an Interwiki link. If we really trace the problem we find that this can be traced back to JavaWoman! :) Take a look at her suggestions to fix interwiki links on WikkaBugsResolved. Here's the regular expression recommended to match interwiki links: --- %% "\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. --JsnX
==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;
~~2) the RE used to match an Interwiki assumes only [[WikiName]]s 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 [[WikiName]]s.
~&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)<?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)<?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)<?php
"\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]([A-Z,a-z,0-9,ÄÖÜ,ßäöü]*)\b|".
?>%%
into this:
%%(php)<?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)
<?php
if (isset($error))
{
print("<tr><td></td><td><div class=\"error\">".$this->Format($passerror)."</div></td></tr>\n");
}
?>
%%--- to this: %%(php)
<?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)<?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)<?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 (//1.1.5.3//)
===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:
- Give rights to a new user (so ACL for read access says "ban all, but allow access for SdfdsfaSdasd")
- Save ACL
- Edit ACL, deleting SdfdsfaSdasd and the exclamation mark
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.
~&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
===Invalid code===
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 {{colour c="#707070" text="[DotMG]"}}
%%
<IfModule mod_rewrite.c>
RewriteEngine off
</IfModule>
%%
===External links===
Version Wikka Wakka Wiki 1.0.4:
External links 'eat' the closing bracket: (see http://www.cnn.com) {{colour c="#707070" text="[MarkHissinkMuller]"}}
~&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)
<?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===
- There are two related bugs in the productionised code. WikiName and WikiPage need to be created to "complete" the group of default pages. If you can't be bothered to create them, register them in WantedPages by default please.
&Deeper analysis shows that WikiPage is meant to be uncreated by default, my apologies. WikiName is found on UserSettings (when you don't enter a valid username) and FormattingRules by default.
===Older topic===
- I mean, I can't even figure out how to get the file uploader running! Let alone figure out whether it's been implemented! I can see the files.php page, but where does it get executed??
&Oops apparently, it's ""{{files}}"", I'm an idiot! But let's see some documentation for this! Btw, the default uploads directory is not created in installation (is this a security precaution?).
====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%%
~&Looks like mod_rewrite is configured incorrect, please take a look at ModRewrite! --NilsLindenberg
~&Not a bug -- JavaWoman
==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)
~&@213.215.153.30: do you have mod_rewrite enabled? -- NilsLindenberg (2005-03-15 16:04:59)
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
~&look in your wikka.config.php: if you have 'rewrite_mode' => '1', set it to '0'. That should solve the problem? --NilsLindenberg
~&You don't need to edit the handlers, because the "?" vs. "&" option is handled by core functions. Nils' suggestion should work --DarTar
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)
~&I suspect this was caused by a (temporary) configuration problem with rewrite_mode (which will cause odd URLs for TextSearch); none of the changes afterwards show this problem. Classified as not-a-bug. --JavaWoman
===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"?>
^
~& There is whitespace before the xml declaration, which is not allowed as far as I know. Not sure tho **why** it is there. Is that an out-of-the-box wikka 1.1.6.0?
~~& It is standard except for patches applied for UserRegistration and TableAction. I installed a second fresh wikka and it worked OK so I must have broken something.
~~& I found the problem - for the user registration you have to change wikka.config.php - the web based software I was using to edit the file had added some blank lines at the bottom of the config file. What this had to do with XML I am not sure but it works fine now.
===Opera and layer===
(copied from the sandbox --NilsLindenberg)
Opera browser doesn't like a right layer a the end of a page :(
~&A "layer" is nothing but a div; Wikka's "float" boxes are floated divs. When a floated block is longer (vertically) than the section it precedes, it will (vertically) overlap with the next section. This is just standard CSS (the effect isn't limited to Opera either). To prevert this overlap happening at the end of a page (or section), add ""::c::"" at the end of the page (or section), which will create an empty div a with clear: both style. **Not a bug** - just standard CSS for which Wikka markup provides an appropriate mechanism. --JavaWoman
===Foreach in php version 4.3.10===
<<==NOTE: Not a bug!==<<::c::
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)<?php foreach ($array as $element) ?>%% is not correct, and should be replaced by
%%(php)<?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:
~~-http://bugs.php.net/bug.php?id=31134
~~-http://bugs.php.net/bug.php?id=31108 ---("Ran into the same problem with 'foreach' during preliminary testing...---The solution is to ensure that your ZendOptimizer has been upgraded to a minimum of 2.5.7...")
~&Looks like changing the syntax is only a workaround in case a new Zend version cannot be installed --JavaWoman
~~-Please see ForeachBugInPhp4dot3dot10 --DotMG
~&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 cached files will still have the error: the pages must be recompiled.
**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 [[http://wiki.samuelooi.com 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
CategoryDevelopmentSuggestions CategoryDevelopmentArchive
Additions:
===Problem with handlers===
{{svn}}
I noted this problem with handlers. If you specify, for example
http://url/wiki/?wakka=HomePage/../../index
You can trick the include out of the /handlers/page directory. I'm not sure it can be a problem, but indeed it's weird.
--MunehiroYamakawa
~& There's a bug in the ##Method()##-method in wikka.php.
~& The calls to ##strstr()## and ##strrpos()## have a wrong order of arguments. I think, it can be a **security issue**, since we have access to arbitrary .php-files on the server. Even user-uploaded ones...
~& See fix below.
~&
~& Change line 795 in wikka.php to
~& %%(php) if (strstr($method,'/')) %%
~& And line 797 to
~& %%(php) $method = substr($method, strrpos($method, '/' )+1); %%
~& -- PhilippAHartmann
===WikiEdit : Ctrl+5 executed twice===
{{svn}}
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
~&Confirmed - we'll look into this. --JavaWoman
I saw the source of the problem : Find the checkKey() prototype in file ##protoedit.js##, and just add "##""k==53+2048 ||""##":
%%(javascript)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===
{{svn}}
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:
%%(php;599) function GetCookie($name) { return $_COOKIE[$name]; }
---to:
%%(php) 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
{{svn}}
I noted this problem with handlers. If you specify, for example
http://url/wiki/?wakka=HomePage/../../index
You can trick the include out of the /handlers/page directory. I'm not sure it can be a problem, but indeed it's weird.
--MunehiroYamakawa
~& There's a bug in the ##Method()##-method in wikka.php.
~& The calls to ##strstr()## and ##strrpos()## have a wrong order of arguments. I think, it can be a **security issue**, since we have access to arbitrary .php-files on the server. Even user-uploaded ones...
~& See fix below.
~&
~& Change line 795 in wikka.php to
~& %%(php) if (strstr($method,'/')) %%
~& And line 797 to
~& %%(php) $method = substr($method, strrpos($method, '/' )+1); %%
~& -- PhilippAHartmann
===WikiEdit : Ctrl+5 executed twice===
{{svn}}
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
~&Confirmed - we'll look into this. --JavaWoman
I saw the source of the problem : Find the checkKey() prototype in file ##protoedit.js##, and just add "##""k==53+2048 ||""##":
%%(javascript)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===
{{svn}}
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:
%%(php;599) function GetCookie($name) { return $_COOKIE[$name]; }
---to:
%%(php) 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
Additions:
<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>';
$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();
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
<input type="hidden" name="submitted" value="true" />
<input type="text" name="pagename" size="50"/>
<input type="submit" value="Create and Edit" />
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
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>';
$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();
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
<input type="hidden" name="submitted" value="true" />
<input type="text" name="pagename" size="50"/>
<input type="submit" value="Create and Edit" />
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
Deletions:
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>';
$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();
<input type="hidden" name="submitted" value="true" />
<input type="text" name="pagename" size="50"/>
<input type="submit" value="Create and Edit" />
Additions:
>>Elsewhere:
~-For open Bugs/Issues look at WikkaBugs.
~-If you want to //propose// a solution to a known issue, WikkaBugs is also the place.
>>This page is for two types of things:
~1)Issues that have been resolved - meaning that the solution is **in current production code or soon-to-be-released code**;
~1)Issues that have been raised but were classiefied as **"not-a-bug"**
These are to be found in two separate section on this page.
''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!''::c::
~-For open Bugs/Issues look at WikkaBugs.
~-If you want to //propose// a solution to a known issue, WikkaBugs is also the place.
>>This page is for two types of things:
~1)Issues that have been resolved - meaning that the solution is **in current production code or soon-to-be-released code**;
~1)Issues that have been raised but were classiefied as **"not-a-bug"**
These are to be found in two separate section on this page.
''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!''::c::
Deletions:
Deletions:
$body = preg_replace("/\n[ ]{4}/", "\n\t", $body); # @@@ FIXME: misses first line and multiple sets of four spaces - JW 2005-01-16
Working fix (this might not be the best code doing the job...)
// replace each 4 spaces at beginning of a line with a tab
$body = preg_replace("/^[ ]{4}/","\t", $body);
$body = preg_replace("/\n[ ]{4}/","\n\t", $body);
while (preg_match("/\t[ ]{4}/",$body)) {
$body = preg_replace("/\t[ ]{4}/","\t\t", $body);
}
-- TimoK
Revision [9358]
Edited on 2005-06-21 20:26:39 by TimoK [Fix for the fix for wrong indenting in handlers/page/edit.php (should have tested with more than 3 i]Additions:
while (preg_match("/\t[ ]{4}/",$body)) {
$body = preg_replace("/\t[ ]{4}/","\t\t", $body);
}
-- TimoK
$body = preg_replace("/\t[ ]{4}/","\t\t", $body);
}
-- TimoK
Deletions:
-- TimoK
Revision [9355]
Edited on 2005-06-21 20:11:17 by TimoK [Fix for wrong indenting in handlers/page/edit.php]Additions:
=== Identing not working properly in handlers/page/edit.php ===
$body = preg_replace("/\n[ ]{4}/", "\n\t", $body); # @@@ FIXME: misses first line and multiple sets of four spaces - JW 2005-01-16
Working fix (this might not be the best code doing the job...)
// replace each 4 spaces at beginning of a line with a tab
$body = preg_replace("/^[ ]{4}/","\t", $body);
$body = preg_replace("/\n[ ]{4}/","\n\t", $body);
$body = preg_replace("/\t[ ]{4}/","\t\t", $body);
-- TimoK
$body = preg_replace("/\n[ ]{4}/", "\n\t", $body); # @@@ FIXME: misses first line and multiple sets of four spaces - JW 2005-01-16
Working fix (this might not be the best code doing the job...)
// replace each 4 spaces at beginning of a line with a tab
$body = preg_replace("/^[ ]{4}/","\t", $body);
$body = preg_replace("/\n[ ]{4}/","\n\t", $body);
$body = preg_replace("/\t[ ]{4}/","\t\t", $body);
-- TimoK
Revision [9197]
Edited on 2005-06-13 09:45:36 by JavaWoman [aded comments from WikkaBugs to Logout problem]Additions:
==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)
~&@213.215.153.30: do you have mod_rewrite enabled? -- NilsLindenberg (2005-03-15 16:04:59)
//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)
~&@213.215.153.30: do you have mod_rewrite enabled? -- NilsLindenberg (2005-03-15 16:04:59)
Revision [9195]
Edited on 2005-06-13 09:22:08 by JavaWoman [Problem with "History"?? moved to Not-a-bug from WikkaBugs (+ note about mod_rewrite)]Additions:
====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''
===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)
~&I suspect this was caused by a (temporary) configuration problem with rewrite_mode (which will cause odd URLs for TextSearch); none of the changes afterwards show this problem. Classified as not-a-bug. --JavaWoman
''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''
===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)
~&I suspect this was caused by a (temporary) configuration problem with rewrite_mode (which will cause odd URLs for TextSearch); none of the changes afterwards show this problem. Classified as not-a-bug. --JavaWoman
Revision [9193]
Edited on 2005-06-13 09:08:36 by JavaWoman [XML Feed Problem moved to not-a-bug from WikkaBugs]Additions:
===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"?>
^
~& There is whitespace before the xml declaration, which is not allowed as far as I know. Not sure tho **why** it is there. Is that an out-of-the-box wikka 1.1.6.0?
~~& It is standard except for patches applied for UserRegistration and TableAction. I installed a second fresh wikka and it worked OK so I must have broken something.
~~& I found the problem - for the user registration you have to change wikka.config.php - the web based software I was using to edit the file had added some blank lines at the bottom of the config file. What this had to do with XML I am not sure but it works fine now.
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"?>
^
~& There is whitespace before the xml declaration, which is not allowed as far as I know. Not sure tho **why** it is there. Is that an out-of-the-box wikka 1.1.6.0?
~~& It is standard except for patches applied for UserRegistration and TableAction. I installed a second fresh wikka and it worked OK so I must have broken something.
~~& I found the problem - for the user registration you have to change wikka.config.php - the web based software I was using to edit the file had added some blank lines at the bottom of the config file. What this had to do with XML I am not sure but it works fine now.
Revision [9190]
Edited on 2005-06-13 08:37:49 by JavaWoman [integrated moved Problems with double double-quote htm? (from WikkaBugs)]Additions:
//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.
~& How about this page? Btw, annoying people from whom you want help is always a bad idea... --NilsLindenberg
~~& Well, i wasn't sure if it was an actual bug or not. I thought it might be a server config issue on my part and i didn't want to clutter up this here bug page. Also, and this is totally my bad, it didn't really occur to me that it was Easter w'end and that ppl might have actual lives. Thanks to JavaWoman we snapped out a solution on irc and i added it to the page.
==Problems with double double-quote html?==
//See also NonObjectMemberFunction for the original report//
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.
~& How about this page? Btw, annoying people from whom you want help is always a bad idea... --NilsLindenberg
~~& Well, i wasn't sure if it was an actual bug or not. I thought it might be a server config issue on my part and i didn't want to clutter up this here bug page. Also, and this is totally my bad, it didn't really occur to me that it was Easter w'end and that ppl might have actual lives. Thanks to JavaWoman we snapped out a solution on irc and i added it to the page.
==Problems with double double-quote html?==
//See also NonObjectMemberFunction for the original report//
Revision [9189]
Edited on 2005-06-13 08:32:07 by JavaWoman [adding reporter sign to non-object fatal error]Additions:
--MonstoBrukes
Revision [9188]
Edited on 2005-06-13 08:28:38 by JavaWoman [Logiut problem moved here from WikkaBugs]Additions:
===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%%
~&Looks like mod_rewrite is configured incorrect, please take a look at ModRewrite! --NilsLindenberg
~&Not a bug -- JavaWoman
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%%
~&Looks like mod_rewrite is configured incorrect, please take a look at ModRewrite! --NilsLindenberg
~&Not a bug -- JavaWoman
Additions:
CategoryDevelopmentSuggestions CategoryDevelopmentArchive
Deletions:
Additions:
CategoryDevelopmentSuggestions CategoryArchive
Deletions:
Revision [9178]
Edited on 2005-06-13 07:38:47 by JavaWoman [suggestions moved to SuggestionsArchive]Deletions:
===Show comments by default===
//Suggestion//
And isn't it possible to have the comments shown by default for every user?
~&at the moment not. maybe if someone has time... do you mean every registered user, or every user? --NilsLindenberg
~&I don't understand the question. Can you please be more specific? --DarTar
Oops, I thought they didn't show up by default, but it apperently does.
===Translations===
//Suggestion//
And will there be translations?
~&An internalization/localization project is currently under discussion, but it requires a major overhaul of the code, so don't expect it to appear in the very next releases -- DarTar
===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
===Public ownership of pages===
I think defaulting to "Public" ownership would be more beneficial than Nobody. Nobody allows anyone to gain ACL rights to main pages if the proper setup steps are not taken. This is a major security issue and should have been addressed when the "Public" role was created.
~&This is not a security issue within the context of a wiki. Wikis are supposed to be open by design. In addition, admins can change ownership whenever they want. However, personally I agree with your point, and this will be considered for a future release. - JsnX
===Double-click event===
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
Additions:
=====Resolved bugs and not-bugs=====
>>For open Bugs/Issues look at WikkaBugs.>>Issues that either have been resolved (in current production code or soon-to-be-released code) or have been classified as "not-a-bug" can be found on this page in two separate sections.::c::
====Resolved bugs====
''This fix will be in the **next** version of Wikka; version 1.1.6.0 still has the bug.''
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.
When ""double_doublequote_html" => "disabled"" configuration is set, the current version of wikka then refers to the incorrect class when parsing ddq.
This statement is never touched as long as ""double_doublequote_html" =>" is not set to ""disabled""
''This change was included in version 1.1.6.0. -- JsnX''
''This change was included in version 1.1.6.0. -- JsnX''
New usernames should be checked against existing page names. This was prompted by a new user named 'HomePage'.
For **##wikka.php##**:%%(php)<?php
For **##actions/usersettings.php##** - insert after line 151:%%(php)<?php
and change **##if##** on the next line to **##elseif##**. That should do it, I think. -- JavaWoman
''The bug is fixed in [[WikkaReleaseNotes Wikka 1.1.6.0]]''
A bug was preventing the feedback action from working in installs with no rewrite rules.
//Hmmm - [[SandBox 안되려나]] - Unicode rendered in plain text but not for link text (안되려나)? Looks like a bug to me.//)
''A somewhat **different** solution was implemented in Wikka 1.1.6.0.''
=== Forced links Formatter bug ===
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: %%(php) "\[\[[^\[].*?\]\]|".%% --- this does indeed expect at least one (not-[) character after the opening two ""[[""; I think this could be replaced with: %%(php) "\[\[[^\[]*?\]\]|".
%% --- 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.
~&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===
~&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 ===
~&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 misused for it. To change this:
===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 [. {{colour c="#707070" text="[DotMG]"}}
~&Can you give me some more detail on this one. I'm not sure what you mean or how to replicate the bug. -- JsnX 5/27/04
~&Is anyone else seeing this? -- JsnX 5/29/04
~~&I have a french azerty keyboard, and to type ""{"", I combine keys Alt Gr and 4. But when I try this inside the box, I have my line enclosed with ""==="", as I typed Ctrl + Shift + 4, and the character ""{"" doesn' t appear as expected! It's because of Javascript. {{colour c="#707070" text="[DotMG]"}}
~~~&I'm not encountering any problems with my swedish keyboard. Can use the full range of Alt Gr symbols: @£$?{[]}\. -- JockeAndersson 6/1/04
~~~~&Ok, I corrected it myself. wikiedit2/wikiedit2.js --DotMG: %% if (event.altKey && !event.ctrlKey) Key=Key+4096;
''Added your suggestion in Wikka 1.1.5.4. Thanks for pointing this out. -- JsnX''
===Underline in headers===
In the Category""""Users, 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//)
~&The problem instigator is the colon on that line. As soon as the colon is removed it works fine. So, the next question is: why is it causing a problem? And the answer is, the formatter sees the colon and thinks we are trying to specify an Interwiki link. If we really trace the problem we find that this can be traced back to JavaWoman! :) Take a look at her suggestions to fix interwiki links on WikkaBugsResolved. Here's the regular expression recommended to match interwiki links: --- %% "\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. --JsnX
~&Added your suggestion in Wikka 1.1.5.4. Thanks for pointing this out. -- JsnX
~&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;
~~2) the RE used to match an Interwiki assumes only [[WikiName]]s 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 [[WikiName]]s.
~&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:
~&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
~&Simple fix:--- Around line 96 in **##actions/usersettings.php##** change this: %%(php)
%%--- to this: %%(php)
%%--- -- JavaWoman
~~&Yup. Thanks for pointing this out. Fixed in Wikka 1.1.5.4 and above. -- JsnX
===Security bug in UserSettings (minor)===
~&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===
~&Both bugs are now fixed, and will be in the next release. Thanks! - JsnX (//1.1.5.3//)
===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:
- Give rights to a new user (so ACL for read access says "ban all, but allow access for SdfdsfaSdasd")
- Save ACL
- Edit ACL, deleting SdfdsfaSdasd and the exclamation mark
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.
===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.
~&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
===Invalid code===
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 {{colour c="#707070" text="[DotMG]"}}
===External links===
External links 'eat' the closing bracket: (see http://www.cnn.com) {{colour c="#707070" text="[MarkHissinkMuller]"}}
~&Acknowledged. -- JsnX 5/27/04 ..... Fixed in Wikka 1.0.5. -- JsnX 5/29/04
~&Fixed in 1.1.3.1 and above. -- JsnX
~&Fixed in 1.1.3.3 and above. -- JsnX
===Problem with newpage action===
- There are two related bugs in the productionised code. WikiName and WikiPage need to be created to "complete" the group of default pages. If you can't be bothered to create them, register them in WantedPages by default please.
&Deeper analysis shows that WikiPage is meant to be uncreated by default, my apologies. WikiName is found on UserSettings (when you don't enter a valid username) and FormattingRules by default.
- I mean, I can't even figure out how to get the file uploader running! Let alone figure out whether it's been implemented! I can see the files.php page, but where does it get executed??
&Oops apparently, it's ""{{files}}"", I'm an idiot! But let's see some documentation for this! Btw, the default uploads directory is not created in installation (is this a security precaution?).
====Not-a-bug====
~&look in your wikka.config.php: if you have 'rewrite_mode' => '1', set it to '0'. That should solve the problem? --NilsLindenberg
~&You don't need to edit the handlers, because the "?" vs. "&" option is handled by core functions. Nils' suggestion should work --DarTar
-- TromboneFreakus
~&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:
~~-http://bugs.php.net/bug.php?id=31134
~~-http://bugs.php.net/bug.php?id=31108 ---("Ran into the same problem with 'foreach' during preliminary testing...---The solution is to ensure that your ZendOptimizer has been upgraded to a minimum of 2.5.7...")
~&Looks like changing the syntax is only a workaround in case a new Zend version cannot be installed --JavaWoman
~~-Please see ForeachBugInPhp4dot3dot10 --DotMG
~&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 cached files will still have the error: the pages must be recompiled.
~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)===
~&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
====Suggestions====
===Show comments by default===
//Suggestion//
-- TromboneFreakus
~&at the moment not. maybe if someone has time... do you mean every registered user, or every user? --NilsLindenberg
~&I don't understand the question. Can you please be more specific? --DarTar
-- TromboneFreakus
===Translations===
//Suggestion//
-- TromboneFreakus
~&An internalization/localization project is currently under discussion, but it requires a major overhaul of the code, so don't expect it to appear in the very next releases -- DarTar
===Missing Pages===
~&None that I know of. I made the change. Better now? -- JsnX
===Public ownership of pages===
I think defaulting to "Public" ownership would be more beneficial than Nobody. Nobody allows anyone to gain ACL rights to main pages if the proper setup steps are not taken. This is a major security issue and should have been addressed when the "Public" role was created.
~&This is not a security issue within the context of a wiki. Wikis are supposed to be open by design. In addition, admins can change ownership whenever they want. However, personally I agree with your point, and this will be considered for a future release. - JsnX
===Double-click event===
~&Added your suggestion in Wikka 1.1.5.4. Thanks for pointing this out. -- JsnX
>>For open Bugs/Issues look at WikkaBugs.>>Issues that either have been resolved (in current production code or soon-to-be-released code) or have been classified as "not-a-bug" can be found on this page in two separate sections.::c::
====Resolved bugs====
''This fix will be in the **next** version of Wikka; version 1.1.6.0 still has the bug.''
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.
When ""double_doublequote_html" => "disabled"" configuration is set, the current version of wikka then refers to the incorrect class when parsing ddq.
This statement is never touched as long as ""double_doublequote_html" =>" is not set to ""disabled""
''This change was included in version 1.1.6.0. -- JsnX''
''This change was included in version 1.1.6.0. -- JsnX''
New usernames should be checked against existing page names. This was prompted by a new user named 'HomePage'.
For **##wikka.php##**:%%(php)<?php
For **##actions/usersettings.php##** - insert after line 151:%%(php)<?php
and change **##if##** on the next line to **##elseif##**. That should do it, I think. -- JavaWoman
''The bug is fixed in [[WikkaReleaseNotes Wikka 1.1.6.0]]''
A bug was preventing the feedback action from working in installs with no rewrite rules.
//Hmmm - [[SandBox 안되려나]] - Unicode rendered in plain text but not for link text (안되려나)? Looks like a bug to me.//)
''A somewhat **different** solution was implemented in Wikka 1.1.6.0.''
=== Forced links Formatter bug ===
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: %%(php) "\[\[[^\[].*?\]\]|".%% --- this does indeed expect at least one (not-[) character after the opening two ""[[""; I think this could be replaced with: %%(php) "\[\[[^\[]*?\]\]|".
%% --- 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.
~&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===
~&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 ===
~&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 misused for it. To change this:
===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 [. {{colour c="#707070" text="[DotMG]"}}
~&Can you give me some more detail on this one. I'm not sure what you mean or how to replicate the bug. -- JsnX 5/27/04
~&Is anyone else seeing this? -- JsnX 5/29/04
~~&I have a french azerty keyboard, and to type ""{"", I combine keys Alt Gr and 4. But when I try this inside the box, I have my line enclosed with ""==="", as I typed Ctrl + Shift + 4, and the character ""{"" doesn' t appear as expected! It's because of Javascript. {{colour c="#707070" text="[DotMG]"}}
~~~&I'm not encountering any problems with my swedish keyboard. Can use the full range of Alt Gr symbols: @£$?{[]}\. -- JockeAndersson 6/1/04
~~~~&Ok, I corrected it myself. wikiedit2/wikiedit2.js --DotMG: %% if (event.altKey && !event.ctrlKey) Key=Key+4096;
''Added your suggestion in Wikka 1.1.5.4. Thanks for pointing this out. -- JsnX''
===Underline in headers===
In the Category""""Users, 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//)
~&The problem instigator is the colon on that line. As soon as the colon is removed it works fine. So, the next question is: why is it causing a problem? And the answer is, the formatter sees the colon and thinks we are trying to specify an Interwiki link. If we really trace the problem we find that this can be traced back to JavaWoman! :) Take a look at her suggestions to fix interwiki links on WikkaBugsResolved. Here's the regular expression recommended to match interwiki links: --- %% "\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. --JsnX
~&Added your suggestion in Wikka 1.1.5.4. Thanks for pointing this out. -- JsnX
~&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;
~~2) the RE used to match an Interwiki assumes only [[WikiName]]s 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 [[WikiName]]s.
~&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:
~&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
~&Simple fix:--- Around line 96 in **##actions/usersettings.php##** change this: %%(php)
%%--- to this: %%(php)
%%--- -- JavaWoman
~~&Yup. Thanks for pointing this out. Fixed in Wikka 1.1.5.4 and above. -- JsnX
===Security bug in UserSettings (minor)===
~&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===
~&Both bugs are now fixed, and will be in the next release. Thanks! - JsnX (//1.1.5.3//)
===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:
- Give rights to a new user (so ACL for read access says "ban all, but allow access for SdfdsfaSdasd")
- Save ACL
- Edit ACL, deleting SdfdsfaSdasd and the exclamation mark
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.
===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.
~&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
===Invalid code===
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 {{colour c="#707070" text="[DotMG]"}}
===External links===
External links 'eat' the closing bracket: (see http://www.cnn.com) {{colour c="#707070" text="[MarkHissinkMuller]"}}
~&Acknowledged. -- JsnX 5/27/04 ..... Fixed in Wikka 1.0.5. -- JsnX 5/29/04
~&Fixed in 1.1.3.1 and above. -- JsnX
~&Fixed in 1.1.3.3 and above. -- JsnX
===Problem with newpage action===
- There are two related bugs in the productionised code. WikiName and WikiPage need to be created to "complete" the group of default pages. If you can't be bothered to create them, register them in WantedPages by default please.
&Deeper analysis shows that WikiPage is meant to be uncreated by default, my apologies. WikiName is found on UserSettings (when you don't enter a valid username) and FormattingRules by default.
- I mean, I can't even figure out how to get the file uploader running! Let alone figure out whether it's been implemented! I can see the files.php page, but where does it get executed??
&Oops apparently, it's ""{{files}}"", I'm an idiot! But let's see some documentation for this! Btw, the default uploads directory is not created in installation (is this a security precaution?).
====Not-a-bug====
~&look in your wikka.config.php: if you have 'rewrite_mode' => '1', set it to '0'. That should solve the problem? --NilsLindenberg
~&You don't need to edit the handlers, because the "?" vs. "&" option is handled by core functions. Nils' suggestion should work --DarTar
-- TromboneFreakus
~&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:
~~-http://bugs.php.net/bug.php?id=31134
~~-http://bugs.php.net/bug.php?id=31108 ---("Ran into the same problem with 'foreach' during preliminary testing...---The solution is to ensure that your ZendOptimizer has been upgraded to a minimum of 2.5.7...")
~&Looks like changing the syntax is only a workaround in case a new Zend version cannot be installed --JavaWoman
~~-Please see ForeachBugInPhp4dot3dot10 --DotMG
~&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 cached files will still have the error: the pages must be recompiled.
~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)===
~&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
====Suggestions====
===Show comments by default===
//Suggestion//
-- TromboneFreakus
~&at the moment not. maybe if someone has time... do you mean every registered user, or every user? --NilsLindenberg
~&I don't understand the question. Can you please be more specific? --DarTar
-- TromboneFreakus
===Translations===
//Suggestion//
-- TromboneFreakus
~&An internalization/localization project is currently under discussion, but it requires a major overhaul of the code, so don't expect it to appear in the very next releases -- DarTar
===Missing Pages===
~&None that I know of. I made the change. Better now? -- JsnX
===Public ownership of pages===
I think defaulting to "Public" ownership would be more beneficial than Nobody. Nobody allows anyone to gain ACL rights to main pages if the proper setup steps are not taken. This is a major security issue and should have been addressed when the "Public" role was created.
~&This is not a security issue within the context of a wiki. Wikis are supposed to be open by design. In addition, admins can change ownership whenever they want. However, personally I agree with your point, and this will be considered for a future release. - JsnX
===Double-click event===
~&Added your suggestion in Wikka 1.1.5.4. Thanks for pointing this out. -- JsnX
Deletions:
<<For open Bugs/Issues look at WikkaBugs.<< ::c::
//No Bug//
//Note: this fix will be in the **next** version of Wikka; version 1.1.6.0 still has the bug.//
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.
When ''"double_doublequote_html" => "disabled"'' configuration is set, the current version of wikka then refers to the incorrect class when parsing ddq.
This statement is never touched as long as ''"double_doublequote_html" =>'' is not set to ''"disabled"''
- There are two related bugs in the productionised code. WikiName and WikiPage need to be created to "complete" the group of default pages. If you can't be bothered to create them, register them in WantedPages by default please. ''Deeper analysis shows that WikiPage is meant to be uncreated by default, my apologies. WikiName is found on UserSettings (when you don't enter a valid username) and FormattingRules by default.''
- I mean, I can't even figure out how to get the file uploader running! Let alone figure out whether it's been implemented! I can see the files.php page, but where does it get executed?? ''Oops apparently, it's ""{{files}}"", I'm an idiot! But let's see some documentation for this! Btw, the default uploads directory is not created in installation (is this a security precaution?).''
This change will be included in version 1.1.6.0. -- JsnX
This change will be included in version 1.1.6.0. -- JsnX
- New usernames should be checked against existing page names. This was prompted by a new user named 'HomePage'.
~For **##wikka.php##**:%%(php)<?php
~For **##actions/usersettings.php##** - insert after line 151:%%(php)<?php
~ and change **##if##** on the next line to **##elseif##**. That should do it, I think. -- JavaWoman
''look in your wikka.config.php: if you have 'rewrite_mode' => '1', set it to '0'. That should solve the problem?'' --NilsLindenberg
''You don't need to edit the handlers, because the "?" vs. "&" option is handled by core functions. Nils' suggestion should work '' --DarTar
''at the moment not. maybe if someone has time... do you mean every registered user, or every user? '' --NilsLindenberg
''I don't understand the question. Can you please be more specific? '' --DarTar
''An internalization/localization project is currently under discussion, but it requires a major overhaul of the code, so don't expect it to appear in the very next releases'' -- DarTar
''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:
~-http://bugs.php.net/bug.php?id=31134
~-http://bugs.php.net/bug.php?id=31108 ---("Ran into the same problem with 'foreach' during preliminary testing...---The solution is to ensure that your ZendOptimizer has been upgraded to a minimum of 2.5.7...")
Looks like changing the syntax is only a workaround in case a new Zend version cannot be installed --JavaWoman''
~-Please see ForeachBugInPhp4dot3dot10 --DotMG
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 cached files will still have the error: the pages must be recompiled.
~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. :))
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]]
''Hmmm - [[SandBox 안되려나]] - Unicode rendered in plain text but not for link text (안되려나)? Looks like a bug to me.'')
== Forced links Formatter bug ==
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: %%(php) "\[\[[^\[].*?\]\]|".%% - this does indeed expect at least one (not-[) character after the opening two ""[[""; I think this could be replaced with: %%(php) "\[\[[^\[]*?\]\]|".
%% 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.
''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==
''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 ==
''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:
== Missing Pages ==
None that I know of. I made the change. Better now? -- JsnX
- 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 [. {{colour c="#707070" text="[DotMG]"}}
- ''//Can you give me some more detail on this one. I'm not sure what you mean or how to replicate the bug. -- JsnX 5/27/04//''
- Is anyone else seeing this? -- JsnX 5/29/04
- //I have a french azerty keyboard, and to type ""{"", I combine keys Alt Gr and 4. But when I try this inside the box, I have my line enclosed with ""==="", as I typed Ctrl + Shift + 4, and the character ""{"" doesn' t appear as expected! It's because of Javascript.//{{colour c="#707070" text="[DotMG]"}}
- I'm not encountering any problems with my swedish keyboard. Can use the full range of Alt Gr symbols: @£$?{[]}\. -- JockeAndersson 6/1/04
- //Ok, I corrected it myself. wikiedit2/wikiedit2.js --DotMG//:
%% if (event.altKey && !event.ctrlKey) Key=Key+4096;
''Added your suggestion in Wikka 1.1.5.4. Thanks for pointing this out.'' -- JsnX
- I think defaulting to "Public" ownership would be more beneficial than Nobody. Nobody allows anyone to gain ACL rights to main pages if the proper setup steps are not taken. This is a major security issue and should have been addressed when the "Public" role was created.
- ''This is not a security issue within the context of a wiki. Wikis are supposed to be open by design. In addition, admins can change ownership whenever they want. However, personally I agree with your point, and this will be considered for a future release. '' - JsnX
''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
- The problem instigator is the colon on that line. As soon as the colon is removed it works fine. So, the next question is: why is it causing a problem? And the answer is, the formatter sees the colon and thinks we are trying to specify an Interwiki link. If we really trace the problem we find that this can be traced back to JavaWoman! :) Take a look at her suggestions to fix interwiki links on WikkaBugsResolved. Here's the regular expression recommended to match interwiki links: ---
%% "\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.
''Added your suggestion in Wikka 1.1.5.4. Thanks for pointing this out.'' -- JsnX
''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;
~2) the RE used to match an Interwiki assumes only [[WikiName]]s 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 [[WikiName]]s.
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:
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
''Simple fix:
Around line 96 in **##actions/usersettings.php##** change this:
to this:
%%''
''Yup. Thanks for pointing this out. Fixed in Wikka 1.1.5.4 and above.'' -- JsnX
==Security bug in UserSettings (minor)==
''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==
Both bugs are now fixed, and will be in the next release. Thanks! - JsnX
'' 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
- Edit ACL, deleting SdfdsfaSdasd and the exclamation mark
- 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 {{colour c="#707070" text="[DotMG]"}}
- External links 'eat' the closing bracket: (see http://www.cnn.com) {{colour c="#707070" text="[MarkHissinkMuller]"}}
- ''//Acknowledged. -- JsnX 5/27/04 ..... Fixed in Wikka 1.0.5. -- JsnX 5/29/04//''
- Fixed in 1.1.3.1 and above. -- JsnX
- Fixed in 1.1.3.3 and above. -- JsnX
==Problem with newpage action==
Additions:
CategoryDevelopmentSuggestions
Deletions:
Additions:
//No Bug//
===Opera and layer===
(copied from the sandbox --NilsLindenberg)
Opera browser doesn't like a right layer a the end of a page :(
~&A "layer" is nothing but a div; Wikka's "float" boxes are floated divs. When a floated block is longer (vertically) than the section it precedes, it will (vertically) overlap with the next section. This is just standard CSS (the effect isn't limited to Opera either). To prevert this overlap happening at the end of a page (or section), add ""::c::"" at the end of the page (or section), which will create an empty div a with clear: both style. **Not a bug** - just standard CSS for which Wikka markup provides an appropriate mechanism. --JavaWoman
===Opera and layer===
(copied from the sandbox --NilsLindenberg)
Opera browser doesn't like a right layer a the end of a page :(
~&A "layer" is nothing but a div; Wikka's "float" boxes are floated divs. When a floated block is longer (vertically) than the section it precedes, it will (vertically) overlap with the next section. This is just standard CSS (the effect isn't limited to Opera either). To prevert this overlap happening at the end of a page (or section), add ""::c::"" at the end of the page (or section), which will create an empty div a with clear: both style. **Not a bug** - just standard CSS for which Wikka markup provides an appropriate mechanism. --JavaWoman
Revision [7045]
Edited on 2005-04-01 08:51:09 by JavaWoman [correction to solution for 'non-object' bug]No Differences
Revision [7044]
Edited on 2005-04-01 08:50:19 by JavaWoman [clarification about 'non-object' bug solution]Additions:
//Note: this fix will be in the **next** version of Wikka; version 1.1.6.0 still has the bug.//
Revision [7023]
Edited on 2005-03-31 00:16:24 by MonstoBrukes [clarification about 'non-object' bug solution]Additions:
=====Resolved bugs=====
<<For open Bugs/Issues look at WikkaBugs.<< ::c::
----
=== Fatal error: Call to a member function on a non-object ===
==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 $wakka->htmlspecialchars_ent($matches[1]);%%
**REPLACE WITH**
%%return $this->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.
----
===Older topic===
- There are two related bugs in the productionised code. WikiName and WikiPage need to be created to "complete" the group of default pages. If you can't be bothered to create them, register them in WantedPages by default please. ''Deeper analysis shows that WikiPage is meant to be uncreated by default, my apologies. WikiName is found on UserSettings (when you don't enter a valid username) and FormattingRules by default.''
- I mean, I can't even figure out how to get the file uploader running! Let alone figure out whether it's been implemented! I can see the files.php page, but where does it get executed?? ''Oops apparently, it's ""{{files}}"", I'm an idiot! But let's see some documentation for this! Btw, the default uploads directory is not created in installation (is this a security precaution?).''
----
===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 ##<?=$q ?>## by **##<?php echo $q;?>##** in the value attribute of the form (line 14).
-- JavaWoman
This change will be 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:
%%(php) 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:
%%(php) 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 will be 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)<?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)<?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
===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.
''look in your wikka.config.php: if you have 'rewrite_mode' => '1', set it to '0'. That should solve the problem?'' --NilsLindenberg
''You don't need to edit the handlers, because the "?" vs. "&" option is handled by core functions. Nils' suggestion should work '' --DarTar
Yup, this works. Thanks!
And isn't it possible to have the comments shown by default for every user?
''at the moment not. maybe if someone has time... do you mean every registered user, or every user? '' --NilsLindenberg
''I don't understand the question. Can you please be more specific? '' --DarTar
Oops, I thought they didn't show up by default, but it apperently does.
And will there be translations?
''An internalization/localization project is currently under discussion, but it requires a major overhaul of the code, so don't expect it to appear in the very next releases'' -- DarTar
Please help me. Thanks!! - TromboneFreakus
===Foreach in php version 4.3.10===
<<==NOTE: Not a bug!==<<::c::
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)<?php foreach ($array as $element) ?>%% is not correct, and should be replaced by
%%(php)<?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:
~-http://bugs.php.net/bug.php?id=31134
~-http://bugs.php.net/bug.php?id=31108 ---("Ran into the same problem with 'foreach' during preliminary testing...---The solution is to ensure that your ZendOptimizer has been upgraded to a minimum of 2.5.7...")
Looks like changing the syntax is only a workaround in case a new Zend version cannot be installed --JavaWoman''
~-Please see ForeachBugInPhp4dot3dot10 --DotMG
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 cached files will still have the error: the pages must be recompiled.
**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
----
== 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**
%%(php)
$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**
%%(php)
$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**
%%(php)
if ($_GET["mail"]=="result") {
%%
**modified**
%%(php)
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.
%%(php) 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
----
== Forced links Formatter bug ==
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: %%(php) "\[\[[^\[].*?\]\]|".%% - this does indeed expect at least one (not-[) character after the opening two ""[[""; I think this could be replaced with: %%(php) "\[\[[^\[]*?\]\]|".
%% 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 == "¥¥")
{
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>");
}
%%
----
== 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
----
- 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 [. {{colour c="#707070" text="[DotMG]"}}
- ''//Can you give me some more detail on this one. I'm not sure what you mean or how to replicate the bug. -- JsnX 5/27/04//''
- Is anyone else seeing this? -- JsnX 5/29/04
- //I have a french azerty keyboard, and to type ""{"", I combine keys Alt Gr and 4. But when I try this inside the box, I have my line enclosed with ""==="", as I typed Ctrl + Shift + 4, and the character ""{"" doesn' t appear as expected! It's because of Javascript.//{{colour c="#707070" text="[DotMG]"}}
- I'm not encountering any problems with my swedish keyboard. Can use the full range of Alt Gr symbols: @£$?{[]}\. -- JockeAndersson 6/1/04
- //Ok, I corrected it myself. wikiedit2/wikiedit2.js --DotMG//:
%% 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 think defaulting to "Public" ownership would be more beneficial than Nobody. Nobody allows anyone to gain ACL rights to main pages if the proper setup steps are not taken. This is a major security issue and should have been addressed when the "Public" role was created.
- ''This is not a security issue within the context of a wiki. Wikis are supposed to be open by design. In addition, admins can change ownership whenever they want. However, personally I agree with your point, and this will be considered for a future release. '' - 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
- The problem instigator is the colon on that line. As soon as the colon is removed it works fine. So, the next question is: why is it causing a problem? And the answer is, the formatter sees the colon and thinks we are trying to specify an Interwiki link. If we really trace the problem we find that this can be traced back to JavaWoman! :) Take a look at her suggestions to fix interwiki links on WikkaBugsResolved. Here's the regular expression recommended to match interwiki links: ---
%% "\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;
~2) the RE used to match an Interwiki assumes only [[WikiName]]s 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 [[WikiName]]s.
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)<?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)<?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)<?php
"\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]([A-Z,a-z,0-9,ÄÖÜ,ßäöü]*)\b|".
?>%%
into this:
%%(php)<?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)
<?php
if (isset($error))
{
print("<tr><td></td><td><div class=\"error\">".$this->Format($passerror)."</div></td></tr>\n");
}
?>
%%
to this:
%%(php)
<?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)<?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)<?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 [[http://wiki.samuelooi.com 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
- Edit ACL, deleting SdfdsfaSdasd and the exclamation mark
- 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 {{colour c="#707070" text="[DotMG]"}}
%%
<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) {{colour c="#707070" text="[MarkHissinkMuller]"}}
- ''//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)
<?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>';
}
?>
%%
----
<<For open Bugs/Issues look at WikkaBugs.<< ::c::
----
=== Fatal error: Call to a member function on a non-object ===
==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 $wakka->htmlspecialchars_ent($matches[1]);%%
**REPLACE WITH**
%%return $this->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.
----
===Older topic===
- There are two related bugs in the productionised code. WikiName and WikiPage need to be created to "complete" the group of default pages. If you can't be bothered to create them, register them in WantedPages by default please. ''Deeper analysis shows that WikiPage is meant to be uncreated by default, my apologies. WikiName is found on UserSettings (when you don't enter a valid username) and FormattingRules by default.''
- I mean, I can't even figure out how to get the file uploader running! Let alone figure out whether it's been implemented! I can see the files.php page, but where does it get executed?? ''Oops apparently, it's ""{{files}}"", I'm an idiot! But let's see some documentation for this! Btw, the default uploads directory is not created in installation (is this a security precaution?).''
----
===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 ##<?=$q ?>## by **##<?php echo $q;?>##** in the value attribute of the form (line 14).
-- JavaWoman
This change will be 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:
%%(php) 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:
%%(php) 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 will be 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)<?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)<?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
===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.
''look in your wikka.config.php: if you have 'rewrite_mode' => '1', set it to '0'. That should solve the problem?'' --NilsLindenberg
''You don't need to edit the handlers, because the "?" vs. "&" option is handled by core functions. Nils' suggestion should work '' --DarTar
Yup, this works. Thanks!
And isn't it possible to have the comments shown by default for every user?
''at the moment not. maybe if someone has time... do you mean every registered user, or every user? '' --NilsLindenberg
''I don't understand the question. Can you please be more specific? '' --DarTar
Oops, I thought they didn't show up by default, but it apperently does.
And will there be translations?
''An internalization/localization project is currently under discussion, but it requires a major overhaul of the code, so don't expect it to appear in the very next releases'' -- DarTar
Please help me. Thanks!! - TromboneFreakus
===Foreach in php version 4.3.10===
<<==NOTE: Not a bug!==<<::c::
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)<?php foreach ($array as $element) ?>%% is not correct, and should be replaced by
%%(php)<?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:
~-http://bugs.php.net/bug.php?id=31134
~-http://bugs.php.net/bug.php?id=31108 ---("Ran into the same problem with 'foreach' during preliminary testing...---The solution is to ensure that your ZendOptimizer has been upgraded to a minimum of 2.5.7...")
Looks like changing the syntax is only a workaround in case a new Zend version cannot be installed --JavaWoman''
~-Please see ForeachBugInPhp4dot3dot10 --DotMG
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 cached files will still have the error: the pages must be recompiled.
**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
----
== 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**
%%(php)
$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**
%%(php)
$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**
%%(php)
if ($_GET["mail"]=="result") {
%%
**modified**
%%(php)
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.
%%(php) 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
----
== Forced links Formatter bug ==
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: %%(php) "\[\[[^\[].*?\]\]|".%% - this does indeed expect at least one (not-[) character after the opening two ""[[""; I think this could be replaced with: %%(php) "\[\[[^\[]*?\]\]|".
%% 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 == "¥¥")
{
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>");
}
%%
----
== 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
----
- 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 [. {{colour c="#707070" text="[DotMG]"}}
- ''//Can you give me some more detail on this one. I'm not sure what you mean or how to replicate the bug. -- JsnX 5/27/04//''
- Is anyone else seeing this? -- JsnX 5/29/04
- //I have a french azerty keyboard, and to type ""{"", I combine keys Alt Gr and 4. But when I try this inside the box, I have my line enclosed with ""==="", as I typed Ctrl + Shift + 4, and the character ""{"" doesn' t appear as expected! It's because of Javascript.//{{colour c="#707070" text="[DotMG]"}}
- I'm not encountering any problems with my swedish keyboard. Can use the full range of Alt Gr symbols: @£$?{[]}\. -- JockeAndersson 6/1/04
- //Ok, I corrected it myself. wikiedit2/wikiedit2.js --DotMG//:
%% 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 think defaulting to "Public" ownership would be more beneficial than Nobody. Nobody allows anyone to gain ACL rights to main pages if the proper setup steps are not taken. This is a major security issue and should have been addressed when the "Public" role was created.
- ''This is not a security issue within the context of a wiki. Wikis are supposed to be open by design. In addition, admins can change ownership whenever they want. However, personally I agree with your point, and this will be considered for a future release. '' - 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
- The problem instigator is the colon on that line. As soon as the colon is removed it works fine. So, the next question is: why is it causing a problem? And the answer is, the formatter sees the colon and thinks we are trying to specify an Interwiki link. If we really trace the problem we find that this can be traced back to JavaWoman! :) Take a look at her suggestions to fix interwiki links on WikkaBugsResolved. Here's the regular expression recommended to match interwiki links: ---
%% "\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;
~2) the RE used to match an Interwiki assumes only [[WikiName]]s 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 [[WikiName]]s.
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)<?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)<?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)<?php
"\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]([A-Z,a-z,0-9,ÄÖÜ,ßäöü]*)\b|".
?>%%
into this:
%%(php)<?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)
<?php
if (isset($error))
{
print("<tr><td></td><td><div class=\"error\">".$this->Format($passerror)."</div></td></tr>\n");
}
?>
%%
to this:
%%(php)
<?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)<?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)<?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 [[http://wiki.samuelooi.com 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
- Edit ACL, deleting SdfdsfaSdasd and the exclamation mark
- 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 {{colour c="#707070" text="[DotMG]"}}
%%
<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) {{colour c="#707070" text="[MarkHissinkMuller]"}}
- ''//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)
<?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>';
}
?>
%%
----
Deletions:
<<For open Bugs/Issues look at WikkaBugs.<< ::c::
----
===Older topic===
- There are two related bugs in the productionised code. WikiName and WikiPage need to be created to "complete" the group of default pages. If you can't be bothered to create them, register them in WantedPages by default please. ''Deeper analysis shows that WikiPage is meant to be uncreated by default, my apologies. WikiName is found on UserSettings (when you don't enter a valid username) and FormattingRules by default.''
- I mean, I can't even figure out how to get the file uploader running! Let alone figure out whether it's been implemented! I can see the files.php page, but where does it get executed?? ''Oops apparently, it's ""{{files}}"", I'm an idiot! But let's see some documentation for this! Btw, the default uploads directory is not created in installation (is this a security precaution?).''
----
===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 ##<?=$q ?>## by **##<?php echo $q;?>##** in the value attribute of the form (line 14).
-- JavaWoman
This change will be 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:
%%(php) 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:
%%(php) 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 will be 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)<?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)<?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
===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.
''look in your wikka.config.php: if you have 'rewrite_mode' => '1', set it to '0'. That should solve the problem?'' --NilsLindenberg
''You don't need to edit the handlers, because the "?" vs. "&" option is handled by core functions. Nils' suggestion should work '' --DarTar
Yup, this works. Thanks!
And isn't it possible to have the comments shown by default for every user?
''at the moment not. maybe if someone has time... do you mean every registered user, or every user? '' --NilsLindenberg
''I don't understand the question. Can you please be more specific? '' --DarTar
Oops, I thought they didn't show up by default, but it apperently does.
And will there be translations?
''An internalization/localization project is currently under discussion, but it requires a major overhaul of the code, so don't expect it to appear in the very next releases'' -- DarTar
Please help me. Thanks!! - TromboneFreakus
===Foreach in php version 4.3.10===
<<==NOTE: Not a bug!==<<::c::
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)<?php foreach ($array as $element) ?>%% is not correct, and should be replaced by
%%(php)<?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:
~-http://bugs.php.net/bug.php?id=31134
~-http://bugs.php.net/bug.php?id=31108 ---("Ran into the same problem with 'foreach' during preliminary testing...---The solution is to ensure that your ZendOptimizer has been upgraded to a minimum of 2.5.7...")
Looks like changing the syntax is only a workaround in case a new Zend version cannot be installed --JavaWoman''
~-Please see ForeachBugInPhp4dot3dot10 --DotMG
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 cached files will still have the error: the pages must be recompiled.
**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
----
== 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**
%%(php)
$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**
%%(php)
$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**
%%(php)
if ($_GET["mail"]=="result") {
%%
**modified**
%%(php)
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.
%%(php) 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
----
== Forced links Formatter bug ==
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: %%(php) "\[\[[^\[].*?\]\]|".%% - this does indeed expect at least one (not-[) character after the opening two ""[[""; I think this could be replaced with: %%(php) "\[\[[^\[]*?\]\]|".
%% 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 == "¥¥")
{
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>");
}
%%
----
== 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
----
- 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 [. {{colour c="#707070" text="[DotMG]"}}
- ''//Can you give me some more detail on this one. I'm not sure what you mean or how to replicate the bug. -- JsnX 5/27/04//''
- Is anyone else seeing this? -- JsnX 5/29/04
- //I have a french azerty keyboard, and to type ""{"", I combine keys Alt Gr and 4. But when I try this inside the box, I have my line enclosed with ""==="", as I typed Ctrl + Shift + 4, and the character ""{"" doesn' t appear as expected! It's because of Javascript.//{{colour c="#707070" text="[DotMG]"}}
- I'm not encountering any problems with my swedish keyboard. Can use the full range of Alt Gr symbols: @£$?{[]}\. -- JockeAndersson 6/1/04
- //Ok, I corrected it myself. wikiedit2/wikiedit2.js --DotMG//:
%% 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 think defaulting to "Public" ownership would be more beneficial than Nobody. Nobody allows anyone to gain ACL rights to main pages if the proper setup steps are not taken. This is a major security issue and should have been addressed when the "Public" role was created.
- ''This is not a security issue within the context of a wiki. Wikis are supposed to be open by design. In addition, admins can change ownership whenever they want. However, personally I agree with your point, and this will be considered for a future release. '' - 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
- The problem instigator is the colon on that line. As soon as the colon is removed it works fine. So, the next question is: why is it causing a problem? And the answer is, the formatter sees the colon and thinks we are trying to specify an Interwiki link. If we really trace the problem we find that this can be traced back to JavaWoman! :) Take a look at her suggestions to fix interwiki links on WikkaBugsResolved. Here's the regular expression recommended to match interwiki links: ---
%% "\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;
~2) the RE used to match an Interwiki assumes only [[WikiName]]s 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 [[WikiName]]s.
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)<?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)<?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)<?php
"\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]([A-Z,a-z,0-9,ÄÖÜ,ßäöü]*)\b|".
?>%%
into this:
%%(php)<?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)
<?php
if (isset($error))
{
print("<tr><td></td><td><div class=\"error\">".$this->Format($passerror)."</div></td></tr>\n");
}
?>
%%
to this:
%%(php)
<?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)<?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)<?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 [[http://wiki.samuelooi.com 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
- Edit ACL, deleting SdfdsfaSdasd and the exclamation mark
- 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 {{colour c="#707070" text="[DotMG]"}}
%%
<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) {{colour c="#707070" text="[MarkHissinkMuller]"}}
- ''//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)
<?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>';
}
?>
%%
----
Additions:
===Older topic===
- There are two related bugs in the productionised code. WikiName and WikiPage need to be created to "complete" the group of default pages. If you can't be bothered to create them, register them in WantedPages by default please. ''Deeper analysis shows that WikiPage is meant to be uncreated by default, my apologies. WikiName is found on UserSettings (when you don't enter a valid username) and FormattingRules by default.''
- I mean, I can't even figure out how to get the file uploader running! Let alone figure out whether it's been implemented! I can see the files.php page, but where does it get executed?? ''Oops apparently, it's ""{{files}}"", I'm an idiot! But let's see some documentation for this! Btw, the default uploads directory is not created in installation (is this a security precaution?).''
- There are two related bugs in the productionised code. WikiName and WikiPage need to be created to "complete" the group of default pages. If you can't be bothered to create them, register them in WantedPages by default please. ''Deeper analysis shows that WikiPage is meant to be uncreated by default, my apologies. WikiName is found on UserSettings (when you don't enter a valid username) and FormattingRules by default.''
- I mean, I can't even figure out how to get the file uploader running! Let alone figure out whether it's been implemented! I can see the files.php page, but where does it get executed?? ''Oops apparently, it's ""{{files}}"", I'm an idiot! But let's see some documentation for this! Btw, the default uploads directory is not created in installation (is this a security precaution?).''
Additions:
===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 ##<?=$q ?>## by **##<?php echo $q;?>##** in the value attribute of the form (line 14).
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 ##<?=$q ?>## by **##<?php echo $q;?>##** in the value attribute of the form (line 14).
Revision [3850]
Edited on 2004-12-30 23:52:16 by NilsLindenberg [MyChanges alphabetical sort doesn't work moved in]Additions:
===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:
%%(php) 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:
%%(php) 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 will be included in version 1.1.6.0. -- JsnX
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:
%%(php) 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:
%%(php) 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 will be included in version 1.1.6.0. -- JsnX
Additions:
===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)<?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)<?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
''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)<?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)<?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
Revision [3843]
Edited on 2004-12-30 23:35:50 by NilsLindenberg [added TromboneFreakus question about rewrite-mode]Additions:
===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.
''look in your wikka.config.php: if you have 'rewrite_mode' => '1', set it to '0'. That should solve the problem?'' --NilsLindenberg
''You don't need to edit the handlers, because the "?" vs. "&" option is handled by core functions. Nils' suggestion should work '' --DarTar
Yup, this works. Thanks!
And isn't it possible to have the comments shown by default for every user?
''at the moment not. maybe if someone has time... do you mean every registered user, or every user? '' --NilsLindenberg
''I don't understand the question. Can you please be more specific? '' --DarTar
Oops, I thought they didn't show up by default, but it apperently does.
And will there be translations?
''An internalization/localization project is currently under discussion, but it requires a major overhaul of the code, so don't expect it to appear in the very next releases'' -- DarTar
Please help me. Thanks!! - TromboneFreakus
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.
''look in your wikka.config.php: if you have 'rewrite_mode' => '1', set it to '0'. That should solve the problem?'' --NilsLindenberg
''You don't need to edit the handlers, because the "?" vs. "&" option is handled by core functions. Nils' suggestion should work '' --DarTar
Yup, this works. Thanks!
And isn't it possible to have the comments shown by default for every user?
''at the moment not. maybe if someone has time... do you mean every registered user, or every user? '' --NilsLindenberg
''I don't understand the question. Can you please be more specific? '' --DarTar
Oops, I thought they didn't show up by default, but it apperently does.
And will there be translations?
''An internalization/localization project is currently under discussion, but it requires a major overhaul of the code, so don't expect it to appear in the very next releases'' -- DarTar
Please help me. Thanks!! - TromboneFreakus
Revision [3782]
Edited on 2004-12-28 15:39:06 by JavaWoman [additional notes about PHP foreach issue]Additions:
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 cached files will still have the error: the pages must be recompiled.
**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. :))
**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. :))
Deletions:
~''**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''
Additions:
<<==NOTE: Not a bug!==<<::c::
Deletions:
Revision [3779]
Edited on 2004-12-28 15:29:07 by JavaWoman [adding Foreach in php version 4.3.10 from WikkaBugs]Additions:
===Foreach in php version 4.3.10===
<<==NOTE: Note a bug!==<<::c::
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)<?php foreach ($array as $element) ?>%% is not correct, and should be replaced by
%%(php)<?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:
~-http://bugs.php.net/bug.php?id=31134
~-http://bugs.php.net/bug.php?id=31108 ---("Ran into the same problem with 'foreach' during preliminary testing...---The solution is to ensure that your ZendOptimizer has been upgraded to a minimum of 2.5.7...")
Looks like changing the syntax is only a workaround in case a new Zend version cannot be installed --JavaWoman''
~-Please see ForeachBugInPhp4dot3dot10 --DotMG
~''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''
<<==NOTE: Note a bug!==<<::c::
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)<?php foreach ($array as $element) ?>%% is not correct, and should be replaced by
%%(php)<?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:
~-http://bugs.php.net/bug.php?id=31134
~-http://bugs.php.net/bug.php?id=31108 ---("Ran into the same problem with 'foreach' during preliminary testing...---The solution is to ensure that your ZendOptimizer has been upgraded to a minimum of 2.5.7...")
Looks like changing the syntax is only a workaround in case a new Zend version cannot be installed --JavaWoman''
~-Please see ForeachBugInPhp4dot3dot10 --DotMG
~''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''
Additions:
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]]
Deletions:
Revision [3138]
Edited on 2004-12-13 16:59:19 by JavaWoman [restoring Korean text in Unicode rendering buglet]Additions:
''Hmmm - [[SandBox 안되려나]] - Unicode rendered in plain text but not for link text (안되려나)? Looks like a bug to me.'')
Deletions:
Additions:
== Feedback Action bug==
A bug was preventing the feedback action from working in installs with no rewrite rules. The bug is fixed in [[ReleaseNotes 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
''Hmmm - [[SandBox ????]] - Unicode rendered in plain text but not for link text (????)? Looks like a bug to me.'')
A bug was preventing the feedback action from working in installs with no rewrite rules. The bug is fixed in [[ReleaseNotes 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
''Hmmm - [[SandBox ????]] - Unicode rendered in plain text but not for link text (????)? Looks like a bug to me.'')
Deletions:
Deletions:
Additions:
==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.)
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.
%%(php) function htmlspecialchars_unicode($text="")
{
$text = preg_replace('/&(?!#[0-9]+;)/s', '&', $text);
$text = str_replace('<', '<', $text);
$text = str_replace('>', '>', $text);
$text = str_replace('"', '"', $text);
$text = str_replace("'", ''', $text);
return $text;
}%%
-- JsnX
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.)
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.
%%(php) function htmlspecialchars_unicode($text="")
{
$text = preg_replace('/&(?!#[0-9]+;)/s', '&', $text);
$text = str_replace('<', '<', $text);
$text = str_replace('>', '>', $text);
$text = str_replace('"', '"', $text);
$text = str_replace("'", ''', $text);
return $text;
}%%
-- JsnX
Additions:
== Forced links Formatter bug ==
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: %%(php) "\[\[[^\[].*?\]\]|".%% - this does indeed expect at least one (not-[) character after the opening two ""[[""; I think this could be replaced with: %%(php) "\[\[[^\[]*?\]\]|".
%% 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
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: %%(php) "\[\[[^\[].*?\]\]|".%% - this does indeed expect at least one (not-[) character after the opening two ""[[""; I think this could be replaced with: %%(php) "\[\[[^\[]*?\]\]|".
%% 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
Additions:
==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
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
Revision [2594]
Edited on 2004-11-28 22:48:22 by JsnX [resolving "Strikethrough rendering" as discussed on WikkaCSS]Additions:
== 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 == "¥¥")
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>");
== 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
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 == "¥¥")
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>");
== 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
Additions:
- 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 [. {{colour c="#707070" text="[DotMG]"}}
- ''//Can you give me some more detail on this one. I'm not sure what you mean or how to replicate the bug. -- JsnX 5/27/04//''
- Is anyone else seeing this? -- JsnX 5/29/04
- //I have a french azerty keyboard, and to type ""{"", I combine keys Alt Gr and 4. But when I try this inside the box, I have my line enclosed with ""==="", as I typed Ctrl + Shift + 4, and the character ""{"" doesn' t appear as expected! It's because of Javascript.//{{colour c="#707070" text="[DotMG]"}}
- I'm not encountering any problems with my swedish keyboard. Can use the full range of Alt Gr symbols: @£$?{[]}\. -- JockeAndersson 6/1/04
- //Ok, I corrected it myself. wikiedit2/wikiedit2.js --DotMG//:
%% if (event.altKey && !event.ctrlKey) Key=Key+4096;
if ((event.ctrlKey) && !event.altKey) Key=Key+2048;
- ''//Can you give me some more detail on this one. I'm not sure what you mean or how to replicate the bug. -- JsnX 5/27/04//''
- Is anyone else seeing this? -- JsnX 5/29/04
- //I have a french azerty keyboard, and to type ""{"", I combine keys Alt Gr and 4. But when I try this inside the box, I have my line enclosed with ""==="", as I typed Ctrl + Shift + 4, and the character ""{"" doesn' t appear as expected! It's because of Javascript.//{{colour c="#707070" text="[DotMG]"}}
- I'm not encountering any problems with my swedish keyboard. Can use the full range of Alt Gr symbols: @£$?{[]}\. -- JockeAndersson 6/1/04
- //Ok, I corrected it myself. wikiedit2/wikiedit2.js --DotMG//:
%% if (event.altKey && !event.ctrlKey) Key=Key+4096;
if ((event.ctrlKey) && !event.altKey) Key=Key+2048;
Revision [2559]
Edited on 2004-11-27 19:06:03 by JsnX [resolved initial ownership of default pages to Public]Additions:
- I think defaulting to "Public" ownership would be more beneficial than Nobody. Nobody allows anyone to gain ACL rights to main pages if the proper setup steps are not taken. This is a major security issue and should have been addressed when the "Public" role was created.
- ''This is not a security issue within the context of a wiki. Wikis are supposed to be open by design. In addition, admins can change ownership whenever they want. However, personally I agree with your point, and this will be considered for a future release. '' - JsnX
- ''This is not a security issue within the context of a wiki. Wikis are supposed to be open by design. In addition, admins can change ownership whenever they want. However, personally I agree with your point, and this will be considered for a future release. '' - JsnX
Additions:
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
Additions:
==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
- The problem instigator is the colon on that line. As soon as the colon is removed it works fine. So, the next question is: why is it causing a problem? And the answer is, the formatter sees the colon and thinks we are trying to specify an Interwiki link. If we really trace the problem we find that this can be traced back to JavaWoman! :) Take a look at her suggestions to fix interwiki links on WikkaBugsResolved. Here's the regular expression recommended to match interwiki links: ---
%% "\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.
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
- The problem instigator is the colon on that line. As soon as the colon is removed it works fine. So, the next question is: why is it causing a problem? And the answer is, the formatter sees the colon and thinks we are trying to specify an Interwiki link. If we really trace the problem we find that this can be traced back to JavaWoman! :) Take a look at her suggestions to fix interwiki links on WikkaBugsResolved. Here's the regular expression recommended to match interwiki links: ---
%% "\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.
Additions:
==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
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
Additions:
- 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? ... //''
Deletions:
Additions:
- 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? ... //''
Deletions:
Additions:
==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)
<?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>';
}
?>
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)
<?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>';
}
?>
Revision [1770]
Edited on 2004-10-09 14:16:35 by JsnX [resolved interwiki issue - thanks to JavaWoman]Additions:
===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;
~2) the RE used to match an Interwiki assumes only [[WikiName]]s 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 [[WikiName]]s.
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)<?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)<?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)<?php
"\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]([A-Z,a-z,0-9,ÄÖÜ,ßäöü]*)\b|".
into this:
%%(php)<?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
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;
~2) the RE used to match an Interwiki assumes only [[WikiName]]s 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 [[WikiName]]s.
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)<?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)<?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)<?php
"\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]([A-Z,a-z,0-9,ÄÖÜ,ßäöü]*)\b|".
into this:
%%(php)<?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
Additions:
<<For open Bugs/Issues look at WikkaBugs.<< ::c::
===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)
<?php
if (isset($error))
{
print("<tr><td></td><td><div class=\"error\">".$this->Format($passerror)."</div></td></tr>\n");
}
?>
to this:
%%(php)
<?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)<?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)<?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
===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)
<?php
if (isset($error))
{
print("<tr><td></td><td><div class=\"error\">".$this->Format($passerror)."</div></td></tr>\n");
}
?>
to this:
%%(php)
<?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)<?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)<?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
Deletions:
Revision [1722]
Edited on 2004-10-07 10:49:24 by DavidCollantes [resolved two bugs - thanks to JavaWoman]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_Einsten". --DavidCollantes
===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
Additions:
==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
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
Additions:
<<For open Bugs/Issues look at WikkaBugs.<<
Deletions:
Additions:
For open Bugs/Issues look at WikkaBugs.
