Comparing revisions for WikkaBugs
- [9654] 2005-06-27 07:00:35 by JavaWoman (unregistered user) [accesskey on comments]
- [20755] 2009-08-17 09:46:45 by JeyRey (unregistered user) [over 5 year old resolved issue removed]
Additions:
{{lastedit show="3"}}
<<**Related pages**:
-check resolved bugs/issues (//in released or to-be-released code//) in WikkaBugsResolved first
-workarounds for unusual problems and temporary fixes for known bugs listed at WikkaWorkarounds
-for issues related to Wikka layout refer to: WikkaCSS
-for feature suggestions rather than bugs, go to the SuggestionBox
-looking for help? check the [[WikkaDocumentation Wikka Documentation]]
<<>>==Attention:==
For problems with **foreach** in PHP version **4.3.10**:---See WikkaBugsResolved>>::c::
If you found a new bug or other issue, please post it here - //with// any solution you may have found. (WikkaBugsResolved is only fot bugfixes that have made it into a release or to-be-released code already.)
''Please use the comments only to actually //comment// on a reported bug but not to report a new one!''
**Please post recently discovered issues on the //top// of this page (just below this note); don't forget to add a ""===heading==="" as a condensed description.**
::c::
===Accesskey on comments===
//copied from the #wikka channel - JW//
<SamuelDr> for the next important guy/gal who'll read this
<SamuelDr> the accesskey="d" on the comments is a little bit useless
<SamuelDr> when there are more than 1 comment deletable on a page
<SamuelDr> I think it wouldn't work really well ;)
===Formatter-bug in the comments===
//reported by someone named DarTar ;) on my userpage. --NilsLindenberg//
Note for ourselves: if you look at the commentinfo by dialup-4.227.116.20 you'll see that we have a small formatter bug (Dial1 is parsed as a missing page): CamelCase formatting should not be applied within commentinfo's.
''part of a users host-name is formatted as a wikilink''
=== 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);
while (preg_match("/\t[ ]{4}/",$body)) {
$body = preg_replace("/\t[ ]{4}/","\t\t", $body);
}
-- TimoK
// indented text
elseif (preg_match("/\n([\t~]+)(-|&|([0-9a-zA-ZÄÖÜßäöü]+)\))?(\n|$)/s", $thing, $matches))
This simply doesn't match indents on the first line.
I know there is a problem in the edit handler as well with indents, but even if that is fixed (working solution for that problem at WikkaBugsResolved) we still will have the problem here. -- TimoK
===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
I just started using this program and I love it ! Its exactly what I've been looking for. However what I want is a Wikki where only the administrator can register new users. This seems like such an obvious feature that I am amazed I cant figure out how to do it !
What am I missing ?
--DavidLee
--Sorta Fixed--
Ok I figured this out ... mostly. Feel free to delete this section if its seems obvious to everyone ! (It wasnt to me)
I changed my default ACL for write and comment to "!*" ... but left read as "*".
People can still register themselves but it doesnt do them much good as they cant create pages.
--DavidLee
Hi DavidLee!
No, we don't have an ""{{adduser}}"" yet. If you don't want other people to register, try out the solution from UserRegistration which allows you to stop registration (and you could use phpmyadmin to add users directly to the database). The solution makes it possible to allow registration only with a password, which can be set in the config. See UserRegistration for more details. A division of registration/log-in and usersettings into different actions is planned but won't come in the next release. --NilsLindenberg
===Code display problem===
The following combination of conditions triggers the problem:
~-multi-line comment (for instance a multi-line /*........*/ block in php)
~-empty lines within such a comment
~-line numbering turned on
When viewed in Mozilla or Firefox (at least - possibly others), the empty lines **overlap** the preceding lines, as can be seen by the line numbers.
Looking at the generated code, an empty line within a multi-line comment (with line numbers) results in this code: %%(html4strict)<li><div class="de1"><span class="coMULTI"></span></div></li>%%---while an empty line elsewhere results in %%(html4strict)<li><div class="de1"> </div></li>%%---Note the ## ## in the latter case (which gives the div actual content) while the empty multi-comment line has nothing but an **empty** span, and no actual content.
This seems to be a combination of a **GeSHi** bug (there should at least a ## ## be generated as content) combined with a **gecko** oddity (or bug?) that will render a number for an ordered list item but not give it a normal line height if the list item is empty.
**Workaround:** add some whitespace to the empty lines - a single tab works (a space probably will as well).
--JavaWoman
===Installer array_merge()===
//Mentioned in passing on #wikka by a user having actually other problems installing Wikka.//
Remember the array_merge() problem in wikka.php under PHP5? Solved in 1.1.6.0.
Guess what: the same problem still exists - but in the installer itself (##/setup/install.php## - line 7): the second argument is (again) not initialized so users get a warning stating "Argument #2 is not an array in /var/www/html/Wikka/setup/install.php on line 7".
We'd better solve it in the installer as well. --JavaWoman
===View Code Handler issue===
The view code handler does not display any message if the page does not exist. [[http://wikka.jsnx.com/NonExistantPage/showcode Example]] -- Rick
~& Technically, it isn't a bug: Wikka tries to display original data concerning the page. As it doesn't exists, Wikka displays nothing. It isn't a bug but a non-existent feature of Wikka, so I would put this comment in SuggestionBox instead of here. JavaWoman? DarTar? What do you think of it? -- PivWan
~~&Actually, I suggested Rick reported it here since I **do** consider it a bug. It is a **page** handler so the handler should look for a page; I think it should return //something// at least. IMO the best solution would be to generate a warning like "Page does not exist" when the page isn't found, or use the "do you want to create it?" we use when accessing a non-exstant page. --JavaWoman
~~~& Okay, hadn't the whole story. So, it's a bug :) -- PivWan
===Email deletion after registration===
On 1.1.6.0 a registered user can modify his or her settings and store an **empty email address**. The engine does not warn the user and accepts an empty value. This bug should be fixed or at least the behavior of UserSettings should be made consistent with the registration requirements (if an email is required, it is required also //after// registering). Note that this might break (beta-)actions based on user email, such as FeedbackActionUpgrade (to be checked)-- DarTar
//reported by |Sam| on #wikka, writeup by me --JavaWoman//
Purging of pages doesn't always seem to happen. |Sam| had the page_purge_time set to 1 (which should purge page versions older than one day) but didn't see them being actually purge. Purging is done in the Maintenance() method in ##wikka.php## executed by the main Run() method. However, there is an extra condition here: %%(php)if(!($this->GetMicroTime()%3)) $this->Maintenance();%% I suspect this may cause the Maintenance() method not being executed. The intention of this (undocumented) condition isn't clear to me - should it really be there? --JavaWoman
~&That's correct. I'm not the author of this code, but the intention is clear to me. It's designed to be a performance improvement. Rather than call the Maintenance function for every single page view(!), it adds some randomness based on the remainder of GetMicroTime() divided by 3. For a busy site this could make a significant drop in MySQL queries. I have done some brief testing of this code and found that on average the Maintenance function was called about every four page views. For any site that has even moderate traffic, the Maintenance function will be triggered sufficiently. To answer your question, yes, this condition should be there. However, maybe there should be a configuration option that admins could tweak if they are obsessed and need certainty that pages get purged. -- JsnX
~~&Another way is to follow what (I think) PHP does for session cleanup. Set a threshold and test if a random number (between 0 and 1, inclusive of 0) is less than that threshold. If so, then do cleanup. Otherwise don't. The threshold is then a percentage chance that cleanup will happen on a particular request instead of hoping that the time falls just right. --JameSmith
//reported by velkr0 on #wikka, analysis and writeup by me -- JavaWoman//
**Problem**: When the rss action is included in a page with a feed URL that happens not to exist (or not exist any more), the page "hangs"; once in this state, editing the page also isn't possible: the hang continues until the browser times out or is closed.
The obvious cause is that neither the ""{{rss}}"" action nor the underlying onyx-rss class checks for //existence// of the resource the feed URL refers to. The problem is already hard to detect when you are first including a feed in a page and maybe make a typo in the feed URL. But if your Wikka provides a page with one or more feeds, and a feed suddenly disappears (or is down momentarily) the result will be very annoying for your visitors.
**Solution**: Either the onyx-rss class or the rss action should check for the availability of the feed (for instance with a HEAD request) before actually trying to retrieve it. Since the class provides caching, the best option would be to handle it in the class (by subclassing the necessary method(s)). If a version of the feed still exists in the cache that version could be displayed (probably this happens automatically anyway), otherwise an error message should be generated instead of the feed output. --JavaWoman
Another problem with Onyx-RSS was just reported by |Sam| on #wikka: in spite of cacheing it seems quite slow, taking something like 2.5 seconds for rendering after retrieving a feed (compared to a normal page rendering time of 0.06 seconds). We should look at the efficiency (or not) of this class - maybe it's time to move to another one that's being actively maintained. --JavaWoman
===Safari and WikiEdit===
(//copied from SandBox - JavaWoman//)
Safari crashes when I use a formatting button. (DarTar has confirmed this.)
It looks like either Safari has a bug in their JavaScript implementation, or WikiEdit's JavaScript isn't (sufficiently) cross-browser, or both. While the browser shouldn't crash on encountering JavaScript it cannot handle, we certainly need an edit toolbar that's more cross-browser (it doesn't appear at all in Opera 7.2x on Windows). --JavaWoman
===WantedPages problem===
The list of Wantedpages may be handy, but I just found the list is not sorted alphabetically, making it hard to scan. That's a "UI bug". The list should be sorted, at least - and preferably split up by starting letters, as in PageIndex (when all pages are shown). --JavaWoman
===Problem with handlers===
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
===passwords containing $ aren't working===
The installation succeed but the wiki doesn't work(connection pb if the db password contains one or more dollars symbols '$'.
The error occur at the creation of the wakka object :
"The wiki is currently unavailable. Error : Unable to connect to the Mysql database"
~& Did you tried to escape them? For example "john$doe" replaced by "john\$doe". AFAIK, it isn't a wikka bug but a php engine's side effect. All string beginning with $ are considered as variables and are interpreted as is. -- PivWan
~~&Solution is to simply use single quotes instead of double quotes so $ is not interpreted as the start of a variable name; involves some changes in the installer. Will likely appear in 1.1.6.1 --JavaWoman
===Extreme extreme slowness===
Not being registered makes no difference. There are users reporting Wikka pages taking several minutes to load!
The guys on the Puppy Linux Forum (SimpleForumPro, a Perl script on the same host, runs real fast), have been analysing the problem, discussion here (look further down the page):
http://www.goosee.com/puppy/sforum/simpleforum_pro.cgi?fid=07&topic_id=1111215715&page=2
...anyone got any thought what the cause could be?
===Spaces in uploaded files===
//Thanks to MrTrick for pointing out this problem//
It is possible to upload files with a space in the file name. However, when trying to download such a file things don't work as expected: in Mozilla browsers (Mozilla, Firefox, etc.) the suggested filename for the download is truncated at the first space.
Two possible solutions:
~1) Prevent that file names are //stored// with spaces in the name; simply replacing all spaces with underscores would do the trick and keep the file name recognizable. This has the advantage that no assumptions are being made about the server OS //or// the user's OS as to whether spaces in file names are valid.
~2) Mozilla seems to pick up the suggested file name from the Content-Disposition header. (raw)urlencoding the file name here works, but then displays the name with the encoding; enclosing the file name in (double) quotes works better, showing the full file name with spaces. This has the advantage that the original file name is preserved - //provided// both the server OS and the downloading user's OS can handle such file names.---
Take your pick ;-) -- JavaWoman
If you edit the ACL on a page, click "Store ACLs", then edit the ACL and click "Cancel", it still reads "Access control lists updated.", even though the changes were canceled. This is due to the "Cancel" button causing the browser to navigate backwards, and a javascript popup. --BarkerJr
===Alzheimers for Wikka?===
This is not a bug specifically - it is really a potential implentation weakness, but if a user specifies a page purge time in wikka.config: "pages_purge_time" => "100" and if that page is not edited for a while, then when that page is edited, the last copy will be deleted, leaving no archived copies at all. I think purge pages should delete old pages, but there should always be a minimum number of old copies preserved, otherwise the wiki becomes highly vulnerable to a content deletion attack. Would it be better to remove this feature, or modify it? --IanAndolina
~&Instead of removing or modifying it (the configuration parameter, rather) we could refine it by introducing an extra parameter name something like "pages_keep" to set a maximum number of pages to be kept regardless (maximum, since it could be less if there are not that many versions in the first place). Setting one or the other to 0 could disable purging altogether. --JavaWoman
~~&Sounds good to me - can you think of an elegant way to modify the SQL query to only delete pages older than X that are also more than Xth on a list of revisions. I'm sure I can come up with something ugly ;) --IanAndolina
~~~&I'm good enough at SQL that I need the manual for that. ;-) As far as I can determine, you need two statements (semi pseudo code): 1) a ##select count(*) from pages where ...## to determine the current number of records; and 2) ##delete from pages where ... order by [timestamp] limit [$count - $pages_keep]##. You can't do a subquery in delete (yet) so the count must be a separate step (but it should be very fast). --JavaWoman
//reported in IRC while I was asleep, sorry - JW does have to sleep sometimes//
(Potential) User extremely frustrated when at installation he's entering a real and valid email address and the Installer rejects it with "Email appears incorrect". This is caused by the extremely brain-dead Javascript in the installer that accepts **nothing but lowercase letters** to appear before the '@'. To be anywhere like realistic it should be corrected to accept numbers, dots, hyphens and underscores as well.
--JavaWoman //(hoping the reporter shows up again so I can help him with a workaround)//
~& Gosh, this is //really// annoying. JW, any news from your general-purpose [[WikkaEmailToolkit email validation]] functions ;-) -- DarTar
~~&The basic problem is that the installer does not use any system routines but instead JavaScript for validation. And the RE it uses for email validation is really, really braindead. Yes, very annoying as I've not seen the user back in #wikka either - we may have lost a user. I could have given a workaround if only I'd not been sleeping. --- Email library is not quite ready but getting close (needs some restructuring, basically); it will be a class, with several abstract methods so the installer should be able to use it as well (provided it can find the class file). And I'm learning some good tricks working on the sessions module (which might also be useful for Wikka). But the installer needs a major overhaul in any case. Sigh... --JavaWoman
===Comments in formatted PHP code===
GeSHi has a habit of adding a trailing line if the PHP code contains a comment using ""//"" or ""#"".
For example %%(php) echo "hello world"; // How do you do?%% This does not happen if ""/* */"" is used for comments. For example %%(php) echo "hello world"; /* How do you do? */%%
-- FreekDijkstra
~&Sounds also like a GeSHi problem rather than a Wikka bug. If anyone is installing (or has installed) GeSHi 1.0.6 I'd appreciate feedback on whether this cosmetic problem is solved as well. --JavaWoman
My default installation of Wikka 1.1.6.0 did display the error
htmlentities(): charset `646' not supported, assuming iso-8859-1 in /home/www/WWW/files/research/air/wiki/3rdparty/plugins/geshi/geshi.php
on the FormattingRules page. I was able to fix this by adding the "set_encoding" line in the GeSHi_Highlight() function in wikka.php:
$geshi =& new GeSHi($sourcecode, $language, $this->config['geshi_languages_path']); # existing code
$geshi->set_encoding('UTF-8'); # set encoding (new line)%%
-- FreekDijkstra
~&This is actually not a Wikka bug, but a problem in GeSHi itself - which only appears in rare cases. See CharsetNotSupportedWorkaround for more information. I think the latest GeSHi version (1.0.6) has addressed this problem. If you'd like to try this, make sure you remove the workaround code in Wikka when installing the new GeSHi version. --JavaWoman
===User name matching===
(related to the //Category name matching// item below)
While [[RegisterActionTest testing]] the beta RegisterAction, I realized that using a username like **""DarTartar""** results in a //"Sorry, username already exists"// error. Looks like a problem in the RE used by the ##""LoadUser()""## function. I'll take a look at it ASAP.
-- DarTar
===Multiple wikka installations on one host: Login security hole?===
Okay. Say that I've installed multiple seperate installations of wikka on one host. If I do a login on wikka A, I can also
reach the pages of wikka B, whereas wikka B has an authentication table where the user account of wikka A does not exist!
My guess is that this behaviour occurs because the login cookies are set with path root. And as long the login cookies exist
Wikka doesn't care about authentication anymore??
-- JeroenJansen
~&Same problem. Is it possible to include in wikka.config.php a line in which you specify the default cookie prefix? I guess this could solve the problem. --YanB
~~&Same problem for me as well. I've modified wikka.php to use different session names (add: session_name($wakkaConfig["wakka_name"]); just above the session_start(); ) and different cookies ("wikka_user_name@".$this->config["wakka_name"] and "wikka_pass@".$this->config["wakka_name"]) as my 2 wikkas do have have different wakka_names. Seems to behave as expected now. --OlivierPerron
===Category name matching===
Yes, I know the category system needs to be revamped, but I figured I'd report this anyway. If you have a category name that is a substring of another category name, pages referencing the second category will also appear in the first. In other words...I have a category named '""CategoryBookOne"", and another named ""CategoryBookOneJournal"". Pages that reference ""CategoryBookOneJournal"" also show up in the list of pages for ""CategoryBookOne"", which is not the behavior I expected or wanted.
-- TammyCravit
~&I cannot reproduce this on this server, nor on my own development system - at least not with the [[WikkaBetaFeatures beta and alpha]] versions of the category action. Possibly dependent on the version of PHP used where older versions may use a slightly different database query to find pages referring to a category. Tammy, if you're reading this: which version of PHP are you using? (We should test with the 'lower-PHP version of the query!) --JavaWoman
Gathered from error reports in different places (including comments on WikkaInstallation, #wikka and IM) - neither new, but worth repeating and putting together, I think:
~-In at least some cases the "detected" base path misses a closing slash (resulting in links that don't work); the installer should check if the derived path has a final slash, and if not, add one, before presenting that to the user.
~-If PHP (and thus Wikka) cannot connect to MySQL the installer just "hangs" after the first screen and printing "Testing configuration"; this seems to be (at least partly) the result of having error messages from the MySQL statements suppressed with a @, which would be OK if the error message were handled afterwards - but this doesn't happen. Other mysql_xxx() calls in the installer also have the @ suppressing error messages. That should either be removed, or all error messages should be picked up and handled by the installer, at the very least by showing the message to the user. ---
~This is especially a problem for users new at MySQL or new even at PHP+MySQL for whom it won't be obvious where to start troubleshooting when the installer simply hangs.
--JavaWoman
===mod_rewrite issue in WikiEdit===
When in edit mode using IIS if you click the help button the program doesn't take you to the FormattingRules page, but tries to go to the ""FormattingRules"" Directory, which does not exist.
~& It assumes that you're using mod_rewrite and goes to the "pretty" url (wikka.jsnx.com/""FormattingRules"" instead of wikka.jsnx.com/wikka.php?wakka=""FormattingRules"") - this needs to either be editable (or is it somewhere in the WikiEdit files and I just haven't found it?) or check with the wikka.config.php to make sure it's using the correct base_url. --MovieLady
===Bug in Textsearch (expanded)===
As DotMG has pointed out, the input for this two actions isn't validated, making it a security-hole.
You can fix it by changing the line
$phrase = stripslashes($phrase);
into
$phrase = preg_quote($this->htmlspecialchars_ent(stripslashes($phrase)), "/");
You have to change both files (textsearch and textsearchexpanded). --NilsLindenberg
===Advanced search results reveal confidential info===
Results should be hidden or not shown if the user doesn't have read access to page IMHO. --PolVazo
===Recent[ly]Comment[ed|s] actions should check for permission===
Comments are being previewed even if users do not have access. A simple check needs to be added. -- JsnX
if ($this->HasAccess("comment"))
===tags in the edit-notes===
I made a edit note: "removed a <?php (to much)" and got "removed a". Perhaps replacing <> would be the better option? --NilsLindenberg
~&Funny - I just stumbled over the same problem - only in the RecentChanges newsfeed: the <?php causes imbalanced tags there, and thus a syntax error: until that post has "aged" off of the feed, it can't be loaded any more! The [[http://feedvalidator.org/check?url=http%3a%2f%2fwikka.jsnx.com%2fRecentChanges%2frecentchanges.xml validation result]] clearly shows what the problem is. So yes, edit notes should be fed threough htmlspecialchars[_ent]() everywhere they're presented, and that includes the RSS feed! --JavaWoman
~~&And the WikiPing, too :) --NilsLindenberg
~&Oh is **that** what you removed Nils. I couldn't figure out using history what you did. Where did you take it from? And why? Did I have one more <?php than was necessary? In which code block? --GmBowen
~~&It was at the beginning of mail.php: %%(php) <?php <?php%%. I guess you overlooked it when you copied your new version to the page. Happent to me in another case, too. --NilsLindenberg
(copied from the sandbox --NilsLindenberg)
not support 2byte language in the Code formatters!!!!
%%(c)
// 한글이 깨지겠지
// 진짜 깨지네.. 흑흑.. 에디터창에서 깨지는 것도 열받는데..
...
Line 46 :
- Code generates a double </a> for links.
- & in URL should be replaced by &
=> %%(php) print("<td valign=\"top\">" . (($site != "unknown") ? "<a href=\"http://".$this->htmlspecialchars_ent($site)."\">".$this->htmlspecialchars_ent($site)."</a>" : $site) . /*"</a> ".*/($IsAdmin ? "[<a href=\"".$this->href("delete_referrer", "", "spam_site=").$this->htmlspecialchars_ent($site)."&redirect=".$this->GetMethod()."\">Blacklist</a>]" : "")."</td>");%%
Note: You cannot see this error by validating directly a page because W3C is not registered and it will not have the same output as you, in other words, code on line 46 won't be executed. But you can save the page on your hard disk and validate it.
--DotMG
**Not really bug, but should be corrected for respect & compliance to RFC2616**
If a browser sends the header
Accept-Encoding: gzip;q=0, deflate
Which should be interpreted as : "I don't support gzip encoding, but I prefer deflate", Wikka will understand "The browser supports gzip-encoding", as it just searches for the text gzip in $_SERVER['HTTP_ACCEPT_ENCODING']. An example I use to treat it correctly is :
%%(php) function ParseHeaderLine($hl, $token=null)
{
$ar_hl = explode(',', $hl);
foreach ($ar_hl as $dotmg_idx => $val)
{
if (preg_match('/^\s*(.*?);\s*q\s*=\s*([0-9\.]*)/i', $val, $match))
{
$res[strtolower($match[1])] = doubleval($match[2]);
}
else
{
$res[strtolower($val)] = 1;
}
}
if ($token) return(isset($res[$token]) && ($res[$token] > 0)); #if $token is set, we return true or false
return ($res); # else we return the header parsed.
}%%
and
%%(php) if ($this->ParseHeaderLine($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ...%%
Note : This function might be useful to deal also with Accept-Language, when Wikka will be made effectively multilingual.
--DotMG
A page contains unicode characters looks OK when viewed but displays ""''&#*****;''"" while edited in WikiEdit
Simplified Chinese Test:
中文是一种美丽的语言，除了具有音节上的美感，同样拥有视觉上的美感
In 1.1.5.3, I solved this problem by changed some line in ./handlers/page/edit.php
#from
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$body."</textarea><br />\n"
#to
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$this->htmlspecialchars_ent($body)."</textarea><br />\n"
Wikka is wonderful! ZhuangYuyao
~&This workaround you outlined will work as well in Wikka 1.1.6.0. A real solution wil take some more investigation though, so we were unable to fix this for the current release. This is now under investigation. --JavaWoman
I noticed: Turning off DoubleClick-editing does not work (double-clicks still go to edit-window) in IE 6.0 or Firefox 1.0.
Keep up the good work!
Cheers, MarkHissinkMuller
~&Yes, I noticed the same thing. This is a bug as of 1.1.6.0. --RyanKnoll
~~&Heres the fix:
~~&add as **first** line in handlers/page/show.php:
~~&%%(php)
<?php $user = $this->GetUser(); ?>
~~&and change the second line to:
~~&%%(php)
<div class="page" <?php echo ((!$user || ($user["doubleclickedit"] == 'Y')) && $this->GetMethod
() == "show") ? "ondblclick=\"document.location='".$this->href("edit")."';\" " : "" ?>>
~~&--NilsLindenberg
DarTar and I have recently created some test pages, testing page names related to how Wikka evaluates 'valid' page names: ,My,Page and ÄhnLich (yes, they both exist, even if they don't show up as such in this sentence!). Now look at where they show up on PageIndex... surely there shouldn't be **two** '#' indices??
--JavaWoman
~&I think that this is due to the encoding of the MySQL tables. I can't see how that would be fixed with a small touch on the code. If this is the matter then I hope that it also rings the i18n bell too. //Translation to Greek is my bussiness ;)// --GeorgePetsagourakis
~~&Yes, my i18n bells were already loudly ringing... but you bring up a good point with MySQL. I hadn't thought about a real cause yet, just wanted to record what I saw before I got distracted again ;-). Sort order is a whole subject of its own within i18n .... --JavaWoman
First, this may applied to my ISP only. When I installed, I have to use
the ?wakka= options. However, I have to add a / to the end of the
default Basic URL before append ?wakka= to it. So I think it maybe
helpful to modify the instruction to '... so it should include
the "/?wakka=" parameter...'
~&ArpY: Maybe this is caused by a config error. Please have a look at your config - is there a slash at the end of the base_url?
~~&IMO the installer should take care that there is a slash if the user doesn't enter it --JavaWoman
Um, I don't know how to describe this really. Put ""{{include page="Category Documentation"}}"" (//without the space!//)on the SandBox page....I can't figure out why it gives that output as Sandbox doesn't own anything.
~&Looks like the weirdness is caused by the ""{{Category}}"" action which assumes the "current page" represents the category - and find pages "belonging to" a category by finding a mention of that page name. Good sign our category system does need an [[CategorySystemOverhaul overhaul]]! --JavaWoman
~&Include pulls in a page that itself has the category action on it; the "official" version of this action assumes that the page it occurs on **is** a category. The "//experimental//" category action that is now active on this site no longer makes this assumption but recognizes that SandBox isn't a category page and defaults to the top category. See Sandbox for a an example (at this moment). --JavaWoman
~~&I can see that it now works, but what do you mean that it "recognizes that Sandbox isn't an action".....do you mean target page? --GmBowen
~~~&Oops, sorry (corrected now) - I meant the new category action sees whether the page it's "sitting" on is a category page or not - if not it defaults to showing the list for the top-level category. --JavaWoman (aka IamBack)
===Backlinks / ""LoadPagesLinkingTo()""===
I just discovered that the ##""{{backlinks}}""## action may list pages that don't "exist" any more, in the sense that they (apparently) still are in the database but without any active version (seemingly as a result of a rename action. I added an example on [[JavaWoman my own page]] where you can see a supposed backlink from ReleaseNotes (which was replaced by WikkaReleaseNotes).
~&The cause is apparently in the ""LoadPagesLinkingTo()"" method which is used by ##""{{backlinks}}""## action. It currently is implemented like this:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' order by tag"); }
%% I think replacing this by:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' and latest = 'Y' order by tag"); }
%% might do the trick to avoid deceased pages - but please test!
~&--JavaWoman
~~&It wont do, since the link-table has no latest col ;). But shouldn't the delete-handler delete these links from the table anyway? --NilsLindenberg
====GetEnv is not a good idea!====
At ./wikka.php, you will see a line %%(php)<?php if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";?>%%
In the most cases, a website is hosted in a machine as a VirtualHost, this means that a number of websites share the same environment variables. If someone knows where your site is hosted, he can put his site at the same server, and use a script containing %%(php)<?php putenv('WAKKA_CONFIG=/home/hacker/config.php');?>%%. And all wikka sites on the same server will use his configuration file. The rest actions to take to hack your site will be as easy as eating sandwich.
Php doc says that an environment variable is altered only during the life of the script, but with my dev Easyphp's on windows, that is false. (I think a "new" environment variable keep its value, even on Linux).
I wanted to make a unique Wikka interface used by 3 sites on the same server. The best secure solution I found is to alter ./wikka.php like this :
%%(php)<?php
if (file_exists("wakka.config.php")) rename("wakka.config.php", "wikka.config.php");
#if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";
if (!$configfile && isset($GLOBALS['wikka_config'])) $configfile = $GLOBALS['wikka_config'];
if (!$configfile) $configfile = "wikka.config.php";
if (file_exists($configfile)) include($configfile);
and put the 2 files sitenumber2.php and .htaccess below at the root of the server number 2:
__sitenumber2.php:__
%%(php)<?php
$GLOBALS['wikka_config'] = "/path/to/altered_config.php";
chdir("/path/to/basewikka");
include('wikka.php');
?>%%
__.htaccess:__
%%<IfModule mod_rewrite.c>
RewriteRule ^(css|images|wikiedit2)/(.*)$ /path/to/basewikka/$1/$2 [L]
RewriteRule ^(.*)$ sitenumber2.php?wakka=$1 [QSA,L]
</IfModule>%%
--DotMG
~&I've now written up my thoughts about a [[WikkaSecureConfig more secure way to handle Wikka's configuration]] (which should also provide also more flexibility). --JavaWoman
===Expanded Text Search fails===
I tried an expanded Text-Search after [[http://wikka.jsnx.com/TextSearchExpanded?phrase=%2Bparameter+%2Blink +parameter +link]] and got the following error:
"Warning: Compilation failed: nothing to repeat at offset 1 in /.../actions/textsearchexpanded.php on line 33"
for every page.
--NilsLindenberg
~&In my recent RE exploits I have found that a warning of this type comes up when a regular expression isn't quite correct (though not every attempt to match may bring up the warning); haven't investigated further in textsearchexpanded.php though. --JavaWoman
~&Php has a function : preg_quote that may help us. Or try this solution : DotMGTextSearchExpanded
Looking at **formatters/wikka.php** to find the cause of the two bugs listed below (found one), I notice to my horror that a **lot** of the regular expressions used there are actually incorrect. They allow such things as using a comma to indent a line (in addition to a tab, or ~, at the start of a line: **demo** in the SandBox, and in the list **below**!), or a comma in a WikiName (even at the start) or in an InterWiki link. That can't have been the intention - it's simply a matter of incorrect RE syntax. I'd become sort of "sensitized" to this phenomenon looking at DarTar's RE on ValidPageNames earlier today - now I see where he found an example (see my comment on that page on his RE!).
''See also [[,My,Page]] - yup, that's a real page now. ;-)''
~&Rather than simply fixing all the REs (and other REs all over the place...) I'd like to propose a more fundamental solution:
~&-create a "library" of RE building blocks to be used in the Wikka core (for an example of what I mean with building blocks see my propopsal for an alternative RE on ValidPageNames); simply create a separate file with define()s for these building blocks, and include them at the start of the main wikka.php file;
~&-gather all RE used in the Wikka core here (extensions/plugins could have their own set of defines - as long as they don't have conflicting names);
~&-now use **only** these building blocks when using REs anywhere in the Wikka core.
~&This should make it much easier to create both //correct//, and //consistent// regular expressions; any (near)duplicates will be much easier to discover, and fix.
~&
~&Probably best to leave this to just **after** the coming release, so we have a stable code base again. I volunteer to undertake this work. (Unlike some people, I happen to like REs.) :)
~&--JavaWoman
Have a look at the source of WikkaDevelopment, you will see that tabs and unordered lists for some reasons are not correctly parsed (actually after one edit, tabs were added at the beginning of each line). I'll try to figure out why this happens...
-- DarTar
~&Possible clue:
~&I just stumbled over the fact that the little list of "Useful pages" at the end of the default (installation-generated) ""HomePage"" had incorrect coding: The last list item (li) was not terminated, nor was the list itself (no closing ul tag). It took me a bit of trial and error to reproduce this - but have a look at my test code at the end of SandBox (now). Originally I thought that any list at the end of a page would be unterminated, but that turned out not to be the case. Then I hit on something else: the last list element on that default ""HomePage"" (not the one here) ands with a period. My test version on SandBox now also has the last element ending in a period ... and if you look at the (HTML) page source, you'll see it is indeed an unterminated list. Somehow that ending period (maybe in combination with end-of-page?) causes the Formatter never to close the list; take that ending period away, and it works normally. I tried a few variants, to check whether it might be an odd-even problem, but no: whether the number of list items is odd or even, if the last one ends in a period, the list isn't terminated.
~&
~&No difference whether it's anordered (ol) or unordered (ul) list, the formatter behaves the same way.
~&
~&And, BTW, if you look at the preview when editing, the HTML source of the **preview** actually contains a lot of Wiki code that shouldn't be there!
~&
~&I haven't dug in the Formatter yet to find the cause or whether end-of-page makes a difference...
~&--JavaWoman
~~&This is indeed an "end of page" problem: teh formatter has some code to close tags inadvertently left open, but does not do this for lists and indent (nor even fro *all* open tags). Fix coded and tested - this will be in 1.1.6.1. --JavaWoman
MySQL 5+ isn't supported as it requires PHP to use the mysqli extension instead of plain old mysql. I hoped there would be a single file to change this, but there seems to be no database abstraction in this project at all.
-- DavidCarrington
~&I do not have access to a MySQL 5 server for testing. And judging by the feedback that I see here on Wikka, most other Wikka admins are using older versions of MySQL. However, I do like progress, so I looked at the documentation for the mysqli extension. I don't see any major issue here. It looks like the function calls are the same, they just have a different name. Instead of calling mysql_connect, you call mysqli_connect. Instead of calling mysql_query, you call mysqli_query. So on and so forth.
~&
~&It seems that we would just have to do a simple version check and call "mysql" functions for older versions, and "mysqli" functions for newer versions.
~&
~&Please correct me if I'm missing something. -- JsnX 26 Nov 2004
~~&I'm running MySQL 5 fine with the mysql_* functions. When you compile PHP, it's your choice to compile the mysql_* or mysqli_* functions. I chose to compile it with mysql_*, which is working fine for me. --BarkerJr
==Login Problem==
==User search - should be case-sensitive==
===Email Addresses===
Found several issues with how email addresses are validated / accepted / used; outlined on WikkaAndEmail - and I'm working on solutions. (Email is //complicated// and there's a whole bunch of standards (RFCs) involved.)
First part of the solutions now in WikkaEmailToolkit; while the toolkit is still incomplete, what's there now can be used as presented there (no dependencies on later components).
-- JavaWoman
<<**Related pages**:
-check resolved bugs/issues (//in released or to-be-released code//) in WikkaBugsResolved first
-workarounds for unusual problems and temporary fixes for known bugs listed at WikkaWorkarounds
-for issues related to Wikka layout refer to: WikkaCSS
-for feature suggestions rather than bugs, go to the SuggestionBox
-looking for help? check the [[WikkaDocumentation Wikka Documentation]]
<<>>==Attention:==
For problems with **foreach** in PHP version **4.3.10**:---See WikkaBugsResolved>>::c::
If you found a new bug or other issue, please post it here - //with// any solution you may have found. (WikkaBugsResolved is only fot bugfixes that have made it into a release or to-be-released code already.)
''Please use the comments only to actually //comment// on a reported bug but not to report a new one!''
**Please post recently discovered issues on the //top// of this page (just below this note); don't forget to add a ""===heading==="" as a condensed description.**
::c::
===Accesskey on comments===
//copied from the #wikka channel - JW//
<SamuelDr> for the next important guy/gal who'll read this
<SamuelDr> the accesskey="d" on the comments is a little bit useless
<SamuelDr> when there are more than 1 comment deletable on a page
<SamuelDr> I think it wouldn't work really well ;)
===Formatter-bug in the comments===
//reported by someone named DarTar ;) on my userpage. --NilsLindenberg//
Note for ourselves: if you look at the commentinfo by dialup-4.227.116.20 you'll see that we have a small formatter bug (Dial1 is parsed as a missing page): CamelCase formatting should not be applied within commentinfo's.
''part of a users host-name is formatted as a wikilink''
=== 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);
while (preg_match("/\t[ ]{4}/",$body)) {
$body = preg_replace("/\t[ ]{4}/","\t\t", $body);
}
-- TimoK
// indented text
elseif (preg_match("/\n([\t~]+)(-|&|([0-9a-zA-ZÄÖÜßäöü]+)\))?(\n|$)/s", $thing, $matches))
This simply doesn't match indents on the first line.
I know there is a problem in the edit handler as well with indents, but even if that is fixed (working solution for that problem at WikkaBugsResolved) we still will have the problem here. -- TimoK
===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
I just started using this program and I love it ! Its exactly what I've been looking for. However what I want is a Wikki where only the administrator can register new users. This seems like such an obvious feature that I am amazed I cant figure out how to do it !
What am I missing ?
--DavidLee
--Sorta Fixed--
Ok I figured this out ... mostly. Feel free to delete this section if its seems obvious to everyone ! (It wasnt to me)
I changed my default ACL for write and comment to "!*" ... but left read as "*".
People can still register themselves but it doesnt do them much good as they cant create pages.
--DavidLee
Hi DavidLee!
No, we don't have an ""{{adduser}}"" yet. If you don't want other people to register, try out the solution from UserRegistration which allows you to stop registration (and you could use phpmyadmin to add users directly to the database). The solution makes it possible to allow registration only with a password, which can be set in the config. See UserRegistration for more details. A division of registration/log-in and usersettings into different actions is planned but won't come in the next release. --NilsLindenberg
===Code display problem===
The following combination of conditions triggers the problem:
~-multi-line comment (for instance a multi-line /*........*/ block in php)
~-empty lines within such a comment
~-line numbering turned on
When viewed in Mozilla or Firefox (at least - possibly others), the empty lines **overlap** the preceding lines, as can be seen by the line numbers.
Looking at the generated code, an empty line within a multi-line comment (with line numbers) results in this code: %%(html4strict)<li><div class="de1"><span class="coMULTI"></span></div></li>%%---while an empty line elsewhere results in %%(html4strict)<li><div class="de1"> </div></li>%%---Note the ## ## in the latter case (which gives the div actual content) while the empty multi-comment line has nothing but an **empty** span, and no actual content.
This seems to be a combination of a **GeSHi** bug (there should at least a ## ## be generated as content) combined with a **gecko** oddity (or bug?) that will render a number for an ordered list item but not give it a normal line height if the list item is empty.
**Workaround:** add some whitespace to the empty lines - a single tab works (a space probably will as well).
--JavaWoman
===Installer array_merge()===
//Mentioned in passing on #wikka by a user having actually other problems installing Wikka.//
Remember the array_merge() problem in wikka.php under PHP5? Solved in 1.1.6.0.
Guess what: the same problem still exists - but in the installer itself (##/setup/install.php## - line 7): the second argument is (again) not initialized so users get a warning stating "Argument #2 is not an array in /var/www/html/Wikka/setup/install.php on line 7".
We'd better solve it in the installer as well. --JavaWoman
===View Code Handler issue===
The view code handler does not display any message if the page does not exist. [[http://wikka.jsnx.com/NonExistantPage/showcode Example]] -- Rick
~& Technically, it isn't a bug: Wikka tries to display original data concerning the page. As it doesn't exists, Wikka displays nothing. It isn't a bug but a non-existent feature of Wikka, so I would put this comment in SuggestionBox instead of here. JavaWoman? DarTar? What do you think of it? -- PivWan
~~&Actually, I suggested Rick reported it here since I **do** consider it a bug. It is a **page** handler so the handler should look for a page; I think it should return //something// at least. IMO the best solution would be to generate a warning like "Page does not exist" when the page isn't found, or use the "do you want to create it?" we use when accessing a non-exstant page. --JavaWoman
~~~& Okay, hadn't the whole story. So, it's a bug :) -- PivWan
===Email deletion after registration===
On 1.1.6.0 a registered user can modify his or her settings and store an **empty email address**. The engine does not warn the user and accepts an empty value. This bug should be fixed or at least the behavior of UserSettings should be made consistent with the registration requirements (if an email is required, it is required also //after// registering). Note that this might break (beta-)actions based on user email, such as FeedbackActionUpgrade (to be checked)-- DarTar
//reported by |Sam| on #wikka, writeup by me --JavaWoman//
Purging of pages doesn't always seem to happen. |Sam| had the page_purge_time set to 1 (which should purge page versions older than one day) but didn't see them being actually purge. Purging is done in the Maintenance() method in ##wikka.php## executed by the main Run() method. However, there is an extra condition here: %%(php)if(!($this->GetMicroTime()%3)) $this->Maintenance();%% I suspect this may cause the Maintenance() method not being executed. The intention of this (undocumented) condition isn't clear to me - should it really be there? --JavaWoman
~&That's correct. I'm not the author of this code, but the intention is clear to me. It's designed to be a performance improvement. Rather than call the Maintenance function for every single page view(!), it adds some randomness based on the remainder of GetMicroTime() divided by 3. For a busy site this could make a significant drop in MySQL queries. I have done some brief testing of this code and found that on average the Maintenance function was called about every four page views. For any site that has even moderate traffic, the Maintenance function will be triggered sufficiently. To answer your question, yes, this condition should be there. However, maybe there should be a configuration option that admins could tweak if they are obsessed and need certainty that pages get purged. -- JsnX
~~&Another way is to follow what (I think) PHP does for session cleanup. Set a threshold and test if a random number (between 0 and 1, inclusive of 0) is less than that threshold. If so, then do cleanup. Otherwise don't. The threshold is then a percentage chance that cleanup will happen on a particular request instead of hoping that the time falls just right. --JameSmith
//reported by velkr0 on #wikka, analysis and writeup by me -- JavaWoman//
**Problem**: When the rss action is included in a page with a feed URL that happens not to exist (or not exist any more), the page "hangs"; once in this state, editing the page also isn't possible: the hang continues until the browser times out or is closed.
The obvious cause is that neither the ""{{rss}}"" action nor the underlying onyx-rss class checks for //existence// of the resource the feed URL refers to. The problem is already hard to detect when you are first including a feed in a page and maybe make a typo in the feed URL. But if your Wikka provides a page with one or more feeds, and a feed suddenly disappears (or is down momentarily) the result will be very annoying for your visitors.
**Solution**: Either the onyx-rss class or the rss action should check for the availability of the feed (for instance with a HEAD request) before actually trying to retrieve it. Since the class provides caching, the best option would be to handle it in the class (by subclassing the necessary method(s)). If a version of the feed still exists in the cache that version could be displayed (probably this happens automatically anyway), otherwise an error message should be generated instead of the feed output. --JavaWoman
Another problem with Onyx-RSS was just reported by |Sam| on #wikka: in spite of cacheing it seems quite slow, taking something like 2.5 seconds for rendering after retrieving a feed (compared to a normal page rendering time of 0.06 seconds). We should look at the efficiency (or not) of this class - maybe it's time to move to another one that's being actively maintained. --JavaWoman
===Safari and WikiEdit===
(//copied from SandBox - JavaWoman//)
Safari crashes when I use a formatting button. (DarTar has confirmed this.)
It looks like either Safari has a bug in their JavaScript implementation, or WikiEdit's JavaScript isn't (sufficiently) cross-browser, or both. While the browser shouldn't crash on encountering JavaScript it cannot handle, we certainly need an edit toolbar that's more cross-browser (it doesn't appear at all in Opera 7.2x on Windows). --JavaWoman
===WantedPages problem===
The list of Wantedpages may be handy, but I just found the list is not sorted alphabetically, making it hard to scan. That's a "UI bug". The list should be sorted, at least - and preferably split up by starting letters, as in PageIndex (when all pages are shown). --JavaWoman
===Problem with handlers===
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
===passwords containing $ aren't working===
The installation succeed but the wiki doesn't work(connection pb if the db password contains one or more dollars symbols '$'.
The error occur at the creation of the wakka object :
"The wiki is currently unavailable. Error : Unable to connect to the Mysql database"
~& Did you tried to escape them? For example "john$doe" replaced by "john\$doe". AFAIK, it isn't a wikka bug but a php engine's side effect. All string beginning with $ are considered as variables and are interpreted as is. -- PivWan
~~&Solution is to simply use single quotes instead of double quotes so $ is not interpreted as the start of a variable name; involves some changes in the installer. Will likely appear in 1.1.6.1 --JavaWoman
===Extreme extreme slowness===
Not being registered makes no difference. There are users reporting Wikka pages taking several minutes to load!
The guys on the Puppy Linux Forum (SimpleForumPro, a Perl script on the same host, runs real fast), have been analysing the problem, discussion here (look further down the page):
http://www.goosee.com/puppy/sforum/simpleforum_pro.cgi?fid=07&topic_id=1111215715&page=2
...anyone got any thought what the cause could be?
===Spaces in uploaded files===
//Thanks to MrTrick for pointing out this problem//
It is possible to upload files with a space in the file name. However, when trying to download such a file things don't work as expected: in Mozilla browsers (Mozilla, Firefox, etc.) the suggested filename for the download is truncated at the first space.
Two possible solutions:
~1) Prevent that file names are //stored// with spaces in the name; simply replacing all spaces with underscores would do the trick and keep the file name recognizable. This has the advantage that no assumptions are being made about the server OS //or// the user's OS as to whether spaces in file names are valid.
~2) Mozilla seems to pick up the suggested file name from the Content-Disposition header. (raw)urlencoding the file name here works, but then displays the name with the encoding; enclosing the file name in (double) quotes works better, showing the full file name with spaces. This has the advantage that the original file name is preserved - //provided// both the server OS and the downloading user's OS can handle such file names.---
Take your pick ;-) -- JavaWoman
If you edit the ACL on a page, click "Store ACLs", then edit the ACL and click "Cancel", it still reads "Access control lists updated.", even though the changes were canceled. This is due to the "Cancel" button causing the browser to navigate backwards, and a javascript popup. --BarkerJr
===Alzheimers for Wikka?===
This is not a bug specifically - it is really a potential implentation weakness, but if a user specifies a page purge time in wikka.config: "pages_purge_time" => "100" and if that page is not edited for a while, then when that page is edited, the last copy will be deleted, leaving no archived copies at all. I think purge pages should delete old pages, but there should always be a minimum number of old copies preserved, otherwise the wiki becomes highly vulnerable to a content deletion attack. Would it be better to remove this feature, or modify it? --IanAndolina
~&Instead of removing or modifying it (the configuration parameter, rather) we could refine it by introducing an extra parameter name something like "pages_keep" to set a maximum number of pages to be kept regardless (maximum, since it could be less if there are not that many versions in the first place). Setting one or the other to 0 could disable purging altogether. --JavaWoman
~~&Sounds good to me - can you think of an elegant way to modify the SQL query to only delete pages older than X that are also more than Xth on a list of revisions. I'm sure I can come up with something ugly ;) --IanAndolina
~~~&I'm good enough at SQL that I need the manual for that. ;-) As far as I can determine, you need two statements (semi pseudo code): 1) a ##select count(*) from pages where ...## to determine the current number of records; and 2) ##delete from pages where ... order by [timestamp] limit [$count - $pages_keep]##. You can't do a subquery in delete (yet) so the count must be a separate step (but it should be very fast). --JavaWoman
//reported in IRC while I was asleep, sorry - JW does have to sleep sometimes//
(Potential) User extremely frustrated when at installation he's entering a real and valid email address and the Installer rejects it with "Email appears incorrect". This is caused by the extremely brain-dead Javascript in the installer that accepts **nothing but lowercase letters** to appear before the '@'. To be anywhere like realistic it should be corrected to accept numbers, dots, hyphens and underscores as well.
--JavaWoman //(hoping the reporter shows up again so I can help him with a workaround)//
~& Gosh, this is //really// annoying. JW, any news from your general-purpose [[WikkaEmailToolkit email validation]] functions ;-) -- DarTar
~~&The basic problem is that the installer does not use any system routines but instead JavaScript for validation. And the RE it uses for email validation is really, really braindead. Yes, very annoying as I've not seen the user back in #wikka either - we may have lost a user. I could have given a workaround if only I'd not been sleeping. --- Email library is not quite ready but getting close (needs some restructuring, basically); it will be a class, with several abstract methods so the installer should be able to use it as well (provided it can find the class file). And I'm learning some good tricks working on the sessions module (which might also be useful for Wikka). But the installer needs a major overhaul in any case. Sigh... --JavaWoman
===Comments in formatted PHP code===
GeSHi has a habit of adding a trailing line if the PHP code contains a comment using ""//"" or ""#"".
For example %%(php) echo "hello world"; // How do you do?%% This does not happen if ""/* */"" is used for comments. For example %%(php) echo "hello world"; /* How do you do? */%%
-- FreekDijkstra
~&Sounds also like a GeSHi problem rather than a Wikka bug. If anyone is installing (or has installed) GeSHi 1.0.6 I'd appreciate feedback on whether this cosmetic problem is solved as well. --JavaWoman
My default installation of Wikka 1.1.6.0 did display the error
htmlentities(): charset `646' not supported, assuming iso-8859-1 in /home/www/WWW/files/research/air/wiki/3rdparty/plugins/geshi/geshi.php
on the FormattingRules page. I was able to fix this by adding the "set_encoding" line in the GeSHi_Highlight() function in wikka.php:
$geshi =& new GeSHi($sourcecode, $language, $this->config['geshi_languages_path']); # existing code
$geshi->set_encoding('UTF-8'); # set encoding (new line)%%
-- FreekDijkstra
~&This is actually not a Wikka bug, but a problem in GeSHi itself - which only appears in rare cases. See CharsetNotSupportedWorkaround for more information. I think the latest GeSHi version (1.0.6) has addressed this problem. If you'd like to try this, make sure you remove the workaround code in Wikka when installing the new GeSHi version. --JavaWoman
===User name matching===
(related to the //Category name matching// item below)
While [[RegisterActionTest testing]] the beta RegisterAction, I realized that using a username like **""DarTartar""** results in a //"Sorry, username already exists"// error. Looks like a problem in the RE used by the ##""LoadUser()""## function. I'll take a look at it ASAP.
-- DarTar
===Multiple wikka installations on one host: Login security hole?===
Okay. Say that I've installed multiple seperate installations of wikka on one host. If I do a login on wikka A, I can also
reach the pages of wikka B, whereas wikka B has an authentication table where the user account of wikka A does not exist!
My guess is that this behaviour occurs because the login cookies are set with path root. And as long the login cookies exist
Wikka doesn't care about authentication anymore??
-- JeroenJansen
~&Same problem. Is it possible to include in wikka.config.php a line in which you specify the default cookie prefix? I guess this could solve the problem. --YanB
~~&Same problem for me as well. I've modified wikka.php to use different session names (add: session_name($wakkaConfig["wakka_name"]); just above the session_start(); ) and different cookies ("wikka_user_name@".$this->config["wakka_name"] and "wikka_pass@".$this->config["wakka_name"]) as my 2 wikkas do have have different wakka_names. Seems to behave as expected now. --OlivierPerron
===Category name matching===
Yes, I know the category system needs to be revamped, but I figured I'd report this anyway. If you have a category name that is a substring of another category name, pages referencing the second category will also appear in the first. In other words...I have a category named '""CategoryBookOne"", and another named ""CategoryBookOneJournal"". Pages that reference ""CategoryBookOneJournal"" also show up in the list of pages for ""CategoryBookOne"", which is not the behavior I expected or wanted.
-- TammyCravit
~&I cannot reproduce this on this server, nor on my own development system - at least not with the [[WikkaBetaFeatures beta and alpha]] versions of the category action. Possibly dependent on the version of PHP used where older versions may use a slightly different database query to find pages referring to a category. Tammy, if you're reading this: which version of PHP are you using? (We should test with the 'lower-PHP version of the query!) --JavaWoman
Gathered from error reports in different places (including comments on WikkaInstallation, #wikka and IM) - neither new, but worth repeating and putting together, I think:
~-In at least some cases the "detected" base path misses a closing slash (resulting in links that don't work); the installer should check if the derived path has a final slash, and if not, add one, before presenting that to the user.
~-If PHP (and thus Wikka) cannot connect to MySQL the installer just "hangs" after the first screen and printing "Testing configuration"; this seems to be (at least partly) the result of having error messages from the MySQL statements suppressed with a @, which would be OK if the error message were handled afterwards - but this doesn't happen. Other mysql_xxx() calls in the installer also have the @ suppressing error messages. That should either be removed, or all error messages should be picked up and handled by the installer, at the very least by showing the message to the user. ---
~This is especially a problem for users new at MySQL or new even at PHP+MySQL for whom it won't be obvious where to start troubleshooting when the installer simply hangs.
--JavaWoman
===mod_rewrite issue in WikiEdit===
When in edit mode using IIS if you click the help button the program doesn't take you to the FormattingRules page, but tries to go to the ""FormattingRules"" Directory, which does not exist.
~& It assumes that you're using mod_rewrite and goes to the "pretty" url (wikka.jsnx.com/""FormattingRules"" instead of wikka.jsnx.com/wikka.php?wakka=""FormattingRules"") - this needs to either be editable (or is it somewhere in the WikiEdit files and I just haven't found it?) or check with the wikka.config.php to make sure it's using the correct base_url. --MovieLady
===Bug in Textsearch (expanded)===
As DotMG has pointed out, the input for this two actions isn't validated, making it a security-hole.
You can fix it by changing the line
$phrase = stripslashes($phrase);
into
$phrase = preg_quote($this->htmlspecialchars_ent(stripslashes($phrase)), "/");
You have to change both files (textsearch and textsearchexpanded). --NilsLindenberg
===Advanced search results reveal confidential info===
Results should be hidden or not shown if the user doesn't have read access to page IMHO. --PolVazo
===Recent[ly]Comment[ed|s] actions should check for permission===
Comments are being previewed even if users do not have access. A simple check needs to be added. -- JsnX
if ($this->HasAccess("comment"))
===tags in the edit-notes===
I made a edit note: "removed a <?php (to much)" and got "removed a". Perhaps replacing <> would be the better option? --NilsLindenberg
~&Funny - I just stumbled over the same problem - only in the RecentChanges newsfeed: the <?php causes imbalanced tags there, and thus a syntax error: until that post has "aged" off of the feed, it can't be loaded any more! The [[http://feedvalidator.org/check?url=http%3a%2f%2fwikka.jsnx.com%2fRecentChanges%2frecentchanges.xml validation result]] clearly shows what the problem is. So yes, edit notes should be fed threough htmlspecialchars[_ent]() everywhere they're presented, and that includes the RSS feed! --JavaWoman
~~&And the WikiPing, too :) --NilsLindenberg
~&Oh is **that** what you removed Nils. I couldn't figure out using history what you did. Where did you take it from? And why? Did I have one more <?php than was necessary? In which code block? --GmBowen
~~&It was at the beginning of mail.php: %%(php) <?php <?php%%. I guess you overlooked it when you copied your new version to the page. Happent to me in another case, too. --NilsLindenberg
(copied from the sandbox --NilsLindenberg)
not support 2byte language in the Code formatters!!!!
%%(c)
// 한글이 깨지겠지
// 진짜 깨지네.. 흑흑.. 에디터창에서 깨지는 것도 열받는데..
...
Line 46 :
- Code generates a double </a> for links.
- & in URL should be replaced by &
=> %%(php) print("<td valign=\"top\">" . (($site != "unknown") ? "<a href=\"http://".$this->htmlspecialchars_ent($site)."\">".$this->htmlspecialchars_ent($site)."</a>" : $site) . /*"</a> ".*/($IsAdmin ? "[<a href=\"".$this->href("delete_referrer", "", "spam_site=").$this->htmlspecialchars_ent($site)."&redirect=".$this->GetMethod()."\">Blacklist</a>]" : "")."</td>");%%
Note: You cannot see this error by validating directly a page because W3C is not registered and it will not have the same output as you, in other words, code on line 46 won't be executed. But you can save the page on your hard disk and validate it.
--DotMG
**Not really bug, but should be corrected for respect & compliance to RFC2616**
If a browser sends the header
Accept-Encoding: gzip;q=0, deflate
Which should be interpreted as : "I don't support gzip encoding, but I prefer deflate", Wikka will understand "The browser supports gzip-encoding", as it just searches for the text gzip in $_SERVER['HTTP_ACCEPT_ENCODING']. An example I use to treat it correctly is :
%%(php) function ParseHeaderLine($hl, $token=null)
{
$ar_hl = explode(',', $hl);
foreach ($ar_hl as $dotmg_idx => $val)
{
if (preg_match('/^\s*(.*?);\s*q\s*=\s*([0-9\.]*)/i', $val, $match))
{
$res[strtolower($match[1])] = doubleval($match[2]);
}
else
{
$res[strtolower($val)] = 1;
}
}
if ($token) return(isset($res[$token]) && ($res[$token] > 0)); #if $token is set, we return true or false
return ($res); # else we return the header parsed.
}%%
and
%%(php) if ($this->ParseHeaderLine($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ...%%
Note : This function might be useful to deal also with Accept-Language, when Wikka will be made effectively multilingual.
--DotMG
A page contains unicode characters looks OK when viewed but displays ""''&#*****;''"" while edited in WikiEdit
Simplified Chinese Test:
中文是一种美丽的语言，除了具有音节上的美感，同样拥有视觉上的美感
In 1.1.5.3, I solved this problem by changed some line in ./handlers/page/edit.php
#from
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$body."</textarea><br />\n"
#to
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$this->htmlspecialchars_ent($body)."</textarea><br />\n"
Wikka is wonderful! ZhuangYuyao
~&This workaround you outlined will work as well in Wikka 1.1.6.0. A real solution wil take some more investigation though, so we were unable to fix this for the current release. This is now under investigation. --JavaWoman
I noticed: Turning off DoubleClick-editing does not work (double-clicks still go to edit-window) in IE 6.0 or Firefox 1.0.
Keep up the good work!
Cheers, MarkHissinkMuller
~&Yes, I noticed the same thing. This is a bug as of 1.1.6.0. --RyanKnoll
~~&Heres the fix:
~~&add as **first** line in handlers/page/show.php:
~~&%%(php)
<?php $user = $this->GetUser(); ?>
~~&and change the second line to:
~~&%%(php)
<div class="page" <?php echo ((!$user || ($user["doubleclickedit"] == 'Y')) && $this->GetMethod
() == "show") ? "ondblclick=\"document.location='".$this->href("edit")."';\" " : "" ?>>
~~&--NilsLindenberg
DarTar and I have recently created some test pages, testing page names related to how Wikka evaluates 'valid' page names: ,My,Page and ÄhnLich (yes, they both exist, even if they don't show up as such in this sentence!). Now look at where they show up on PageIndex... surely there shouldn't be **two** '#' indices??
--JavaWoman
~&I think that this is due to the encoding of the MySQL tables. I can't see how that would be fixed with a small touch on the code. If this is the matter then I hope that it also rings the i18n bell too. //Translation to Greek is my bussiness ;)// --GeorgePetsagourakis
~~&Yes, my i18n bells were already loudly ringing... but you bring up a good point with MySQL. I hadn't thought about a real cause yet, just wanted to record what I saw before I got distracted again ;-). Sort order is a whole subject of its own within i18n .... --JavaWoman
First, this may applied to my ISP only. When I installed, I have to use
the ?wakka= options. However, I have to add a / to the end of the
default Basic URL before append ?wakka= to it. So I think it maybe
helpful to modify the instruction to '... so it should include
the "/?wakka=" parameter...'
~&ArpY: Maybe this is caused by a config error. Please have a look at your config - is there a slash at the end of the base_url?
~~&IMO the installer should take care that there is a slash if the user doesn't enter it --JavaWoman
Um, I don't know how to describe this really. Put ""{{include page="Category Documentation"}}"" (//without the space!//)on the SandBox page....I can't figure out why it gives that output as Sandbox doesn't own anything.
~&Looks like the weirdness is caused by the ""{{Category}}"" action which assumes the "current page" represents the category - and find pages "belonging to" a category by finding a mention of that page name. Good sign our category system does need an [[CategorySystemOverhaul overhaul]]! --JavaWoman
~&Include pulls in a page that itself has the category action on it; the "official" version of this action assumes that the page it occurs on **is** a category. The "//experimental//" category action that is now active on this site no longer makes this assumption but recognizes that SandBox isn't a category page and defaults to the top category. See Sandbox for a an example (at this moment). --JavaWoman
~~&I can see that it now works, but what do you mean that it "recognizes that Sandbox isn't an action".....do you mean target page? --GmBowen
~~~&Oops, sorry (corrected now) - I meant the new category action sees whether the page it's "sitting" on is a category page or not - if not it defaults to showing the list for the top-level category. --JavaWoman (aka IamBack)
===Backlinks / ""LoadPagesLinkingTo()""===
I just discovered that the ##""{{backlinks}}""## action may list pages that don't "exist" any more, in the sense that they (apparently) still are in the database but without any active version (seemingly as a result of a rename action. I added an example on [[JavaWoman my own page]] where you can see a supposed backlink from ReleaseNotes (which was replaced by WikkaReleaseNotes).
~&The cause is apparently in the ""LoadPagesLinkingTo()"" method which is used by ##""{{backlinks}}""## action. It currently is implemented like this:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' order by tag"); }
%% I think replacing this by:
~& %%(php) function LoadPagesLinkingTo($tag) { return $this->LoadAll("select from_tag as tag from ".$this->config["table_prefix"]."links where to_tag = '".mysql_real_escape_string($tag)."' and latest = 'Y' order by tag"); }
%% might do the trick to avoid deceased pages - but please test!
~&--JavaWoman
~~&It wont do, since the link-table has no latest col ;). But shouldn't the delete-handler delete these links from the table anyway? --NilsLindenberg
====GetEnv is not a good idea!====
At ./wikka.php, you will see a line %%(php)<?php if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";?>%%
In the most cases, a website is hosted in a machine as a VirtualHost, this means that a number of websites share the same environment variables. If someone knows where your site is hosted, he can put his site at the same server, and use a script containing %%(php)<?php putenv('WAKKA_CONFIG=/home/hacker/config.php');?>%%. And all wikka sites on the same server will use his configuration file. The rest actions to take to hack your site will be as easy as eating sandwich.
Php doc says that an environment variable is altered only during the life of the script, but with my dev Easyphp's on windows, that is false. (I think a "new" environment variable keep its value, even on Linux).
I wanted to make a unique Wikka interface used by 3 sites on the same server. The best secure solution I found is to alter ./wikka.php like this :
%%(php)<?php
if (file_exists("wakka.config.php")) rename("wakka.config.php", "wikka.config.php");
#if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";
if (!$configfile && isset($GLOBALS['wikka_config'])) $configfile = $GLOBALS['wikka_config'];
if (!$configfile) $configfile = "wikka.config.php";
if (file_exists($configfile)) include($configfile);
and put the 2 files sitenumber2.php and .htaccess below at the root of the server number 2:
__sitenumber2.php:__
%%(php)<?php
$GLOBALS['wikka_config'] = "/path/to/altered_config.php";
chdir("/path/to/basewikka");
include('wikka.php');
?>%%
__.htaccess:__
%%<IfModule mod_rewrite.c>
RewriteRule ^(css|images|wikiedit2)/(.*)$ /path/to/basewikka/$1/$2 [L]
RewriteRule ^(.*)$ sitenumber2.php?wakka=$1 [QSA,L]
</IfModule>%%
--DotMG
~&I've now written up my thoughts about a [[WikkaSecureConfig more secure way to handle Wikka's configuration]] (which should also provide also more flexibility). --JavaWoman
===Expanded Text Search fails===
I tried an expanded Text-Search after [[http://wikka.jsnx.com/TextSearchExpanded?phrase=%2Bparameter+%2Blink +parameter +link]] and got the following error:
"Warning: Compilation failed: nothing to repeat at offset 1 in /.../actions/textsearchexpanded.php on line 33"
for every page.
--NilsLindenberg
~&In my recent RE exploits I have found that a warning of this type comes up when a regular expression isn't quite correct (though not every attempt to match may bring up the warning); haven't investigated further in textsearchexpanded.php though. --JavaWoman
~&Php has a function : preg_quote that may help us. Or try this solution : DotMGTextSearchExpanded
Looking at **formatters/wikka.php** to find the cause of the two bugs listed below (found one), I notice to my horror that a **lot** of the regular expressions used there are actually incorrect. They allow such things as using a comma to indent a line (in addition to a tab, or ~, at the start of a line: **demo** in the SandBox, and in the list **below**!), or a comma in a WikiName (even at the start) or in an InterWiki link. That can't have been the intention - it's simply a matter of incorrect RE syntax. I'd become sort of "sensitized" to this phenomenon looking at DarTar's RE on ValidPageNames earlier today - now I see where he found an example (see my comment on that page on his RE!).
''See also [[,My,Page]] - yup, that's a real page now. ;-)''
~&Rather than simply fixing all the REs (and other REs all over the place...) I'd like to propose a more fundamental solution:
~&-create a "library" of RE building blocks to be used in the Wikka core (for an example of what I mean with building blocks see my propopsal for an alternative RE on ValidPageNames); simply create a separate file with define()s for these building blocks, and include them at the start of the main wikka.php file;
~&-gather all RE used in the Wikka core here (extensions/plugins could have their own set of defines - as long as they don't have conflicting names);
~&-now use **only** these building blocks when using REs anywhere in the Wikka core.
~&This should make it much easier to create both //correct//, and //consistent// regular expressions; any (near)duplicates will be much easier to discover, and fix.
~&
~&Probably best to leave this to just **after** the coming release, so we have a stable code base again. I volunteer to undertake this work. (Unlike some people, I happen to like REs.) :)
~&--JavaWoman
Have a look at the source of WikkaDevelopment, you will see that tabs and unordered lists for some reasons are not correctly parsed (actually after one edit, tabs were added at the beginning of each line). I'll try to figure out why this happens...
-- DarTar
~&Possible clue:
~&I just stumbled over the fact that the little list of "Useful pages" at the end of the default (installation-generated) ""HomePage"" had incorrect coding: The last list item (li) was not terminated, nor was the list itself (no closing ul tag). It took me a bit of trial and error to reproduce this - but have a look at my test code at the end of SandBox (now). Originally I thought that any list at the end of a page would be unterminated, but that turned out not to be the case. Then I hit on something else: the last list element on that default ""HomePage"" (not the one here) ands with a period. My test version on SandBox now also has the last element ending in a period ... and if you look at the (HTML) page source, you'll see it is indeed an unterminated list. Somehow that ending period (maybe in combination with end-of-page?) causes the Formatter never to close the list; take that ending period away, and it works normally. I tried a few variants, to check whether it might be an odd-even problem, but no: whether the number of list items is odd or even, if the last one ends in a period, the list isn't terminated.
~&
~&No difference whether it's anordered (ol) or unordered (ul) list, the formatter behaves the same way.
~&
~&And, BTW, if you look at the preview when editing, the HTML source of the **preview** actually contains a lot of Wiki code that shouldn't be there!
~&
~&I haven't dug in the Formatter yet to find the cause or whether end-of-page makes a difference...
~&--JavaWoman
~~&This is indeed an "end of page" problem: teh formatter has some code to close tags inadvertently left open, but does not do this for lists and indent (nor even fro *all* open tags). Fix coded and tested - this will be in 1.1.6.1. --JavaWoman
MySQL 5+ isn't supported as it requires PHP to use the mysqli extension instead of plain old mysql. I hoped there would be a single file to change this, but there seems to be no database abstraction in this project at all.
-- DavidCarrington
~&I do not have access to a MySQL 5 server for testing. And judging by the feedback that I see here on Wikka, most other Wikka admins are using older versions of MySQL. However, I do like progress, so I looked at the documentation for the mysqli extension. I don't see any major issue here. It looks like the function calls are the same, they just have a different name. Instead of calling mysql_connect, you call mysqli_connect. Instead of calling mysql_query, you call mysqli_query. So on and so forth.
~&
~&It seems that we would just have to do a simple version check and call "mysql" functions for older versions, and "mysqli" functions for newer versions.
~&
~&Please correct me if I'm missing something. -- JsnX 26 Nov 2004
~~&I'm running MySQL 5 fine with the mysql_* functions. When you compile PHP, it's your choice to compile the mysql_* or mysqli_* functions. I chose to compile it with mysql_*, which is working fine for me. --BarkerJr
==Login Problem==
==User search - should be case-sensitive==
===Email Addresses===
Found several issues with how email addresses are validated / accepted / used; outlined on WikkaAndEmail - and I'm working on solutions. (Email is //complicated// and there's a whole bunch of standards (RFCs) involved.)
First part of the solutions now in WikkaEmailToolkit; while the toolkit is still incomplete, what's there now can be used as presented there (no dependencies on later components).
-- JavaWoman
Deletions:
<p>If you have something to report:<br/>
<strong>First</strong> check if your issue is already being discussed on this page:</p><ul>
<li>If so: check if it has a link to a ticket:<ul>
<li>If so: <strong>follow that link</strong> and add your comment there</li>
<li>If not: add your comment to the issue <strong>on this page</strong></li></ul></li>
<li>If not: please use the <strong><a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a></strong> to report your <strong>new</strong> bug or issue. Again, <a href="http://wush.net/trac/wikka/search?ticket=on">search first</a> to make sure your issue has not been reported yet.</li></ul>
</div>""
<<==Read this first==
~-workarounds for unusual problems and temporary fixes for known bugs are listed at WikkaWorkarounds
~-general help can be found on the [[Docs:WikkaDocumentation Wikka documentation page]]
<<::c::
===== {{done}} Bugs reported on the tracker =====
[[Ticket:13]]
[[Ticket:79]]
===Valid Email Addresses===
[[Ticket:80]]
[[Ticket:13]]
=== Indenting not working properly in handlers/page/edit.php ===
[[Ticket:85]]
[[Ticket:88]]
[[Ticket:1]]
[[Ticket:34]]
[[Ticket:80]]
See CharsetNotSupportedWorkaround
[[Ticket:90]]
===Purging should not remove the whole history of a page===
[[Ticket:93]]
[[Ticket:95]]
[[Ticket:97]]
[[Ticket:100]]
[[Ticket:104]]
[[Ticket:108]]
[[Ticket:231]]
[[Ticket:232]]
===Code tag % % ... % % problems===
[[Ticket:783]]
===== {{todo}} Bugs still to be checked/migrated =====
===the Blank on IE browser===
i just tested it on IE,firefox,opera;but only on IE it sometimes got blank page,nothing displaed,no code on it(so i think it's not coz the insert ads host,and my host don't gave ads).this not happened always,when you click the links,go to the new page,got a blank,then refresh it,it displayed.no this problem on firefox or opera.
but which is interesting,on your official site of Wikka,there is no this problem with IE blank.is there something wrong with the File permission?(exhausted with it),but when refresh the blank page,it displayed.
~&Details like the versions of your IE, your webserver and Mysql (and perhaps a link to the page) would be helpfull! NilsLindenberg
===remote (or local) won't load Wikka===
I just installed Wikka and it works fine on the localhost.
But if I want to access it from another machine, being it on the LAN or internet, I got an error message saying "connection refused when attempting to contact localhost."
my config setting is
"base_url" => "http://localhost/wikka/wikka.php?wakka=",
"rewrite_mode" => "0",
If I change the localhost to mydomain.com, I can access it from internet, but I can't load it on my localhost.
It's one or the other. Is there anything I did wrong?
~& Hi, this is a problem that depends on your server configuration and how it resolves virtual hosts. It is in no way a Wikka bug. You should contact your network administrator to address this issue -- DarTar
~~& I don't think so. I tried MediaWiki and it works fine. I can serve my web pages and that's fine. My server is behind a cable modem and a router. All ports are forwarded correctly. But I really think that the "base_url" syntex caused this problem.
~~~&Since you say you can access your site from the Internet if you use "base_url" => "http://mydomain.com/wikka/wikka.php?wakka=", you could simply edit your hosts file on your local machine and map mydomain.com to 1.0.0.127 - that way you can access the site on your local machine the same way as from the Internet. For accessing it from other machines on your LAN you may need to add a similar mapping (to the hosting machine's local IP address) to access it from there. -- JavaWoman
The following is a solution copied from comments of WikkaInstallation that I think resolves this issue (have not tested it though) --GiorgosKontopoulos 16/03/2006
The following solution will allow Wikka to work for a site that can be reached by multiple domain names (for example, a server that has one address when accessed via an intranet and a different address when accessed from the Internet):
Edit wikka.php.
//After
$wakkaConfig = array_merge($wakkaDefaultConfig, $wakkaConfig);)
//add the following line:
$wakkaConfig[base_url] = "http://".$_SERVER["SERVER_NAME"].($_SERVER["SERVER_PORT"] != 80 ? ":".$_SERVER["SERVER_PORT"] : "").$wakkaConfig[base_url];
Then, edit wikka.config.php and set base_url to contain just the path of your Wikki instead of the full URL
"base_url" = "/wikka/",
I may be reinventing the wheel here. It would be good if Wikka actually had a config option to autodetect the domain or require it in base_url. --Vincent -- 65.242.114.226 (2006-02-06 18:52:54)
===Wikka and WebDAV===
I've found that the .htaccess file (i think) prevents me from accessing a wikka folder using MacOS X's in built webdav client. I imagine that if the Rewrite stuff was less catch-all it might not have this effect, letting me edit wikka templates with ease rather than the terminal... thanks tom
Now.. and I don't get this... THIS has fixed it.. and it doesn't even seem to make sense (my install is in a folder called Wikka)... but when I try and change it ... it stops working again... My .htaccess file looks like this...
""RewriteEngine"" on
# ""RewriteCond"" %{REQUEST_FILENAME} -d
# ""RewriteRule"" ^(.*/[^\./]*[^/])$ $1/
""RewriteCond"" %{REQUEST_FILENAME} -f [OR]
""RewriteCond"" %{REQUEST_FILENAME} -d
""RewriteRule"" ^(.+) - [PT,L]
""RewriteCond"" %{REQUEST_URI} !/(Wikka/css|/Wikka/files|actions|dav|handlers|pages)
""RewriteRule"" ^(.*)$ wikka.php?wakka=$1 [QSA,L]
..... I don't get this... but hey, if it works...
===Wrong Links===
I get Links like
http://localhost/~ckl/Wikka/wikkaHomePage
http://localhost/~ckl/Wikka/wikkaCategoryCategory
and so on, instead of
http://localhost/~ckl/Wikka/wikka/HomePage
http://localhost/~ckl/Wikka/wikka/CategoryCategory
~& Open ##wikka.config.php## and check the value for ##base_url##: it should be ""http://localhost/~ckl/Wikka/wikka/"". BTW, you may also want to read ModrewriteInSubdirectoryWorkaround. Hope this helps -- DarTar
~~& Thank you for the help.
~~& If I use http://localhost/~ckl/Wikka/wikka/ the links are correct,
~~& but the css file is not found and I get messages like //Unknown method "page/HomePage.php"//. ModRewrite is off.
~~& If I use http://localhost/~ckl/Wikka/wikka the links are not correct and if I click HomePage I get
~~& Not Found The requested URL /home/ckl/public_html/Wikka/wikka.php was not found on this server.
===Logout fails silently or takes long time on ""SourceForge"" hosted site ===
Here are the symptoms :
When you click on the **logout** button, it returns to UserSettings page but does nothing.
You can browse other pages, it keeps saying 'You are XXXX' even after logging out.
IMHO, I think it may be a problem with the ""SourceForge"" hosting space as I've tried logout/login on different Wikka sites already hosted by ""SourceForge"" -> same issue.
On my local LAMP, it works fine so I suggest there are some PHP, MOD_PHP, APACHE issues on ""SourceForge"".
--PhilippeVincent 10 Aug 2005
~& it may not be a bug since i noticed there are some problems with mysql on sourceforge.
~& when a query takes too long, the server just cut the connection.
~& So, if the logout process takes a bit too long according to the short mysql latency, it fails over...silently.
~& --PhilippeVincent
~& I'm also get the same error 403. I tried KoG workaround but it gives error 500 (Internal Server Error). The only solution that works with me to delete .htaccess file. Is this implies security risks? I don't know till now. --Ikhnaton2
~~&There is no //security// risk with removing .htaccess. In fact, only the Apache web server can do anything with it but Wikka can function just fine running on other webservers (even IIS :)). Also, there are hosting plans where Apache is used but the use of .htaccess is not allowed - which might result in it either being ignored, or possibly a 403 error. So, while a .htaccess file (with Apache) may make life with Wikka easier (some spam defense, and pretty URLs) it's safe to remove it.---That said, if adding ##""Options +FollowSymLinks""## changes the 403 error into a 500 error, you might want to check the ServerErrorWorkaround page (and look at ModrewriteInSubdirectoryWorkaround as well). --JavaWoman
~~~&IIS7 is supposed to support something akin to htaccess. But yes, some apache installations don't allow for overriding either. I those cases you'll need to speak with your administrator, or find a different/better host. Of course, Wikka works fine without mod_rewrite. As for the other portion of .htaccess, it's for stopping spambots. Of course, if you set your Wikka ACLs so only registered users can post/comment (as necessary and appropriate to your purpose), you should be ok. If you find yourself hammered by Wiki-attacking bots, adjust your security as needed (or talk to JW - she's been dealing with spammers I think) --KoG
~~~~The .htaccess should probably be removed or renamed in the distribution. Once upgrading to 1.1.6.2 i wasn't able to use wikka untill i removed the htaccess file that it comes with.-BrendonB
~~~~~&Can't confirm that, as the 1.1.6.2Alpha, 1.1.6.2Beta, and the 1.1.6.2-released all worked without the .htaccess file being an issue on my system. --WazoO 11Jul06
===Login Problem===
===User search - should be case-sensitive===
