Revision [9654]

This is an old revision of WikkaBugs made by JavaWoman on 2005-06-27 07:00:35.

 

Bugs/Issues discovered in Wikka!

Last edited by JavaWoman:
accesskey on comments
Mon, 27 Jun 2005 07:00 UTC [diff]

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
Attention:
For problems with foreach in PHP version 4.3.10:
See WikkaBugsResolved
 

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.
 



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


.htaccess settings yields consistent error 403 on Apache

Original issue: running Apache 2.0.54, with the presence of .htaccess file I kept getting error 403. Originally I moved .htaccess and set the base page in the conf to using the long url. After looking around I realized that the fix, in some instances (see requirements below) is to set the option FollowSymLinks to on in your .htaccess file.

Problem: your Apache configuration files don't have FollowSymLinks on

Solution: use the .htaccess below IFF (if, and only if) you have the following options set in the configuration file for the directory: AllowOverride Options or AllowOverride All, because you're going to need to override the settings in your local .htaccess file.

### STOP REFERRER SPAM
SetEnvIfNoCase Referer ".*(adultsite|picturesplace|learnthebiz|pi-o|erotica|ghettoinc|port5|bulk-email|camgirls|paris-hilton|modelos|kredit|handyflirt24|versicherung|wwww|erotower|krank|x-1000|flirtnet|blowjob|agedwife|in-the-vip|boysfirsttime|milf|captain-stabbin|tranny|Kontakt|erotik|fetish|frauen|hardcore|fick|krankenversicherung|jinnan-cross|8thstreet|xxx|XXX|ficken|fuck).*" BadReferrer

order deny,allow
deny from env=BadReferrer

<IfModule mod_rewrite.c>
 Options +FollowSymLinks
 RewriteEngine on
 RewriteCond %{REQUEST_FILENAME} -d
 RewriteRule ^(.*/[^\./]*[^/])$ $1/
 RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L]
</IfModule>


The + is optional, but I chose to put it in since I'm overriding default settings.

--KoG

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


Wakka formatter: Indenting on first line

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

I saw the source of the problem : Find the checkKey() prototype in file protoedit.js, and just add "k==53+2048 ||":

ProtoEdit.prototype.checkKey = function (k) {

if (k==85+4096 || k==73+4096 || k==49+2048 || k==50+2048 || k==51+2048 || k==52+2048 || k==53+2048 ||
k==76+4096 || k==76+2048 || k==78+2048 || k==79+2048 || k==66+2048 || k==83+2048 ||

--DotMG


No Registration Wikki

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:
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:
<li><div class="de1"><span class="coMULTI"></span></div></li>

while an empty line elsewhere results in
<li><div class="de1">&nbsp;</div></li>

Note the &nbsp; 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 &nbsp; 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. Example -- Rick


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


Purging of pages not always happening

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


RSS feed action hangs or crashes browser if feed does not exist

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"



Messages delayed

copied from #wikka
- well, some slight weirdness where i seem to get logged out without asking to
- and some other weirdness where i make a change, such as claiming ownership of a page, but then get a javascript notification several pages later
- cookie related problem? (firefox 1.0.1 on OSX).


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


ACL Cancel

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


Admin email at installation

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)


Email forgotten password action


I tried with 2 different emails on this site (jsnx.com) to have a temporary password sent to me ('Forgot password?' etc.), and I never received anything. I have the same problem with other wikkas on several servers. Am I crazy, or does this action actually send something which... nobody ever receives? :-( --YanB


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
 echo "hello world"; // How do you do?
This does not happen if /* */ is used for comments. For example
 echo "hello world"; /* How do you do? */

-- FreekDijkstra


Encoding of GeSHi

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


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


Using compression

Moved here from a comment so it won't get "lost". --JavaWoman
Wikka doesn't work with zlib.output.compression = On, it would be nice if it did.
-- 81-178-214-34.dsl.pipex.com (2005-01-06 22:31:13)


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


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


Installer problems

Gathered from error reports in different places (including comments on WikkaInstallation, #wikka and IM) - neither new, but worth repeating and putting together, I think:
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


PHP5 + GESHI

Using PHP5 with the 1.1.6.0 release and the included GeSHI doesn't work. Once I updated GeSHI to the latest version, everything worked fine. --BrendonB


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.




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


Missing language-support in the code formatter

(copied from the sandbox --NilsLindenberg)

not support 2byte language in the Code formatters!!!!
// &#54620;&#44544;&#51060; &#44648;&#51648;&#44192;&#51648;
// &#51652;&#51676; &#44648;&#51648;&#45348;.. &#55121;&#55121;.. &#50640;&#46356;&#53552;&#52285;&#50640;&#49436; &#44648;&#51648;&#45716; &#44163;&#46020; &#50676;&#48155;&#45716;&#45936;..
...



Error on ./handlers/page/referrers_sites

Line 46 :
=>
            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)."&amp;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


Wiki Edit causes lockup

The new version of wikiedit here causes a lockup if I use either ctrl-B or click on the B link after highlighting text. I can go to earlier versions of wikka on my servers and it works fine. Back to wikka and it causes a lockup (no asterisks are inserted, no other formatting works either, so I have to close the window...which generates an MS window crash notification popup). I'm running XPPro with current updates for both XP & IE. -- GmBowen


Accept-Encoding: gzip;q=0, deflate

Not really bug, but should be corrected for respect & compliance to RFC2616
If a browser sends the header
Accept-Encoding: gzip;q=0, deflate
Which should be interpreted as : "I don't support gzip encoding, but I prefer deflate", Wikka will understand "The browser supports gzip-encoding", as it just searches for the text gzip in $_SERVER['HTTP_ACCEPT_ENCODING']. An example I use to treat it correctly is :
 function ParseHeaderLine($hl, $token=null)
 {
  $ar_hl = explode(',', $hl);
  foreach ($ar_hl as $dotmg_idx => $val)
  {
   if (preg_match('/^\s*(.*?);\s*q\s*=\s*([0-9\.]*)/i', $val, $match))
   {
    $res[strtolower($match[1])] = doubleval($match[2]);
   }
   else
   {
    $res[strtolower($val)] = 1;
   }
  }
  if ($token) return(isset($res[$token]) && ($res[$token] > 0)); #if $token is set, we return true or false
 return ($res); # else we return the header parsed.
}

and
 if ($this->ParseHeaderLine($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ...

Note : This function might be useful to deal also with Accept-Language, when Wikka will be made effectively multilingual.
--DotMG


1.1.6.0beta4: Simplified Chinese (or Unicode relative) in WikiEdit:

A page contains unicode characters looks OK when viewed but displays ''&#*****;'' while edited in WikiEdit
Simplified Chinese Test:
中文是一种美丽的语言,除了具有音节上的美感,同样拥有视觉上的美感
In 1.1.5.3, I solved this problem by changed some line in ./handlers/page/edit.php
#from
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$body."</textarea><br />\n"
#to
"<textarea onKeyDown=\"fKeyDown()\" id=\"body\" name=\"body\" style=\"width: 100%; height: 500px\">".$this->htmlspecialchars_ent($body)."</textarea><br />\n"

Wikka is wonderful! ZhuangYuyao


Double-click editing

I noticed: Turning off DoubleClick-editing does not work (double-clicks still go to edit-window) in IE 6.0 or Firefox 1.0.
Keep up the good work!
Cheers, MarkHissinkMuller


$_REQUEST problem


If this does not fit in this bug section as such, my apologies... I'd like to hear some comments on this though..

I initially noticed this after having a problem with the {{files}} action. When trying to download a (previously succesfully uploaded) I received this result: Unknown method "page/files.xml?action=download.php"

Digging through the code and printing out some variables I noticed the $_REQUEST (and $_GET) variable still contained part of the query string. See the example code below. I inserted a quick workaround in wikka.php but I'm interested in figuring out how and where this is caused.

My setup:
Apache/1.3.28
php (module) 4.3.7
wikka 1.1.5.3

url: /wakka/wikka.php/FileActionExample/files.xml?action=download&file=file.txt

<?php

print_r($_REQUEST);

/* print_r result
Array
(
    [wakka] => FileActionExample/files.xml?action=download
    [file] => file.txt
)
*/


//work-around $_REQUEST problem
if( preg_match( "/(^[^?]*?)\?([^=]*?)=(.*)/" ,$_REQUEST['wakka'],$matches) ){
    list(,$_REQUEST['wakka'],,$_REQUEST[$matches[2]]) = $matches;
    list(,$_GET['wakka'],,$_GET[$matches[2]]) = $matches;
    unset($matches);
}

print_r($_REQUEST);

/*
print_r result after work-around
Array
(
    [wakka] => FileActionExample/files.xml
    [file] => file.txt
    [action] => download
)
*/


?>


thanks, JoshJohn


PageIndex problem

DarTar and I have recently created some test pages, testing page names related to how Wikka evaluates 'valid' page names: ,My,Page and ÄhnLich (yes, they both exist, even if they don't show up as such in this sentence!). Now look at where they show up on PageIndex... surely there shouldn't be two '#' indices??
--JavaWoman


Install Note on Basic URL and CSS

First, this may applied to my ISP only. When I installed, I have to use
the ?wakka= options. However, I have to add a / to the end of the
default Basic URL before append ?wakka= to it. So I think it maybe
helpful to modify the instruction to '... so it should include
the "/?wakka=" parameter...'


This problem has been cropping up off and on in wikka for me recently (only at this site as far as I can tell...so beta code maybe??). Anyways, I noticed it today on the BannerMaker page. The follow three screen captures were done after multiple reloads of the page (the images didn't move with every reload). The weird part to me is that the "spacing" between them stays the same, but the images move up and down the screen.
http://gmbowen.educ.unb.ca/wikitest/bug.jpg http://gmbowen.educ.unb.ca/wikitest/bug2.jpg http://gmbowen.educ.unb.ca/wikitest/bug3.jpg


Weirdness with Include

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.


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



GetEnv is not a good idea!

At ./wikka.php, you will see a line
<?php if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";?>

In the most cases, a website is hosted in a machine as a VirtualHost, this means that a number of websites share the same environment variables. If someone knows where your site is hosted, he can put his site at the same server, and use a script containing
<?php putenv('WAKKA_CONFIG=/home/hacker/config.php');?>
. And all wikka sites on the same server will use his configuration file. The rest actions to take to hack your site will be as easy as eating sandwich.
Php doc says that an environment variable is altered only during the life of the script, but with my dev Easyphp's on windows, that is false. (I think a "new" environment variable keep its value, even on Linux).

I wanted to make a unique Wikka interface used by 3 sites on the same server. The best secure solution I found is to alter ./wikka.php like this :
<?php
if (file_exists("wakka.config.php")) rename("wakka.config.php", "wikka.config.php");
#if (!$configfile = GetEnv("WAKKA_CONFIG")) $configfile = "wikka.config.php";
if (!$configfile && isset($GLOBALS['wikka_config'])) $configfile = $GLOBALS['wikka_config'];
if (!$configfile) $configfile = "wikka.config.php";
if (file_exists($configfile)) include($configfile);

and put the 2 files sitenumber2.php and .htaccess below at the root of the server number 2:
sitenumber2.php:
<?php
 $GLOBALS['wikka_config'] = "/path/to/altered_config.php";
 chdir("/path/to/basewikka");
 include('wikka.php');
?>

.htaccess:
<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteCond %{REQUEST_FILENAME} -d
 RewriteRule ^(.*/[^\./]*[^/])$ $1/
 RewriteRule ^(css|images|wikiedit2)/(.*)$ /path/to/basewikka/$1/$2 [L]
 RewriteRule ^(.*)$ sitenumber2.php?wakka=$1 [QSA,L]
</IfModule>


--DotMG



Expanded Text Search fails

I tried an expanded Text-Search after +parameter +link and got the following error:

"Warning: Compilation failed: nothing to repeat at offset 1 in /.../actions/textsearchexpanded.php on line 33"

for every page.
--NilsLindenberg


Yet more formatter bugs

Looking at formatters/wikka.php to find the cause of the two bugs listed below (found one), I notice to my horror that a lot of the regular expressions used there are actually incorrect. They allow such things as using a comma to indent a line (in addition to a tab, or ~, at the start of a line: demo in the SandBox, and in the list below!), or a comma in a WikiName (even at the start) or in an InterWiki link. That can't have been the intention - it's simply a matter of incorrect RE syntax. I'd become sort of "sensitized" to this phenomenon looking at DarTar's RE on ValidPageNames earlier today - now I see where he found an example (see my comment on that page on his RE!).
See also ,My,Page - yup, that's a real page now. ;-)



List parsing bug?

Have a look at the source of WikkaDevelopment, you will see that tabs and unordered lists for some reasons are not correctly parsed (actually after one edit, tabs were added at the beginning of each line). I'll try to figure out why this happens...
-- DarTar



MySQL issue


MySQL 5+ isn't supported as it requires PHP to use the mysqli extension instead of plain old mysql. I hoped there would be a single file to change this, but there seems to be no database abstraction in this project at all.

-- DavidCarrington



Login Problem

I have several users that have trouble staying logged in using ie 6.0.XX.
--GregorLindner





User search - should be case-sensitive
I was going through user pages, and looked at the homepage by user DaN; clicking on the name does the TextSearch thing: http://wikka.jsnx.com/TextSearch?phrase=DaN which brings up a surprising number of pages, none of which have actually been touched by DaN, it seems (at least non of the ones I checked). Using the browser to search in some of the listed pages (and their revision history) I found hits on words like "dangerous" - and nothing else. This way, the user search feature isn't all that useful, I'm afraid. A whole-word search may be difficult, but could we at least make it (optionally) case-sensitive so that a search for a user name or page name doesn't bring up a host of spurious results?




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


CategoryDevelopmentSuggestions
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki