Suggestion Box


New Wikka Tracker available

We are happy to announce that Wikka has just opened a dedicated issue tracker. We are currently migrating open issues, bugs and feature requests from this site to the new server but this migration isn't complete yet.

Meanwhile, if you have something to report:
First check if your feature suggestion is already being discussed on this page:

  • If so: check if it has a link to a tracker ID:
    • If so: follow that link and add your comment there
    • If not: add your comment to the issue on this page
  • If not: please use the issue tracker to report your new feature suggestion.

Thanks for your understanding.


 

Issues often asked for
see also:

Language support

Ticket:340


Highlight text searched in a page

Ticket:281


Wikka markup inside tables
Ticket:230


Is There a way to consolidate a bunch of page updates (the actual content that is) onto one page?

Ticket:259


Static HTML for offline browsing

Ticket:177


Ticket:175


Edit comments displayed by user rights

Ticket:180

Please provide a way to add formatters, that don't get placed in '<div class = "code">'

Ticket:176



Note on edit, mandatory field

Question: note?
Ticket:114


Order of comments

Ticket:115


Own comments editing

Ticket:116


versioning of attachments

Ticket:118


Making PageIndex go faster

Ticket:117


Single-click restore of previous versions

Ticket:119


Signature

Ticket:121


Preview

Ticket:123


Generate ID in forms; allow class

Ticket:21


Ticket:73


Exclude certain CamelCase words from formatting

Ticket:191


Import WikiPedia database

Ticket:192


Color Formatting

Ticket:193


Separation of Wakka class from wikka.php

Ticket:161


Save Pages to PDF Format

Ticket:190


showing comments

Ticket:195


Ticket:196


RSS options

Ticket:197


wikiwyg

Ticket:44


Google Sitemap

Ticket:210


Clearing ACLs

Ticket:211


Online editing of mindmaps would be great

Ticket:212


%% in code blocks: a possible workaround

How to format code to get two % characters without space together?

Ticket:213


Robot Friendly Pages

Sending 403 headers

(related to the Search engine results inflation item below)
Ticket:258


The access-key for "re-edit

Ticket:234


LinkTails

Ticket:35



Search within the textbox

Ticket:578 (see also WikkaEdit)


Numbers as page names?

Ticket:8


Improved code for error messages in Action() method

Ticket:202


Language files

Ticket:340


mod_rewrite idea (.htaccess)

Ticket: 604


Create rewrite rules on install

Ticket: 604




Suggestions to be checked/migrated to the tracker


making user uploaded images more useful


have a look at my suggestion at FilesAction


Automatic conversion from HTML to WakkiWiki syntax

Does such thing exist? For a number of other Wikies, it does.
It should be nice (one could say, essential) to have this here, too.
--CsillagKristof

Files Management

copied from FilesManagementSolution --JW
Link to files, rather than upload? Would it be possible to add the functionality so that rather than store the files within the Wikki, there was an option box for 'link' as well as upload. This would be useful on internal wikki deployments where you want to avoid file duplication by allowing users to point at the file to create a link to that file on a separate internal server. - RogerD



Automatic summary

copied from Sourceforge --NilsLindenberg

Is it possible to display through an action a little summary of the categories and sub categories available from the page we are in ?


Improving Wikka


A nice list of suggestions can be found at: By Blood and bone.



Login using retrieved password

The password retrieved from forgotten password does not work for me. Is there some setting in php4 or mysql that would allow md5(md5(password)) == md5(password) to return true? Since the password sent is the hash of the clear-text password, the current line in usersettings.php compares a hash of the hashed password to the hashed password, I think. I've found the correct code elsewhere in usersettings.php.
// usersettings.php line 130 fixed
if ($existingUser["password"] == md5($_POST["password"]) || $existingUser["password"]==$_POST["password"])

This is the current version:
// usersettings.php current line 130
if ($existingUser["password"] == md5($_POST["password"]))

The first one works for me. Is there a problem with security in using that version?
-CharlotteFischer


Hiding anonymous host/IP from non-administrators

On the Wiki I run, it is not desireable for the IP/hostname of anonymous users to be displayed to just anyone. I've made a small modification to hide the IP/hostname of anonymous users to users that (a) Are not administrators, and (b) not themselves. In handlers/page/show.php, around line 80 you can find:
print("\t<div class=\"commentinfo\">\n-- ".$this->Format($comment["user"])." (".$comment["time"].")\n");
I modified this to:
if ($this->IsAdmin() || $current_user == $comment["user"] || $this->LoadUser($comment["user"]))
{
    print("\t<div class=\"commentinfo\">\n-- ".$this->Format($comment["user"])." (".$comment["time"].")\n");
}
else
{
    print("\t<div class=\"commentinfo\">\n-- Anonymous#".str_pad(dechex(crc32($comment["user"])), 8, "0", STR_PAD_LEFT)." (".$comment["time"].")\n");
}
And in actions/recentlycommented.php:
if (!$this->LoadUser($comment_by)) $comment_by .= " (unregistered user)";
was changed to:
if (!$this->IsAdmin() && $this->GetUserName() != $comment_by && !$this->LoaderUser($comment_by))
{
    $comment_by = "Anonymous#".str_pad(dechex(crc32($comment_by)), 8, "0", STR_PAD_LEFT);
}
And in actions/recentcomments.php:
if (strlen($comment["comment"]) > 120) $comment_preview = $comment_preview.".... ";
after this add:
if (!$this->IsAdmin() && $this->GetUserName() != $comment["user"] && !$this->LoaderUser($comment["user"]))
{
    $comment["user"] = "Anonymous#".str_pad(dechex(crc32($comment["user"])), 8, "0", STR_PAD_LEFT);
}


You will probably need to also update the XML handlers and the history page handler, but right now anonymous users cannot edit pages on my Wiki. (actions/recentchanges.php, handlers/page/really don't want them to have 2 seperate usernames/ passwords. Therefore ideally I would like the wikka to use the usertable from phpBB... Has anybody else done something like this? -- KiltanneN
    • One solution that I've used is to set up a registration page that registers the user into both the bulletin board and the wiki user tables. I've then removed the registration screens from each of the two. Users can then log into either of them using the same username and password. Of course, this only works when registering "new" users...one would have to write a script to copy existing users from the bulletin board into the wiki user tables for current users. --GmBowen
      • Not a bad idea - but breaks down for password changes and also name changes... I am going to try and build what I have described. I will make notes over here: UseThephpBBUserTable -- KiltanneN


Pages linking to nonexisting pages

As MovieLady pointed out somewhere, it could be usefull to see if there are pages linking to a non existing page (for example when you have renamed the page and have to update the links).

The following solution just prints out the links, without any other text ("the following pages link here") - which should be better placed in the backlinks action.

Change in handlers/page/show.php the lines with if (!this->page) to:
  1.     if (!$this->page)
  2.     {
  3.         print("<p>This page doesn't exist yet. Maybe you want to <a href=\"".$this->Href("edit")."\">create</a> it?</p>");
  4.         print $this->Action("backlinks")."</div>";
  5.     }
  • What's the </div> for? I see no opening <div>. --JavaWoman
    • it closes the <div class="page">. --NilsLindenberg
      • But I don't see an opening <div> - and this closing </div> is within an if clause. So when/where is that div opened, and when/where does it get closed when the condition is not true? Something wrong with the logic here, or you're not showing enough of the logic. --JavaWoman
        • Ok, I was a littler bit short here :) the show handler opens a <div class="page"> before doing anything else (like the "has access"/page is existing check). So it has to be closed (and actually is closed) in every one of the three cases (1. no access to the page 2.pages is not existing 3.pages is displayed). In the official version it is closed after the "create it". I just moved it to have the backlinks inside the page-class (should have written that earlier :) --NilsLindenberg.
          • All right :) I guess the show handler is just sloppily written. If you open a div no matter what conditions apply, then you also close it no matter what, i.e., opened outside the if statement, then close it also outside the if statement. Whatever you do inside the if statement should have no influence at all: if opened, you must close it, no ifs and buts. I guess it's not wriiten like that (yet...). One for the code cleanup list. ;-) --JavaWoman


Configurable name for Wikka engine

I think it might be interesting for many of our users if we gave the possibility - in the install/upgrade wizard - to
rename the engine from wikka.php to something else (for instance, index.php). This might be useful in cases where RR are off and the user wants to avoid long URLs: http://www.mydomain.com/wiki/wikka.php?wakka=HomePage can then become http://www.mydomain.com/wiki/?wakka=HomePage. The name should be specified as an option in wikka.config.php, for instance

 "wikka_engine" => "wikka.php", 


This option might also allow using different engines (say, different versions of wikka.php) on the same installation.
-- DarTar


Search engine results inflation

I have recently installed Wikka on my personal website. Everything works fine, except that the TextSearch link in the page header (which I masked through CSS - I don't want to hack the code) produces dozens of search results that I really don't want to be cached on Google. Same story applies to the revisions and history links that are cached on search engines: this is what happens in the case of our main server. I'd also would like to avoid default wiki pages (like SandBox, MyPages, UserSettings etc.) to be crawled and cached (simply setting ACLs to !*-!*-!* won't do the job). Maybe we should think of a way to allow the user to decide
what kind of content of her Wikka-powered site should be spidered by SE and what content should not. -- DarTar
  • I think I've suggested before that the SandBox should not be indexed - the way to avoid this would be to add the appropriate meta tag to the page's head. That concept could easily be extended by allowing a WikiAdmin (not the WikiUser!) to define a list of pages where such a meta tag would be inserted. Generating a little text note to the effect for all these pages could also go some way to discourage spammers. --JavaWoman


For Better Overview

1. It often takes too much time to check if a wiki has changed and what has changed. In the case of wikkawiki one has to check RecentChanges as well as RecentlyCommented. A combined page would be more convenient - RicharD


Generate page from an external database

As described in DynamicPageGeneration I'd like to create a mailling-like system to fill in pages containig custom fields with data from an external database or a simple table. This could be done through a few actions or by writing a new handler.
This idea can be extended to an inline editor to add/remove/edit entries in this external table if wikka store creditentials with write access in its own tables.
The main goal is to integrate data from an existing knoweldge base in a wikka based documentation repository.

DotMG insists about favicon.ico and robots.txt

Please add the following two lines to ./.htaccess
RewriteCond %{REQUEST_URI} !=/favicon.ico
 RewriteCond %{REQUEST_URI} !=/robots.txt
 RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L]
This will prevent /favicon.ico and /robots.txt from being redirected to wikka.php?wakka=favicon.ico
With these 2 lines, we don't have to modify wikka.php as suggested in FaviconDotIco --DotMG
  • It can be done more generically by simply preventing rewiting happening when the requested URL matches an existing file or directory:
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f

    The first line excludes any directory, the second any existing file (which would include robots.txt and
    any icon file - you do not necessarily have to use favicon.ico). --JavaWoman


Category Icons

Create a table which maintains a mapping between wikka categories and an associated predefined icon graphic. When the directive {category_icon} is used the category's icon is dropped into the page at the location of invocation. -KarmaTester
  • Karma, we are actually considering the possibility of integrating a set of GPL'ed icons (and the relevant actions/formatters) in Wikka. Stay tuned... -- DarTar
    • You're more than welcome to use our icon action and icons: WikiIcons which were copyleft from here. The icons were auto-generated from the SVG versions at various sizes, you can take what you want. Only problem is they are PNG's -great in ANY browser but IE!!! --IanAndolina
      • IE7 does support PNG's, IE6 and IE5.5 support it with a javascript solution, look in SmiliesAction for more on IE, PNG, image actions, icons etc.
    • Some more at IconsInWikka -- ChristianBarthelemy


Automatic Table of Content Generation

A table of contents {TOC} directive is replaced by an ordered list of defined headers in the wiki page. This makes it easier to navigate pages which are very long like this one. -KarmaTester

Security Verification Test from Wikini

On the top of most page handlers, the Wikini developers have:
// Vérification de sécurité
if (!defined("WIKINI_VERSION"))
{
die ("accès direct interdit");
}

I'm not sure what exactly this does, can anyone enlighten me; and if it is a good idea, then it should considered for Wikka too... --IanAndolina
  • This is to ensure that a hacker can't view a page directly, with url like http://wikka.jsnx.com/actions/recentchanges.php. If this technique is possible, he (the hacker) can send request to make your wikka site output error strings. But in wakka forks, this will result in handlers "page/recentchanges.php.php" not found, if rewriteengine is on. If else, I' ll test it and I'll tell you. The simplest workaround, if it's the case is to add a .htaccess file at ./actions, .handlers/page directories, with the content : Deny from all. --DotMG



Inherit ACL from 'parents'

Create a page and when creating a page from there, give the option to copy the ACL of the first page.
Should pages be linked in some form to some documents given the fact that Wikka is flat, not hierarchic.
ForTheLazy - chatlog and summary.
-- FreekNL
  • IMO the acl system has to be dumped and/or renewed/rewrittem to accomodate usergroups..
  • I have been thinking of presenting a modification that will actually implement this user managment system ..
  • having privileges for each page is making userprofile-specific-features on Wikka efficiently non-existant.
  • The ability to create custom usergoups ( aka levels, profiles etc. ) would enable the addition such features
  • ( ip/hostname display , access to special parts of the wiki and such .. ) -- GeorgePetsagourakis
See also HierarchiesAndInheritance for some background --JavaWoman


Paragraph instead of line-breaks

(copied from WhatsNew -- DarTar)
Why is it that the formatter creates line breaks instead of paragraphs? I've been trying to figure out a way to get Wikka to do this, but it may be nice for there to be some sort of option in a future release. Paragraphs tend to be more useful for doing CSS formatting.
-- ScumBle

+1 — semantically, Wikka's current lack of proper paragraphs and liberal sprinkling of line breaks is really undesirble. I made a hack-mod on my wakka some time ago in formatter/wakka.php (just after the preg_replace_callback):

$pattern2 = "/^(\040|\t)*(?!<|\040)(.+)$/m"; //matches any line with no <element> (and variable leading space) - assume a paragraph
$replace2 = "<p>\\2</p>";
$text=preg_replace($pattern2,$replace2,$text);

$pattern1 = "/^(\040|\t)*(<(?!hr|(\/|)h[1-6]|br|(\/|)li|(\/|)[uo]l|(\/|)div|(\/|)p).*)$/m"; //matches any <element>text lines not considered block formatting
$replace1 = "<p>\\2</p>";
$text=preg_replace($pattern1,$replace1,$text);


I don't know how that will affect wikka (it was designed for my formatting which is different to wikka slightly), and there is probably a much better way to do it (call a post-formatter?), but it is possible using a small modification at least... --IanAndolina
  • The above code places paragraph tags throughout the page, including within code blocks, which seems undesirable. If \n were treated as markup which wakka.php needs to transform into paragraph tags, code blocks wil not be changed, I think. I'll try it and post the code changes if it works. --PaulP
    • No, that doesn't completely work either. It leaves code blocks unchanged, but keeps text from returning to left margin after indented paragraphs. --PaulP



E-mail this page facility
--JamesMcl


Usergroups

(copied from WikkaDevelopment --Nils)
Yet another idea from me:
Usergroups. So i can create a group of users, and just write that group into the ACLs...
GregorLindner
- Take a look at GroupManagement (which doesn't seem to be finished) - or at ACLsWithUserGroups.


"In work" for Wikka-pages

(copied from WikkaDevelopment --Nils)
Add a page property, 'Status' [?] that can be used to facilitate code development within Wikka. Imagine a very basic CVS system. A user can change the status to "In use' while considering improvements to the code, and then change it to 'Available' when done. This may prevent this scenario:
  • Multiple users see the same code and concurrently start working on changes.
  • One user posts his changes.
  • Another user posts his changes without realizing that the code had been updated.
OR
  • Another user has to go back through his code and incorporate the changes made by the first user.
  • Comments:
  • Dangerous! Consider the following scenario: user has been hard at work all week, now it's Friday afternoon and there's some time to do an edit or three. User opens each page in a browser tab, marking all three as "in use" and starts to edit them. Clickety-click. Suddenly user realises he has to run to catch the train home. Run! On the train, user realises the three pages are still open in the browser and "in use". "No matter", thinks our user, "it's always quiet during the weekend and I'll get back to it first thing Monday morning. On Sunday afternoon, user plays soccer, as he always does, and breaks a leg, which he usually doesn't do. User is transported to hospital where he has to stay for four weeks. ... A bit exceptional maybe - but what do you do with "dangling in uses" and when (how) are they considered "dangling" in the first place? --JW
    • Good point, but this modification would be only an informational resource to facilitate user communication. Techically, users could still update the page any time they wanted. It would just be a courtesy to hold back if you saw that a page was 'in use.' I didn't mention it above, but I planned to also add a field that would timestamp when the status was last changed. So in your scenario, we would see that the page had been marked as 'in use' for several days and feel free to ignore it. However, this does bring up the idea that it would be good to also have a 'note' box available for updating the page status -- used for comments such as, "should have the code updated within a few hours." Better now? -- JsnX
  • I've got code/table changes done that indicate if anybody (other than oneself) opened the page to "edit" in the last 15 minutes. It's on an iteration that isn't "live" right now (it's part of an earlier installation of wikka that we just haven't brought the code forward from yet), but I can make it that way so you can test out the functionality if you want. Since much of our site will be geared towards small teams doing collaborative editing, it was designed so that editing conflicts would not occur. Let me know if you want me to get it installed at a test site. -- GmBowen
  • I agree, it's an important issue (some Wakka forks have already addressed the problem of concurrent editing) -- DarTar
  • JsnX: If it's purely informational, that's better; I thought the intention was some kind of locking. So you'd have something like:
    • -state: in use | available
    • -timestamp: in use since
    • -note: applies to the in use state only
  • Then - would the state apply to the logical page or to a particular version? If the latter, what happens if a page is reverted to that version? What happens to the state when another user goes ahead and edits the page anyway?
  • And I still think you'd need some kind of admin function to "clear" dangling in use states that are older than xx minutes/hours/days.
  • GmBowen: is yours completely automatic or user-initiated? What happens in the run off to catch the train scenario? -- JavaWoman
  • (i) it's purely informational, not a "lock"...it sets a red exclamation mark beside the page name at the top if the "edit" link (or double click) has been used in the last 15 minutes by anybody other than yourself (ii) it's automatic (iii) the "train scenario" can't happen. It doesn't check if "saved" or not, just whether an edit was started in the last 15 minutes. This means that if the person doing the edit hasn't saved in the last 15 minutes when editing then the exclamation mark isn't activated for another user. But, people should save edits every 15 minutes anyways methinks. It's not "foolproof", but was meant to avoid many sorts of common editing conflicts on collaborative documents. It's not a very "big" edit of the wikka code actually. The edit.php script timestamps the most recent version of the page when it is activated, and there's a small addition to header.php that checks when the page is loaded to see if the current time is < 15 minutes from that timestamp & if so shows an exclamation mark. Finally, there's a small linked graphic that "refreshes" the page beside "homepage" and the "edit" link (essentially, it's just a link to the page itself) so a user can check the edit status before deciding to edit it themselves. For server load reasons I decided to not have an automatic check (once every 5 minutes for example) since most people read & don't edit much of the time so it made sense more to encourage people to check edit status themselves. Of course, it would also be possible to have edit.php check to see if the file was edited in last 15 minutes and if so, ask the user if they wanted to continue with their own edit. Hmmm...I'll have to think about that. As it sits it worked pretty well when tested (but remember, I'm into small group collaborative writing tasks....I'm not sure how it would work if the pages were "open" to everyone). It originally took me several hours to write the code myself, but I'm sure it would take JW or DarTar or Jason maybe 30 minutes....and the code would probably be more efficient (I'm not a real coder remember :-( ) -- GmBowen (aka Mike) (I've now provided my code & mods @ [GmBowenRecentEditCheck] for people to play with)


Searching (in) comments

(copied from WikkaDevelopment --Nils)
Add the ability to 'search for all comments by user X'. How this might be useful: I want to find a comment by JavaWoman
(really?), but I can't remember which page it was on -- she's quite prolific! -- (I admit I'm easily distracted. What am I doing here, now!? :)) so I use this new function to list all of her comments.


(copied from WikkaDevelopment --Nils)
It would be good if the text-search would be sorted in some way. If I search for example for "GmBowen", a page with the exact match (his userpage) should be on the top of the results. The next results perhaps in alphabetical order? --NilsLindenberg