=====Suggestion Box=====

""<div style="padding:5px; background-color:#FEE; border:1px solid #EDD"><h5>New Wikka Tracker available</h5><p>We are happy to announce that Wikka has just opened a dedicated <a href="http://wush.net/trac/wikka/" target="_blank">issue tracker</a>. We are currently migrating open issues, bugs and feature requests from this site to the new server but this migration isn't complete yet.</p>
<p>Meanwhile, if you have something to report:<br/>
<strong>First</strong> check if your feature suggestion is already being discussed on this page:</p><ul>
<li>If so: check if it has a link to a tracker ID:<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> feature suggestion.</li></ul>
<p>Thanks for your understanding.</p></div>""
::c::
**Issues often asked for**
~-[[CategorySystemOverhaul Categories]]
~-[[WikkaFolksonomy (Technorati) tags & related]]
~-[[WikkaInternationalization Internationalization/Localisation]]
~-[[DateAndTimeFormat Date/Time]]
~-[[WikkaFilters Wikka Exporting/Importing]], [[WikkaToPdf PDF-Export]]
~-[[WikkaOptimization Optimization]]
~-[[TableofcontentsAction Table of contents (TOC)]]
~-[[SectionEditing Section Editing]]
~-[[WikkaSpamFighting Spam (and related issues)]]
~-[[WikkaTables Tables]]
~-TemplateSystem
~-[[WikkaWorkarounds Workarounds for uncommon problems]]

**see also:**
~-UserMap
----
===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]]

----
===Link en- and disabling in respect to user rights===
[[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]]

----
===Accesskeys for the footer functions===
[[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]]

----
===Local links===
[[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)===
[[http://wush.net/trac/wikka/ticket/604 Ticket: 604]]

----
=== Create rewrite rules on install ===
[[http://wush.net/trac/wikka/ticket/604 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
~&Try out http://diberri.dyndns.org/html2wiki.html (Won't work with tables yet). --NilsLindenberg

----
===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 [[http://sourceforge.net/tracker/index.php?func=detail&aid=1150914&group_id=118997&atid=682795 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: [[http://smackaroo.net/by-blood-and-bone/MyNextWiki 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.
%%(php)
// usersettings.php line 130 fixed
if ($existingUser["password"] == md5($_POST["password"]) || $existingUser["password"]==$_POST["password"])
%%
This is the current version:
%%(php)
// 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
~&Charlotte, you are correct in that the code doesn't work as is. We are working on splitting up the whole (confusing) login/usersettings form into separate actions and forms; logging in with a "temporary" password should then not only be separate, but also force the user to immediately choose a new password since sending a password by email is inherently insecure. Until we have that in place in a future release, your workaround is a good one (I came up with the same ;-)); but it's up to you to decide how acceptable it is in your application to let the user continue to login with an emailed password. --JavaWoman

----

===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: %%(php)print("\t<div class=\"commentinfo\">\n-- ".$this->Format($comment["user"])." (".$comment["time"].")\n");%% I modified this to: %%(php)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: %%(php)if (!$this->LoadUser($comment_by)) $comment_by .= " (unregistered user)";%% was changed to: %%(php)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: %%(php)if (strlen($comment["comment"]) > 120) $comment_preview = $comment_preview.".... ";%% after this add: %%(php)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/*xml*.php, handlers/page/history.php). --Rick

----
===Storing the IP-address for registered users===
//copied from WikkaBugs - this is a suggestion, not a bug --NilsLindenberg//
Security: I was wondering whether it would be possible to store IPs for registered users as well. That way you can ban them via .htaccess if necessary. -Sam
~& Last known IP or every IP they ever connect from? I'd be willing to store one last known IP per user. - JsnX
~~& Last known IP please :) Thanks. - Sam
~& I'd suggest adding *two* distinct fields to ##wikka_users##: Last Login IP/Hostname + Last Login Time - DarTar
~~&I was also thinking of a way to ban users directly from the wiki (much in the same way as referrers are added to the blacklist of spammers). This might turn out easier to implement than a //user deleting action// (which was one of the ideas discussed [[UserAdmin here]]) - DarTar

----

===Global Access Control Lists===
How about a global ACL that allows you to pick a prefix to a wikka word that automatically has an ACL applied? E.g. PrivatePage1, PrivatePage2 -- so the word Private is the trigger, anything prefixed with that has an ACL applied. -- JeremyCoates

----
===Integration into existing site===
==plus more on non-wikiname formatted usernames==
I'm trying to integrate wikka into an existing site auth system. I have wikka already successfully running with the includes of my main site, thus requiring main site login to access the wiki. i fig the best way to deal with wikka logins is to read the main sites "current user" info. when someone access' the wiki for the first time, their username obviously won't exist in the wikka userdb, so rather than making them create a login, i'll want to quietly query it into the wikka db. the problem is that wikka depends on wikiname formatted names. I don't care if people have their own page (may have it for a special few) password resets won't be an issue as stated below. While we may use comments (on the pages for the special few) they will prob remain off.

I'd like to do this as above to keep vandalism down. I've got almost 200k members and i know there are some jokers just waiting to anon deface crap just cuz they can. With an auto login like this, showing ppl their username as soon as they hit the wiki, it'll immediately cut that factor.
-- MonstoBrukes

~&I am interested in doing something very like this as well. I would like to integrate wikka into an existing phpBB site. I don't mind if my users have to log in twice - but I **//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

~&See also WikkaWithphpBB --JavaWoman

----
===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:
%%(php;1)
if (!$this->page)
{
print("<p>This page doesn't exist yet. Maybe you want to <a href=\"".$this->Href("edit")."\">create</a> it?</p>");
print $this->Action("backlinks")."</div>";
}
%%
~&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 [[http://dartar.free.fr 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 [[http://www.google.com/search?hl=en&lr=&q=site%3Adartar.free.fr&btnG=Search 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: [[http://www.google.com/search?hl=en&lr=&q=site%3Awikka.jsnx.com+revisions.xml&btnG=Search 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
~& Hope you have a large screen: SoWhatAreTheNews --ChristianBarthelemy
~~&Nice one, Christian! While you're at it, you might want to add the RecentComments page (or its content) as well, so you get a better overview of **all** recent comments and not just //pages// that have recently acquired new comments. Then you have it all in one place. ;-) --JavaWoman

----
===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
%%(apache)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: %%(apache)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: [[http://nontroppo.org/wiki/WikiIcons WikiIcons]] which were copyleft [[http://mc.clintock.com/first_floor/study_1/desk/computer_projects/icons/index.php 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
~&Have a look at TableofcontentsAction for some ideas about creating a TOC (automatically or triggered by an action...) --JavaWoman

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

%%(php)$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.
~&Yes. And related: an extension of this or the general search function to search by //comments content// (in addition to page name or page content) would, I think, be also useful. --JW
~~&Agreed. -- JsnX
~&Nice idea :). For //comments by user X// (and, why not, //mods by user X//) we could imagine something similar to Google syntax for site-restricted queries. E.g.: ##I18n user:""JavaWoman""##. The scope of the query (pages, mods, comments, anywhere) should be settable as a radio button (similar to Google's restrict search options). FYI, //Comments by user X//, //Pages owned by user X// and //Changes done by user X// were already partially addressed by the following action proposals: UserCommentsAction, UserPagesAction, UserChangesAction -- DarTar
~~&In general....given the complexity (and utility) of some of the conversations now happening in the comments, I think that we should consider either (i) the current textsearch being expanded to include the comments, or (ii) a separate action be written directed at searching the comments table (possibly an easier route). The latter might mean we consider renaming the search pages to ""SearchText"", ""SearchTextExtended"" & ""SearchComments"". [I now realize that this "search comments" feature is a **"lost"** feature. I realize now that //earlier// versions of this wiki had the comments stored in the pages table and were therefore searched. When they were moved to a separate table, the ability to search comments was lost. (Update: See my GmBowen directory for a (temporary) solution for this....even separates results for comments & pages into two columns) A separate action to list all comments by a user would also be useful. In a related comment on the comments, and given my arguments about the complexity of conversations in some of the comment threads now, I suggest that we also consider developing code for threaded discussions in the comments....which I think will considerably enrich collaborative efforts (such as we engage in). -- GmBowen

----
===Order of the text-search===
//(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

----
===Highlight unseen Recentchanges===
//(copied from WikkaDevelopment --NilsLindenberg)//
Add fields to the 'users' table [?] to track when RecentChanges and RecentlyCommented were last viewed. Then RecentChanges and RecentlyCommented can by modified to highlight new items since the user last viewed the page.
~&If it's only for **highlighting**, OK, but I'm not waiting for that. If it's for **filtering**, please no. I quite often trace back several days to re-review pages or comments --JW
~~&OK. Point taken. I was considering doing some form of filtering, but will now only consider higlighting, as requested. -- JsnX
~~&I totally agree with JW's point -- DarTar
~~~&Actually, I //could// imagine separate functionality with filtering being useful on a busy site, but then as, say, UnseenChanges and UnseenComments - **in addition to** the current "Recent" functionality; that way the semantics of "recent" would not be changed. But I agree it's low priority. --JavaWoman

----
==="target=" in external links?===
Is there a way to include a target in a link, so that the Link opens in a new window?
~& Yeap, use this directly within the wikka page you are working on
~& %%(htmlstrict) <A href="http://google.com" TARGET="_blank">Google</A> %%
~& It will show up a normal link "" <A href="http://google.com" TARGET="blank">Google</A> ""
~& In this case the **TARGET="_blank"** bit is what does the trick.
~& Assuming this is what you were originally after, it has the advantage of no code changes. NickDamoulakis
~~& I assume you meant the above code to be put in double quotes like this:
~~& %%(htmlstrict) ""<A href="http://google.com" TARGET="_blank">Google</A>"" %%
~~& Since I use Wikka inside an iframe I need to use target a lot, so I modified the forced links section in wakka.php from:
~~& %%(php)//if ($url!=($url=(preg_replace("/@@|££||\[\[/","",$url))))$result="</span>";
if (!$text) $text = $url;
//$text=preg_replace("/@@|££|\[\[/","",$text);
return $result.$wakka->Link($url, "", $text);%%
~~& To this:
~~& %%(php)//if ($url!=($url=(preg_replace("/@@|££||\[\[/","",$url))))$result="</span>";
if (!$text) $text = $url;
if ($pos=stripos($text, ' target=')) {
$target = substr($text, $pos);
$text = substr($text, 0, strlen($text)-strlen($target));
}
//$text=preg_replace("/@@|££|\[\[/","",$text);
return $result.$wakka->Link($url, "", $text);%%
~~& I can now do forced links like this:
~~& %%[[http://www.google.com Google target="_top"]]%%
~~& What I don't like is target within imagelinks, the way it is now you have to write like this:
~~& %%{{image url="whatever.gif" link="http://www.google.com" target="target='_top'"}}%%
~~& This would have been better looking:
~~& %%{{image url="whatever.gif" link="http://www.google.com" target="_top"}}%%
~~& /AndreasHeintze

--GregorLindner
----
=== Easy way of adding links ===
Most wikis I have set up have the need for a page containing a list of links. It would be great if Wikka could support this in some way - such as providing an easy way of adding links to a configured page. One way of doing this could be a simple Java Scriptlet that you configure with the address of the link page. Then, you mark a link in a web-page, click on the scriptlet, enter a short description and bang - the link is added to the wiki page.
The del.icio.us [[http://del.icio.us/doc/about page]] offers some user contributed hacks which may be a starting point.
-- MatthewLangham
~& MatthewLangham, I propose AddLinkAction as solution for adding links on a page in a structured way. I also added (under the Beta section at the end) a ""JavaScript""-link that you need to bookmark to fast add a link in two mouse clicks... (Works with Firefox and IE under XP, still needs testing with other browsers) -- OnegWR

----
=== Image dimensions ===

The [[Docs:AddingImages image]] action really needs the ability to specify image height and width. :) --MovieLady
~&I agree that it would be better to have defined width and height in the resulting img element: faster output, and no "jumping" pages. However, PHP can easily derive these dimensions by itself - would that be sufficient or do you think it's also necessary to be able to override the actual dimensions of the image file? --JavaWoman
~~&There surely will be users which want to do that. My suggestion (if possible): allow height and width as optional input. If nothing the variables should be filled with the values of the image. --NilsLindenberg
~~~&Noted. More //easy// suggestions like this, please. :) --JavaWoman
~~~~& Yes, that exactly, Nils. LOL Lemme get my list, JW. ;) Seriously, though, I really like what you all have done with this wikki, and the multitude of suggestions are only because I'm getting invested in it. *g* I've been sick or I would've worked on the DeleteSpamAction changes sooner so I could feel like I was actually doing more than "I want it to do this!" ;) --MovieLady
Dear all: see my proposal at EnhancedImageAction
~& That's great, Christian, thank you! --MovieLady

----

== User registration control ==
now available as URUniqueEMailModule

----

=== Embed a blurb from a news page into another page? ===

I currently have no idea how one would approach this, but thought I'd toss it out there for others to think over. I would find it really useful to have an announcement action (maybe ""{{news}}""?) that I could use which displays only the most recent (configurable) number (e.g. ""{{news show="2"}}"" would show the most recent two entries from the page) of entries from a specific (configurable or static?) page. Right now I do this by hand, adding the current announcement to both the front page and the news archive page (so I'll have a history of the announcements), and boy, what a pita! What I'd like to be able to do is just edit the news page and have it automatically update what displays in the news area on the front page. Possible, or am I smoking something I need to share? ;) --MovieLady
~& I am doing this using the IncludeAction - at least you only update one page (TheNews). --ChristianBarthelemy
~~& Thanks, I'll try that out. --MovieLady
~~~& Did you do anything to get it to add only part of the page being included (for example, down to the first horizontal line)? --MovieLady
~~~~& Nope. I just only keep the news updated in TheNews page so that the whole page is displayed when included. --ChristianBarthelemy
~~~~~& Ah well, I'll keep working on trying to figure out a way to do it. *g* Thanks! :) --MovieLady

----
===Logging-out===
Perhaps the installer should tell the user that he will be logged-out (because of the new cookie-names). Would be nicer. Btw, the /setup directory needs an update (or better the files in it). --NilsLindenberg

----
=== Backlinks ===

It would be wonderful to have the option to display the results of the ""{{backlinks}}"" action in columns, similar to what ""{{Category col="3"}}"" allows you to do. --MovieLady
~&Noted - good suggestion. --JavaWoman

backlinks.php
%%(php)
if ($pages = $this->LoadPagesLinkingTo($this->getPageTag())) {
foreach ($pages as $page) {
$links[] = $this->Link($page["tag"]);
}
// #MW:commented print(implode("<br />\n", $links));

// #MW: Ja, här ska jag fixa stöd för kolumner via parametern col

if (!isset($col)) $col=1;
$out = "<table width='100% border='0''><tr>";
$count = 0;
while (list($key, $val) = each($links)) {
if($count == $col) { $out .= "</tr><tr>"; $count = 0; }
$out .= "<td>" . $val . "</td>";
$count++;
}
$out .= "</tr></table>";
print $out;
%%

----
=== User names ===

Is there any likelihood of non-wikiname usernames (e.g. Movielady) in the future? It's one of the things I've been asked a lot by the users of the site I use Wikka for. (Most often heard comment: "but other wikis I've used let me do it!") Obviously it's possible to create non-wikiname pages, so why not usernames? (I have looked on the site, but I've probably missed the explanation.)

I also agree with Nils that it would be really wonderful if some sort of default user page was created when a person creates an account.
~& Should not be that difficult? In usersettings.php there is a part where a new user is created. After the mysql query which adds the user to the user-base, another query which inserts the user-page to the pages table is needed. Anybody here whos good in creating mysql-queries? --NilsLindenberg
~~&Automatically creating a user page should certainly be possible (easy enough). But while on some Wikis you may have a small group of people regularly contributing, on others many people may register just to post one or two things, and then disappear, never even look at their user page - and you'd end up with a lot of empty pages, all of which will show up in the PageIndex. So it really should be a (WikiAdmin) option to determine whether user pages are automatically created or not. --JavaWoman
~~~& Excellent point, hadn't thought about that. :) --MovieLady
~~~~& See AutomaticUserPageCreation for a first version. Or test it [http://www.niehle.info/UserRegistration here] And it is of course an additional config-option :) --NilsLindenberg
~~~~~& Fabulous! I'll check it out. --MovieLady

Y'all are doing a marvelous job, BTW and it is greatly appreciated! :) (I will try to contribute as I can, but honestly, some of the programming is beyond me at the moment.) --MovieLady

I actually hacked UserSettings.php to allow for non-wikinames. Just change lines such as 152 and 179 from:
%%
if (!$this->IsWikiName($name)) $error = "User name must be WikiName formatted!";
%%
to something like:
%%
if(false);
%%
Then modify header.php so that the username is Wikified. So change a certain line (I modified my Wikka so much that I can't give accurate lines) to:
%%
echo "You are ".$this->Link($this->GetUserName());
%%
I'm not sure how well this will work in the long run, but it worked for me!
-- MikeXstudios
~& Good idea, except that having a non-wikiname causes problems elsewhere. For instance, I edited my db by hand and changed a couple of names to non-wikinames, and then one of the users with a non-wikiname forgot (sigh) her password. She tried to request a new one, but the temporary password function wouldn't recognize her username as being valid. And that's certainly not the only place that checks for a valid username. (The automatic sig on comments doesn't show a hotlink to a username if it's not a wikiname, either.) Just FYI. :) --MovieLady
~~& I do really want to use non-wikinames (or just turn wikinames off completely somehow). The temp pass and comments can be easily modified, comments can use the same header code above if the user exists. I know many of us are used to wikinames, but it is extremely odd and intimidating to newbies. Thats why Mediawiki dropped all wikinames so not to intimidate anyone and lessen the learning curve. So I hope there is some way to make wikinames an optional thing. --RyanKnoll

----
===List of special actions?===
A complete reference list of all the special actions (e.g. ""{{nocomments}}"", ""{{Category}}"", etc.) would be really nice. --MovieLady

~&Have a look at UsingActions which has a current list of available actions. We're working on automatic actions documentation, so that both that list (expanded with short descriptions), and documentation pages for individual actions will pull content from the actions files themselves. (Not for 1.1.6.0, but likely the version after that.) --JavaWoman
~~&Thank you! I figured something like that somewhere, but couldn't find it. :) I'm more than happy to help out with documentation if you need help! --MovieLady

----
===Allow spaces in pagetitle===
Allow Spaces in the document title and replace it later with "-" to optimize it for search engines.
~& Wikka already uses the SmartTitle formatter, which displays the highest-level header present in the page (like: ##""===== This is the main heading""##) as a HTML title. See for instance the title of FormattingRules. -- DarTar

----
===User-defined formatting rules===
It would be nice if Wikka supported some way to add in user defined wikki formatting rules (that is, without editing ""./formatters/wakka.php""). Not sure what that would look like. A few thoughts I've had:
-An array in wikka.config.php
-A function defined in a standard place (like ./formatters/wakka_user.php). ""./formatters/wakka.php"" could then call that function, if it exists). Maybe even a flag in ""wikka.config.php"" to enable it.
--KickTheDonkey

----
==Compile Category action==
A "compile category" action. Right now, if I go to CategoryDocumentation I can see a list of all of the pages in this category...but it still requires a lot of snooping to find what I want. As an administrator I'd like to provide a pdf "booklet" of all of that output for users to download. To make this now would mean going to and printing each and every page (using a software tool, TO a pdf file). Ugh. An action that let me go ""{{compile category="CategoryDocumentation"}}"" to generate a single web page of all of that documentation would be quite useful because then I could just print it to a pdf file once.....then I could provide a link to the PDF file so users could download it and print it off.

----
===Compatibility & Installer===
//(Copied from comment on WikkaInstallation, I support this proposal - and agree that @ in front of a statement should generally be avoided, unless any errors are actually dealt with. (Layout slightly adapted.) --JavaWoman)//

IMPORTANT: installer uses TOO MUCH "@" before all mysql calls...
-- 213-140-6-98.fastres.net

- Compatibility-problem is solved now, text moved below to Resolved Suggestions->Compatibility with PHP 4.1.x) --NilsLindenberg

----
===Handling the config===
I have three questions about the config. See HandlingWikkaConfig.
--NilsLindenberg
''See also WikkaSecureConfig for a possible new appraoch. --JavaWoman''
''See also [[http://wush.net/trac/wikka/ticket/603 Ticket 603]] --JavaWoman''

----
===Markup for code not to be shown===
I read this suggestion elsewhere (not in wikka I don't think...some other wiki I think) and didn't think anything about it at the time, but now with the showpagecode action (Mod042fShowPageCodeHandler) am thinking that maybe some wiki markup for "comment text" that is not shown by the code interpreter might be useful (in other words, visible when editing the page, visible when showing the code, NOT visible when just viewing page). I suspect it might be simple to add this....am I wrong?? -- GmBowen (Mike)
~''Essentially you can already do this -- well, mostly -- since Wikka supports HTML markup: just enclose the element to be hidden in HTML (SGML) comments: **<!--** at the start and **-->** at the end, and then mark the whole as being HTML. One gotcha: the content between inside the comment declaration cannot itself contain a double dash (hyphen) since that would terminate the comment. And a proviso: HTML should be enabled. --JavaWoman''
I played with this a little and did a modification of formatters/wakka.php (see [[http://131.202.167.33/wikichanges/wikka.php?wakka=Mod009AddingHiddenCommentCodeToWikiFormatting here]]) that got rid of monospace and replaced it with the comment brackets. It works okay, although it does leave a blank line in the code. I tried making my own format within that code (using ^^) and got nowhere....but what I did works okay. Thanks for your feedback...it provided info I needed to do the change in the wakka file. -- Mike
~''But why make a modification at all? HTML is **already** supported. ""<!--(So let me include a comment here.)-->"" Do you see the commented out text? It's right here in my reply; edit the page to see it. :) --JavaWoman''
Ha...I learned something here....I didn't have HTML turned on in the config file (oops!)....however, one thing to remember is that I'm dealing with a different "audience" for using this wikka tool (13-18 year olds, many not computer literate at all, and who would be completely alienated by even thinking about using html...although maybe not all **that** different from an "average" user) and I'm trying to have it as useable as possible for them. For that group, there's a big difference between typing ""##"" twice when they might want to add a comment they don't want anyone else to see as they're reading the document, like a thought they don't want to forget, and having to remember BOTH of "<!--" AND "-->" (with the double quotes remember). From a useability perspective the latter is a LOT more difficult, and therefore students would be much less likely to use it (altho' the ability to drop in quick notes would be quite useful to the writing process....like I use the post it boxes in MSWord). Imagine them writing an essay that they want comments back on from the teacher or other students. They would **never** put "off-topic commentary" (to remind themselves of a reference, etc) into the overall "visible" body in a way that you and I might (it runs completely against how students write in school culture)...although such personal sorts of comments might be really useful when re-editing the document. My overall schtick is trying to provide a scaffolding of use so that complete newbies can better proceed to more sophisticated usage...and part of how I do this is considering the culture they work in and how they use similar tools in the context that I'm interested in them using the wiki....which is what many of my comments and additions here are all about eh. ; ) I agree though that for my useage, and for your useage, what you're suggesting makes complete sense....and besides, why do we //need// monospace anyways?? {grin} -- Mike
~''Ah, yes, I see your point about the "available" commenting method being unusable for your (and similar) audience. (One could possibly extend the WikeEdit toolbar to provide an easy "commenting out" action though) On the other hand, maybe **you** don't need monospace, but I, often writing //about// code (and planning Wikis where users would do the same), need it **all the time**: I use it as a "fake" inline code markup (see my new JwCalendar page for an example :)); real inline code markup might be nice, of course, but I still wouldn't want to give up monospace markup! So, I'd suggest a choosing different set of characters (possibly a combination of two different characters, we're fast running out of candidates!). --JavaWoman''
My, uh, comment on monospace was a "poking fun" "tongue in cheek" kind of comment (meant in the kindest possible ways) that programmers use monospace a lot (which is probably why it's there), whereas non-computer sorts don't.....my (maniacal?) focus is on the latter groups eh? LOL. I did try to have code in formatters/page/wakka.php to add in ^^ as code for commenting, but I couldn't get it working...which is why I switched to just replacing monospace. Do I need to edit a file other than that one to get it to work?? I couldn't find another relevant file, but I might have missed something. I've played with editing the wikiedit toolbar before (I now have [[http://www.zhuo.org/htmlarea/ Image Manager]] in mine to make placing images easier (from the students personal directories)) and will add in code (either for the replaced monospace or some other code (if I can get it working)) for commenting at some point. -- Mike
~''Heh, poke fun all you like. ;-) I know us coder types can take thinks rather literally sometimes (and some of us make an art of that! "can you pass the salt?" "yes.").
~About not getting ^^ working - without looking up the Formatter code, I think you'd need to add both the code to **handle** the "tags" and the appropriate regular expressions, I think. Did you do that? Everywhere? If not, does that hint help at all? --JavaWoman''
Oh, regex stuff. Ugh. I don't understand those worth a darn. (although some comments here last week helped me understand them a little) Okay, thanks for the hint. I'll have to tackle it a bit later (got marking to do). -- Mike

----
===markup of diff pages===
The 'diff' facility is if course nice - and essential to a Wiki. But I note the differences are marked up only with classes which match to coloring in the stylesheet. If we're doing XHTML, we could do that a little better (as well as more accessible!): the **##del##** and **##ins##** elements are __created__ to markup deletions and insertions: fully semantic markup!

My proposal:
~-mark up a deletion with the <del>...</del> tag; since we actually know the timestamp of the change, add that in the **##datetime##** attribute (properly formatted);
~-mark up an insertion with the <ins>...</ins> tag; same recipe for the timestamp
~-then use the stylesheet to render those two in whatever font/coloring you like (even as done now) - but note that most browsers have a default rendering anyway

See [[http://www.w3.org/TR/html401/struct/text.html#edef-del 9.4 Marking document changes: The INS and DEL elements]] for all the details (HTML 4.01 since that's where all the semantics are).
--JavaWoman (standards junkie)

''This is related - I found that the diff engine and page history sometimes forgot to close tags. With a list of lists, the indents would get carried forward. Check out my [[http://wiki.samuelooi.com/wikka.php?wakka=Mod03HistoryAndRevisions hack]]. Not CSS compliant by any means, but then again, your suggestion isn't either (list tags are not closed etc etc). I reckon you would probably have to parse each addition/deletion through the SafeHTML checker.'' -- Sam

Assuming you mean XHTML compliant (sorry) my suggestion certainly is (believe me, I would //never// suggest anything that //isn't// XHTML compliant) - I just forgot to mention that closing tags properly is a prerequisite... although I did point to the actual standard which indicates how **##ins##** and **##del##** must maintain proper tag nesting.
You're right though, I did notice that lists don't seem to be closed properly. I think that should be fixed first (it's a bug, not sure it's recorded as such yet) - **then** you can do more semantic markup.
-- JavaWoman (standards junkie)

You mean something like that?:

%%
// deletions
else if ($thing == ""¥¥")
{
$timestamp = $wakka->GetPageTime(); //hopefully this function returns the right format?
return (++$trigger_deleted % 2 ? "<DEL datetime=\"$timestamp\">" : "</DEL>");
}
%%

(naturely the rest has to be changed too)
--NilsLindenberg

----
=== Problem: Scrolling in the search - field ===

Not worth to mention but now I am here I write it. Text in the search field is a little bit scrollable. Again ... ;-)

-- SkyWalk

----
=== Problem: Five Line Breaks ===

Just a small problem i found. If you insert five line breaks at the end of a site, the footer jumps into the box.
After all a nice wikki. Keep on the good work.

-- SkyWalk

----
=== DB Export ===

ExportDB : as i'm discovering Wikki (and WikkaWiki) and playing with it on my main server and on my laptop (which too runs an Apache installation), I
was needing a quickly way of making export of my database. So I wrote a quick (and dirty ...) export page to get all the replace SQL commands to populate an instance.

I too may use this in the future to quickly backup an online Wikki site. See this additionnal page for the code : CodeExportdb

-- SergiO

----
===Code block formatting===
I was converting a document to Wikka markup format, and I was trying to display ""MySQL"" (Console) Table output using the "Code" formatters ""%%"". Everything that appears in a code block is formatted using a monospace font (as I expect), however, since the Edit page handler converts every instance of 4 spaces to a tab, the spacing is thrown off. Below is an example (Select some of the whitespace with your mouse to see the tabs):
%%
----------------------------------------------------------------
OBJECT_TYPE COUNT(*)
------------------ ----------
FUNCTION 12
INDEX 55
LOB 4
PACKAGE 2
PACKAGE BODY 2
SEQUENCE 9
TABLE 37
TRIGGER 6
VIEW 1
9 rows selected
no rows selected
--------------------------------------------------------------------
%%

The edit page handler seems to convert spaces to tabs throughout the entire document, including Code blocks.

**From edit.php**
%%(php)
11: // replace 4 consecutive spaces with tab character
12: $body = str_replace(" ", "\t", $body);
%%
Is there any way to make the edit handler leave the spaces alone inside of code blocks?
Thanks! -RichardTerry

''Noted. Try commenting out that line for a temporary workaround.'' -- JsnX
%%(php)
// $body = str_replace(" ", "\t", $body);
%%

----
===Various suggestions===
- See MarkHissinkMuller for things I would like to see in Wakka/Wacko/Wikka. Feel free to add/discuss.

----
===Other method to attach files===
- I'd like a way to attach files to a page without having to include the ""{{files}}"" action. I like using the action to //link// to attachments, but I'd rather click a link at the bottom of each page to reach the attach form or to see which files are attached to the page. (I'm a PHP newbie, so It would probably take me some time to make a handler to do what I want.) //Actually, now I'm kind of used to having all of my attached images displaying at the bottom of the screen, so this isn't a big deal. If I really don't want the attachment list (usually a bunch of images) to display I just remove the ""{{files}}"" from the page.// -RichardTerry

----
===Installation problem - UTF-8?===
- Not a suggestion, but problems: with installing 1.1.3 on a Win 32 Apache 2, with Php 4.3.8 and Mysql 4.1.3. Upgrading from wakka 0.1.2 didn't work (ended with: "creating comment table - failed - hmm"). So I thought I'd do a fresh install. Everything went fine, but there seems to be some problem with utf8. Even when I set the charset in header.php to utf-8, the page is all scrambled. However, in phpMyAdmin, the text in the pages table shows up fine. Any clues? (I need utf-8, by the way ...) BirgitKellner.

Sorry if this was the wrong place for posting this, and feel free to move it to a more appropriate one.

wikka don't support utf-8 yet. this issue is discussed here: WikkaInternationalization (and should be moved from there to its own page, 'cause it's not a trivial problem ;) --moved to HandlingUTF8 ). anyway, i'm afraid you won't find comprehensive help in that discussion. it's not enough to change the meta-tag. that only tells the browser to assume a charset, which in fact isn't used.

i haven't spent much time on that issue, although i am (or should be) interested in it. but be assured that it's not a simple config-value to be squeezed to solve the problem. i hope the discussion mentioned above will get more precise in the next days, as i would appreciate any hint how to start to despair of it ;) i think in long terms it's **a must** to support different charsets. -- DreckFehler

----
===Add page link & other suggestions===
~- It would be Really Nice to be able to have an **Add Page** link that allows a user to create a new page without having to edit an existing one. (I don't belive this is currently possible, I'm a newbie however) Perhaps this could be achieved via a simple HTML Form that prompts the user for a Page Name, and Category. It would be even better if the Category was selectable (dropdown list) from existing categories. And to top the whole thing off, it would be perfect if it was possible to define Template files (eg. per Category) where by when a user creates a new page of category ABC, the template file for ABC is used as the default page text. This would aid in keeping some kind of consistancy between pages of the same category. (ie. for one thing the correct category definition could be placed in the appropriate location/style). An **Add Page** link would posssibly be usefull on the standard Category pages, especially as the Category is already known.

~- It would be nice if ACLs were somehow inheiritable from their creating pages (Created either the current way or via the above described method)

~- Is it possible to define User Groups to simplify editing ACLs also.
~& I tried to do something with ACLsWithUserGroups.

~- Finally, (although I think I can possibly do this one myself) , On the Editor Page a link to the standard FormattingRules page would be most useful. Especially if it opened in a different window.

Regards Simon H.

~& I like the **Add Page** link idea. It would be really simple to implement, too. Perhaps a text form where you'd enter the page name, which would take you to ""http://some.host.com/wikka.php?wakka=NewPage/edit"", where you would actually create the content. I like it! --KickTheDonkey

----
===Disable CamelCase===
While I understand the arguments in favor of CamelCase, I prefer not to use it. Given how incredibly simple it is to modify Wikka for non CamelCase use (remove one line in formatters/wakka.php, and replace a regex in wikka.php, wouldn't it be simple just to add an admin option to turn it on and off?

----
===Rename Pages===
It would be nice to be able to rename pages and automatically update all backlinks to point to the right page.

Example: I have a ""HomePage"" which has a link to ""MyIdeas"" on it. Let's say I realized that all these ideas are Wikka related, so I want to rename the page to ""MyWikkaIdeas"". Any link to ""MyIdeas"" (such as that on ""HomePage"") should now be changed to point to ""MyWikkaIdeas"".
- JonathanMitchem
~& Yeah, so I found this... RefactorWiki which supposedly does exactly that (I haven't tested it personally) - JonathanMitchem

----
===Star Rating System===
I think that maybe usefull a star rating system for a page or for an image or other .
~& LuxiO, what criteria would you suggest for such a ranking system? --BrianKoontz
~~& BrianKoontz, first i think that the rating system should have an extra table in the main database so that every item we want rate should have a unique identification number. Then we manipulate this extra table from an internal action... maybe? --LuxiO
~~~& That sounds like a suitable approach...but my question is, how would users be expected to "rank" a page? Are we looking for a measure of suitability, quality or aesthetics, or maybe popularity? Is it really possible to assign a relative ranking to pages with dissimilar content? --BrianKoontz
~~~~&It would depend on the use of the wikki... for example, [[http://www.RantThisSpace.com Rant This Space!]] is purely for entertainment and therefore people would be encouraged to vote based on how entertaining the page was. In a corporate setting it might denote importance, or relevance to the project. Then the home page could display a list of all pages with 5 stars, and new members would know to read them first. Icons other than stars could also be used.

I have found this simple javascript for page rating:
%%(javascript)
<div class="js-kit-rating" starColor="Golden" path="ABSOLUTE-PAGE-URL"></div><script src="http://js-kit.com/ratings.js"></script>
%%
but i don't know how implement single file rating --LuxiO

CategoryDevelopmentSuggestions