Revision history for SuggestionBox
Additions:
===Storing the IP-address for registered users===
Deletions:
Revision [19976]
Edited on 2008-05-25 13:26:47 by NilsLindenberg [replaced old discussion with link]Additions:
now available as URUniqueEMailModule
Deletions:
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
~&Place this function in wikka.php right after function ""UserWantsComments()"". And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
Revision [19548]
Edited on 2008-02-09 02:10:52 by PaulP [Paragraph instead of line-breaks: Proposal doesn't work]Additions:
~~& No, that doesn't completely work either. It leaves code blocks unchanged, but keeps text from returning to left margin after indented paragraphs. --PaulP
Deletions:
Revision [19547]
Edited on 2008-02-09 01:51:29 by PaulP [Paragraph instead of line-breaks: Proposal doesn't work]Additions:
~& 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
~&& No, that doesn't completely work either. It leaves code blocks unchanged, but keeps text from returning to left margin after indented paragraphs. --PaulP
Deletions:
Later: no that doesn't completely work either. It leaves code blocks unchanged, but after indents, text stays indented instead of returning to left margin. --PaulP
Revision [19546]
Edited on 2008-02-09 01:43:14 by PaulP [Paragraph instead of line-breaks: Proposal doesn't work]Additions:
Later: no that doesn't completely work either. It leaves code blocks unchanged, but after indents, text stays indented instead of returning to left margin. --PaulP
Revision [19542]
Edited on 2008-02-08 01:51:54 by PaulP [Paragraph instead of line-breaks: Proposal doesn't work]Additions:
The above code places paragraph tags throughout the page, even //within// code blocks. 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
Deletions:
Revision [19541]
Edited on 2008-02-08 01:49:20 by PaulP [Paragraph instead of line-breaks: Proposal doesn't work]Additions:
The above code places paragraph tags throughout the page, even //within// code blocks. 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 an post the code if it works. --PaulP
Additions:
The [[Docs:AddingImages image]] action really needs the ability to specify image height and width. :) --MovieLady
Deletions:
Additions:
=====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>""
**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-adress 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
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 [[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 ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function ""UserWantsComments()"". And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
=== 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
""<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>""
**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-adress 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
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 [[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 ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function ""UserWantsComments()"". And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
=== 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
Deletions:
This page can now be found on the [[Docs:SuggestionBox Wikka Documentation Server]].
Thanks for updating your bookmarks!
An archive of [[http://wikkawiki.org/SuggestionBox/revisions
old revisions of this page]] is still available for reference.<<
CategoryMigratedDocs
Additions:
<<===This page has moved===
This page can now be found on the [[Docs:SuggestionBox Wikka Documentation Server]].
Thanks for updating your bookmarks!
An archive of [[http://wikkawiki.org/SuggestionBox/revisions
old revisions of this page]] is still available for reference.<<
CategoryMigratedDocs
This page can now be found on the [[Docs:SuggestionBox Wikka Documentation Server]].
Thanks for updating your bookmarks!
An archive of [[http://wikkawiki.org/SuggestionBox/revisions
old revisions of this page]] is still available for reference.<<
CategoryMigratedDocs
Deletions:
""<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>""
**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-adress 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
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 [[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 ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function ""UserWantsComments()"". And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
=== 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
Revision [17831]
Edited on 2007-12-12 12:47:13 by JavaWoman [prevent function references looking as page links]Additions:
~&Place this function in wikka.php right after function ""UserWantsComments()"". And change in actions/usersettings.php the following line: %%(php)
Deletions:
Revision [17802]
Edited on 2007-12-10 09:41:37 by JavaWoman [slight reorg because of new migrated issues]No Differences
Deletions:
take a look at FaviconDotIco and RobotsDotTxt
Additions:
''See also [[http://wush.net/trac/wikka/ticket/603 Ticket 603]] --JavaWoman''
Revision [17799]
Edited on 2007-12-10 08:43:48 by JavaWoman [two (essentially same) issues migrated to #604]Additions:
[[http://wush.net/trac/wikka/ticket/604 Ticket: 604]]
[[http://wush.net/trac/wikka/ticket/604 Ticket: 604]]
[[http://wush.net/trac/wikka/ticket/604 Ticket: 604]]
Deletions:
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
Revision [17735]
Edited on 2007-11-21 06:43:47 by DarTar [clean up - replacing already migrated issues with ticket reference]Additions:
===LinkTails===
[[Ticket:35]]
===Search within the textbox===
[[Ticket:578]] (see also WikkaEdit)
[[Ticket:8]]
[[Ticket:202]]
=== Language files ===
~&Try out http://diberri.dyndns.org/html2wiki.html (Won't work with tables yet). --NilsLindenberg
A nice list of suggestions can be found at: [[http://smackaroo.net/by-blood-and-bone/MyNextWiki By Blood and bone]].
[[Ticket:35]]
===Search within the textbox===
[[Ticket:578]] (see also WikkaEdit)
[[Ticket:8]]
[[Ticket:202]]
=== Language files ===
~&Try out http://diberri.dyndns.org/html2wiki.html (Won't work with tables yet). --NilsLindenberg
A nice list of suggestions can be found at: [[http://smackaroo.net/by-blood-and-bone/MyNextWiki By Blood and bone]].
Deletions:
i am aware of the LinkTails discussion, but i am trying to push wikka in our corporate environment as a documentation tool and our standard is internet explorer and so however elegant **:after** is, it is not acceptable for me to shut out IE users like this. as firefox itself doesn't pass the acid2 test (as of writing) i would recommend waiting with these more "exotic" css features. and however i dislike IE, i don't want to cripple my IE users.
i also don't want to make the empty links different colored/styled as i think that this would disctract the users.
so i added
<span class=\"missingpagetail\"> [empty]</span>%%
before the ending </a> on line 659 of wikka.php and
%%(css)
.missingpagetail {
font-size: 10px;
in the css file.
===IE SCREW UP===
Does a fresh install not work at all with IE? Im getting a screen w/o any css formatting..
ANSWER:
Check the file ##wikka.config.php##
Probably you forgot the trailing slash at the end of your wikki path, Look for: "base_url"
--TomEk
===On WikiEdit===
Search within the textbox: its pain to find where you want to edit in long pages.
How about integrating a search function in wikiEdit, or implementing paragraph editing like wikipedia.
Also how about anchor in wikiedit and a way to link to them ?
--GiorgosKontopoulos
~&Hi George, have a look at AnchorAction (including my mods at the bottom of the page).
See http://www.dynamicdrive.com/dynamicindex11/findpage.htm for a "search in page" feature you might consider adding in. --GmBowen
:Try out http://diberri.dyndns.org/html2wiki.html (Won't work with tables yet). --NilsLindenberg
The ##Action()## method in ##wikka.php## produces errors in some cases; the error class was implemented as a span rather than directly on the <em> element surrounding the message. The span elements are superfluous and bad coding style.
Change:
%%(php;759) function Action($action, $forceLinkTracking = 0)
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
// treat everything after the first whitespace as parameter
preg_match("/^([A-Za-z0-9]*)\s+(.*)$/", $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all("/([A-Za-z0-9]*)=\"(.*)\"/U", $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[2][$a];
}
}
$vars["wikka_vars"] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>"; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
if (!preg_match("/^[a-zA-Z0-9]+$/", $action)) return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>";
if (!$forceLinkTracking) $this->StopLinkTracking();
$result = $this->IncludeBuffered(strtolower($action).".php", "<em>Unknown action \"$action\"</em>", $vars, $this->config["action_path"]);
$this->StartLinkTracking();
return $result;
%%---
to:
%%(php) // JW Action() modified to allow attributes in single quotes
// JW 2005-07-08 error class moved to em
function Action($action, $forceLinkTracking = 0)
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
// treat everything after the first whitespace as parameter
preg_match('/^([A-Za-z0-9]*)\s+(.*)$/', $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all('/([A-Za-z0-9]*)=("|\')(.*)\\2/U', $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[3][$a];
}
}
$vars['wikka_vars'] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
#return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
return '<em class="error">Unknown action; the action name must not contain special characters.</em>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
#if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>';
if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<em class="error">Unknown action; the action name must not contain special characters.</em>';
if (!$forceLinkTracking) $this->StopLinkTracking();
#$result = $this->IncludeBuffered(strtolower($action).'.php', '<em>Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$result = $this->IncludeBuffered(strtolower($action).'.php', '<em class="error">Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$this->StartLinkTracking();
return $result;
%%---
Now implemented as beta on this site. --JavaWoman
A nice list of suggestions can be found at: [[http://smackaroo.net/by-blood-and-bone/MyNextWiki By Blood and bone]].
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
Additions:
~~~~&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.
Deletions:
Additions:
~~~~&It would depend on the use of the wikki... for example, RantThisSpace 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.
Additions:
~~& 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
~~~& 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
Deletions:
Additions:
%%(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
<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
Deletions:
<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 how implement single file rating --LuxiO
Additions:
I have found this simple javascript for page rating:
<<
<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 how implement single file rating --LuxiO
<<
<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 how implement single file rating --LuxiO
Additions:
~& 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
Additions:
~& LuxiO, what criteria would you suggest for such a ranking system? --BrianKoontz
Additions:
===Star Rating System===
I think that maybe usefull a star rating system for a page or for an image or other .
I think that maybe usefull a star rating system for a page or for an image or other .
Additions:
~-[[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]]
----
=====Suggestions to be checked/migrated to the tracker=====
====making user uploaded images more useful====
have a look at my suggestion at FilesAction
----
===LinkTails for IE===
i am aware of the LinkTails discussion, but i am trying to push wikka in our corporate environment as a documentation tool and our standard is internet explorer and so however elegant **:after** is, it is not acceptable for me to shut out IE users like this. as firefox itself doesn't pass the acid2 test (as of writing) i would recommend waiting with these more "exotic" css features. and however i dislike IE, i don't want to cripple my IE users.
i also don't want to make the empty links different colored/styled as i think that this would disctract the users.
so i added
%%(php)
<span class=\"missingpagetail\"> [empty]</span>%%
before the ending </a> on line 659 of wikka.php and
%%(css)
.missingpagetail {
font-size: 10px;
}%%
in the css file.
----
===IE SCREW UP===
Does a fresh install not work at all with IE? Im getting a screen w/o any css formatting..
ANSWER:
Check the file ##wikka.config.php##
Probably you forgot the trailing slash at the end of your wikki path, Look for: "base_url"
--TomEk
===On WikiEdit===
Search within the textbox: its pain to find where you want to edit in long pages.
How about integrating a search function in wikiEdit, or implementing paragraph editing like wikipedia.
Also how about anchor in wikiedit and a way to link to them ?
--GiorgosKontopoulos
~&Hi George, have a look at AnchorAction (including my mods at the bottom of the page).
See http://www.dynamicdrive.com/dynamicindex11/findpage.htm for a "search in page" feature you might consider adding in. --GmBowen
=== 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
----
===Improved code for error messages in Action() method===
The ##Action()## method in ##wikka.php## produces errors in some cases; the error class was implemented as a span rather than directly on the <em> element surrounding the message. The span elements are superfluous and bad coding style.
Change:
%%(php;759) function Action($action, $forceLinkTracking = 0)
{
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
{
// treat everything after the first whitespace as parameter
preg_match("/^([A-Za-z0-9]*)\s+(.*)$/", $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all("/([A-Za-z0-9]*)=\"(.*)\"/U", $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[2][$a];
}
}
$vars["wikka_vars"] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>"; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
}
if (!preg_match("/^[a-zA-Z0-9]+$/", $action)) return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>";
if (!$forceLinkTracking) $this->StopLinkTracking();
$result = $this->IncludeBuffered(strtolower($action).".php", "<em>Unknown action \"$action\"</em>", $vars, $this->config["action_path"]);
$this->StartLinkTracking();
return $result;
}
%%---
to:
%%(php) // JW Action() modified to allow attributes in single quotes
// JW 2005-07-08 error class moved to em
function Action($action, $forceLinkTracking = 0)
{
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
{
// treat everything after the first whitespace as parameter
preg_match('/^([A-Za-z0-9]*)\s+(.*)$/', $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all('/([A-Za-z0-9]*)=("|\')(.*)\\2/U', $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[3][$a];
}
}
$vars['wikka_vars'] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
#return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
return '<em class="error">Unknown action; the action name must not contain special characters.</em>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
}
#if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>';
if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<em class="error">Unknown action; the action name must not contain special characters.</em>';
if (!$forceLinkTracking) $this->StopLinkTracking();
#$result = $this->IncludeBuffered(strtolower($action).'.php', '<em>Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$result = $this->IncludeBuffered(strtolower($action).'.php', '<em class="error">Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$this->StartLinkTracking();
return $result;
}
%%---
Now implemented as beta on this site. --JavaWoman
----
===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-adress 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
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===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
----
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
----
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
=== Image dimensions ===
The [[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 ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
=== 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;
%%
----
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
=== 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
----
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
===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''
----
===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
----
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
===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
----
CategoryDevelopmentSuggestions
~-[[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]]
----
=====Suggestions to be checked/migrated to the tracker=====
====making user uploaded images more useful====
have a look at my suggestion at FilesAction
----
===LinkTails for IE===
i am aware of the LinkTails discussion, but i am trying to push wikka in our corporate environment as a documentation tool and our standard is internet explorer and so however elegant **:after** is, it is not acceptable for me to shut out IE users like this. as firefox itself doesn't pass the acid2 test (as of writing) i would recommend waiting with these more "exotic" css features. and however i dislike IE, i don't want to cripple my IE users.
i also don't want to make the empty links different colored/styled as i think that this would disctract the users.
so i added
%%(php)
<span class=\"missingpagetail\"> [empty]</span>%%
before the ending </a> on line 659 of wikka.php and
%%(css)
.missingpagetail {
font-size: 10px;
}%%
in the css file.
----
===IE SCREW UP===
Does a fresh install not work at all with IE? Im getting a screen w/o any css formatting..
ANSWER:
Check the file ##wikka.config.php##
Probably you forgot the trailing slash at the end of your wikki path, Look for: "base_url"
--TomEk
===On WikiEdit===
Search within the textbox: its pain to find where you want to edit in long pages.
How about integrating a search function in wikiEdit, or implementing paragraph editing like wikipedia.
Also how about anchor in wikiedit and a way to link to them ?
--GiorgosKontopoulos
~&Hi George, have a look at AnchorAction (including my mods at the bottom of the page).
See http://www.dynamicdrive.com/dynamicindex11/findpage.htm for a "search in page" feature you might consider adding in. --GmBowen
=== 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
----
===Improved code for error messages in Action() method===
The ##Action()## method in ##wikka.php## produces errors in some cases; the error class was implemented as a span rather than directly on the <em> element surrounding the message. The span elements are superfluous and bad coding style.
Change:
%%(php;759) function Action($action, $forceLinkTracking = 0)
{
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
{
// treat everything after the first whitespace as parameter
preg_match("/^([A-Za-z0-9]*)\s+(.*)$/", $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all("/([A-Za-z0-9]*)=\"(.*)\"/U", $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[2][$a];
}
}
$vars["wikka_vars"] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>"; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
}
if (!preg_match("/^[a-zA-Z0-9]+$/", $action)) return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>";
if (!$forceLinkTracking) $this->StopLinkTracking();
$result = $this->IncludeBuffered(strtolower($action).".php", "<em>Unknown action \"$action\"</em>", $vars, $this->config["action_path"]);
$this->StartLinkTracking();
return $result;
}
%%---
to:
%%(php) // JW Action() modified to allow attributes in single quotes
// JW 2005-07-08 error class moved to em
function Action($action, $forceLinkTracking = 0)
{
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
{
// treat everything after the first whitespace as parameter
preg_match('/^([A-Za-z0-9]*)\s+(.*)$/', $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all('/([A-Za-z0-9]*)=("|\')(.*)\\2/U', $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[3][$a];
}
}
$vars['wikka_vars'] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
#return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
return '<em class="error">Unknown action; the action name must not contain special characters.</em>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
}
#if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>';
if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<em class="error">Unknown action; the action name must not contain special characters.</em>';
if (!$forceLinkTracking) $this->StopLinkTracking();
#$result = $this->IncludeBuffered(strtolower($action).'.php', '<em>Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$result = $this->IncludeBuffered(strtolower($action).'.php', '<em class="error">Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$this->StartLinkTracking();
return $result;
}
%%---
Now implemented as beta on this site. --JavaWoman
----
===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-adress 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
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===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
----
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
----
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
=== Image dimensions ===
The [[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 ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
=== 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;
%%
----
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
=== 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
----
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
===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''
----
===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
----
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
===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
----
CategoryDevelopmentSuggestions
Deletions:
Additions:
~-[[WikkaFolksonomy (Technorati) tags
Deletions:
~-[[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]]
----
=====Suggestions to be checked/migrated to the tracker=====
====making user uploaded images more useful====
have a look at my suggestion at FilesAction
----
===LinkTails for IE===
i am aware of the LinkTails discussion, but i am trying to push wikka in our corporate environment as a documentation tool and our standard is internet explorer and so however elegant **:after** is, it is not acceptable for me to shut out IE users like this. as firefox itself doesn't pass the acid2 test (as of writing) i would recommend waiting with these more "exotic" css features. and however i dislike IE, i don't want to cripple my IE users.
i also don't want to make the empty links different colored/styled as i think that this would disctract the users.
so i added
%%(php)
<span class=\"missingpagetail\"> [empty]</span>%%
before the ending </a> on line 659 of wikka.php and
%%(css)
.missingpagetail {
font-size: 10px;
}%%
in the css file.
----
===IE SCREW UP===
Does a fresh install not work at all with IE? Im getting a screen w/o any css formatting..
ANSWER:
Check the file ##wikka.config.php##
Probably you forgot the trailing slash at the end of your wikki path, Look for: "base_url"
--TomEk
===On WikiEdit===
Search within the textbox: its pain to find where you want to edit in long pages.
How about integrating a search function in wikiEdit, or implementing paragraph editing like wikipedia.
Also how about anchor in wikiedit and a way to link to them ?
--GiorgosKontopoulos
~&Hi George, have a look at AnchorAction (including my mods at the bottom of the page).
See http://www.dynamicdrive.com/dynamicindex11/findpage.htm for a "search in page" feature you might consider adding in. --GmBowen
=== 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
----
===Improved code for error messages in Action() method===
The ##Action()## method in ##wikka.php## produces errors in some cases; the error class was implemented as a span rather than directly on the <em> element surrounding the message. The span elements are superfluous and bad coding style.
Change:
%%(php;759) function Action($action, $forceLinkTracking = 0)
{
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
{
// treat everything after the first whitespace as parameter
preg_match("/^([A-Za-z0-9]*)\s+(.*)$/", $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all("/([A-Za-z0-9]*)=\"(.*)\"/U", $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[2][$a];
}
}
$vars["wikka_vars"] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>"; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
}
if (!preg_match("/^[a-zA-Z0-9]+$/", $action)) return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>";
if (!$forceLinkTracking) $this->StopLinkTracking();
$result = $this->IncludeBuffered(strtolower($action).".php", "<em>Unknown action \"$action\"</em>", $vars, $this->config["action_path"]);
$this->StartLinkTracking();
return $result;
}
%%---
to:
%%(php) // JW Action() modified to allow attributes in single quotes
// JW 2005-07-08 error class moved to em
function Action($action, $forceLinkTracking = 0)
{
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
{
// treat everything after the first whitespace as parameter
preg_match('/^([A-Za-z0-9]*)\s+(.*)$/', $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all('/([A-Za-z0-9]*)=("|\')(.*)\\2/U', $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[3][$a];
}
}
$vars['wikka_vars'] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
#return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
return '<em class="error">Unknown action; the action name must not contain special characters.</em>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
}
#if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>';
if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<em class="error">Unknown action; the action name must not contain special characters.</em>';
if (!$forceLinkTracking) $this->StopLinkTracking();
#$result = $this->IncludeBuffered(strtolower($action).'.php', '<em>Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$result = $this->IncludeBuffered(strtolower($action).'.php', '<em class="error">Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$this->StartLinkTracking();
return $result;
}
%%---
Now implemented as beta on this site. --JavaWoman
----
===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-adress 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
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===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
----
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
----
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
=== Image dimensions ===
The [[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 ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
=== 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;
%%
----
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
=== 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
----
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
===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''
----
===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
----
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
===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
----
CategoryDevelopmentSuggestions
Additions:
=====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]]
----
=====Suggestions to be checked/migrated to the tracker=====
====making user uploaded images more useful====
have a look at my suggestion at FilesAction
----
===LinkTails for IE===
i am aware of the LinkTails discussion, but i am trying to push wikka in our corporate environment as a documentation tool and our standard is internet explorer and so however elegant **:after** is, it is not acceptable for me to shut out IE users like this. as firefox itself doesn't pass the acid2 test (as of writing) i would recommend waiting with these more "exotic" css features. and however i dislike IE, i don't want to cripple my IE users.
i also don't want to make the empty links different colored/styled as i think that this would disctract the users.
so i added
%%(php)
<span class=\"missingpagetail\"> [empty]</span>%%
before the ending </a> on line 659 of wikka.php and
%%(css)
.missingpagetail {
font-size: 10px;
}%%
in the css file.
----
===IE SCREW UP===
Does a fresh install not work at all with IE? Im getting a screen w/o any css formatting..
ANSWER:
Check the file ##wikka.config.php##
Probably you forgot the trailing slash at the end of your wikki path, Look for: "base_url"
--TomEk
===On WikiEdit===
Search within the textbox: its pain to find where you want to edit in long pages.
How about integrating a search function in wikiEdit, or implementing paragraph editing like wikipedia.
Also how about anchor in wikiedit and a way to link to them ?
--GiorgosKontopoulos
~&Hi George, have a look at AnchorAction (including my mods at the bottom of the page).
See http://www.dynamicdrive.com/dynamicindex11/findpage.htm for a "search in page" feature you might consider adding in. --GmBowen
=== 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
----
===Improved code for error messages in Action() method===
The ##Action()## method in ##wikka.php## produces errors in some cases; the error class was implemented as a span rather than directly on the <em> element surrounding the message. The span elements are superfluous and bad coding style.
Change:
%%(php;759) function Action($action, $forceLinkTracking = 0)
{
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
{
// treat everything after the first whitespace as parameter
preg_match("/^([A-Za-z0-9]*)\s+(.*)$/", $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all("/([A-Za-z0-9]*)=\"(.*)\"/U", $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[2][$a];
}
}
$vars["wikka_vars"] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>"; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
}
if (!preg_match("/^[a-zA-Z0-9]+$/", $action)) return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>";
if (!$forceLinkTracking) $this->StopLinkTracking();
$result = $this->IncludeBuffered(strtolower($action).".php", "<em>Unknown action \"$action\"</em>", $vars, $this->config["action_path"]);
$this->StartLinkTracking();
return $result;
}
%%---
to:
%%(php) // JW Action() modified to allow attributes in single quotes
// JW 2005-07-08 error class moved to em
function Action($action, $forceLinkTracking = 0)
{
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
{
// treat everything after the first whitespace as parameter
preg_match('/^([A-Za-z0-9]*)\s+(.*)$/', $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all('/([A-Za-z0-9]*)=("|\')(.*)\\2/U', $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[3][$a];
}
}
$vars['wikka_vars'] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
#return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
return '<em class="error">Unknown action; the action name must not contain special characters.</em>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
}
#if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>';
if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<em class="error">Unknown action; the action name must not contain special characters.</em>';
if (!$forceLinkTracking) $this->StopLinkTracking();
#$result = $this->IncludeBuffered(strtolower($action).'.php', '<em>Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$result = $this->IncludeBuffered(strtolower($action).'.php', '<em class="error">Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$this->StartLinkTracking();
return $result;
}
%%---
Now implemented as beta on this site. --JavaWoman
----
===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-adress 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
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===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
----
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
----
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
=== Image dimensions ===
The [[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 ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
=== 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;
%%
----
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
=== 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
----
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
===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''
----
===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
----
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
===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
----
CategoryDevelopmentSuggestions
""<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]]
----
=====Suggestions to be checked/migrated to the tracker=====
====making user uploaded images more useful====
have a look at my suggestion at FilesAction
----
===LinkTails for IE===
i am aware of the LinkTails discussion, but i am trying to push wikka in our corporate environment as a documentation tool and our standard is internet explorer and so however elegant **:after** is, it is not acceptable for me to shut out IE users like this. as firefox itself doesn't pass the acid2 test (as of writing) i would recommend waiting with these more "exotic" css features. and however i dislike IE, i don't want to cripple my IE users.
i also don't want to make the empty links different colored/styled as i think that this would disctract the users.
so i added
%%(php)
<span class=\"missingpagetail\"> [empty]</span>%%
before the ending </a> on line 659 of wikka.php and
%%(css)
.missingpagetail {
font-size: 10px;
}%%
in the css file.
----
===IE SCREW UP===
Does a fresh install not work at all with IE? Im getting a screen w/o any css formatting..
ANSWER:
Check the file ##wikka.config.php##
Probably you forgot the trailing slash at the end of your wikki path, Look for: "base_url"
--TomEk
===On WikiEdit===
Search within the textbox: its pain to find where you want to edit in long pages.
How about integrating a search function in wikiEdit, or implementing paragraph editing like wikipedia.
Also how about anchor in wikiedit and a way to link to them ?
--GiorgosKontopoulos
~&Hi George, have a look at AnchorAction (including my mods at the bottom of the page).
See http://www.dynamicdrive.com/dynamicindex11/findpage.htm for a "search in page" feature you might consider adding in. --GmBowen
=== 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
----
===Improved code for error messages in Action() method===
The ##Action()## method in ##wikka.php## produces errors in some cases; the error class was implemented as a span rather than directly on the <em> element surrounding the message. The span elements are superfluous and bad coding style.
Change:
%%(php;759) function Action($action, $forceLinkTracking = 0)
{
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
{
// treat everything after the first whitespace as parameter
preg_match("/^([A-Za-z0-9]*)\s+(.*)$/", $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all("/([A-Za-z0-9]*)=\"(.*)\"/U", $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[2][$a];
}
}
$vars["wikka_vars"] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>"; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
}
if (!preg_match("/^[a-zA-Z0-9]+$/", $action)) return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>";
if (!$forceLinkTracking) $this->StopLinkTracking();
$result = $this->IncludeBuffered(strtolower($action).".php", "<em>Unknown action \"$action\"</em>", $vars, $this->config["action_path"]);
$this->StartLinkTracking();
return $result;
}
%%---
to:
%%(php) // JW Action() modified to allow attributes in single quotes
// JW 2005-07-08 error class moved to em
function Action($action, $forceLinkTracking = 0)
{
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
{
// treat everything after the first whitespace as parameter
preg_match('/^([A-Za-z0-9]*)\s+(.*)$/', $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all('/([A-Za-z0-9]*)=("|\')(.*)\\2/U', $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[3][$a];
}
}
$vars['wikka_vars'] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
#return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
return '<em class="error">Unknown action; the action name must not contain special characters.</em>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
}
#if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>';
if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<em class="error">Unknown action; the action name must not contain special characters.</em>';
if (!$forceLinkTracking) $this->StopLinkTracking();
#$result = $this->IncludeBuffered(strtolower($action).'.php', '<em>Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$result = $this->IncludeBuffered(strtolower($action).'.php', '<em class="error">Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$this->StartLinkTracking();
return $result;
}
%%---
Now implemented as beta on this site. --JavaWoman
----
===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-adress 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
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===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
----
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
----
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
=== Image dimensions ===
The [[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 ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
=== 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;
%%
----
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
=== 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
----
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
===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''
----
===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
----
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
===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
----
CategoryDevelopmentSuggestions
Deletions:
Ph JackaL AlganX PanZehir MezaRKabuL dænte Manasiyok GoDOfHaCk DanYaLL ZBiDy MctaLebe LoneLy.antaLya SÆRH@T
Kruis PeaCeR weBmasTer Yagmurcu YaduriS Ogantitan
Additions:
HaCKeD By ErD@L
Ph JackaL AlganX PanZehir MezaRKabuL dænte Manasiyok GoDOfHaCk DanYaLL ZBiDy MctaLebe LoneLy.antaLya SÆRH@T
Kruis PeaCeR weBmasTer Yagmurcu YaduriS Ogantitan
Ph JackaL AlganX PanZehir MezaRKabuL dænte Manasiyok GoDOfHaCk DanYaLL ZBiDy MctaLebe LoneLy.antaLya SÆRH@T
Kruis PeaCeR weBmasTer Yagmurcu YaduriS Ogantitan
Deletions:
""<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]]
----
=====Suggestions to be checked/migrated to the tracker=====
====making user uploaded images more useful====
have a look at my suggestion at FilesAction
----
===LinkTails for IE===
i am aware of the LinkTails discussion, but i am trying to push wikka in our corporate environment as a documentation tool and our standard is internet explorer and so however elegant **:after** is, it is not acceptable for me to shut out IE users like this. as firefox itself doesn't pass the acid2 test (as of writing) i would recommend waiting with these more "exotic" css features. and however i dislike IE, i don't want to cripple my IE users.
i also don't want to make the empty links different colored/styled as i think that this would disctract the users.
so i added
%%(php)
<span class=\"missingpagetail\"> [empty]</span>%%
before the ending </a> on line 659 of wikka.php and
%%(css)
.missingpagetail {
font-size: 10px;
}%%
in the css file.
----
===IE SCREW UP===
Does a fresh install not work at all with IE? Im getting a screen w/o any css formatting..
ANSWER:
Check the file ##wikka.config.php##
Probably you forgot the trailing slash at the end of your wikki path, Look for: "base_url"
--TomEk
===On WikiEdit===
Search within the textbox: its pain to find where you want to edit in long pages.
How about integrating a search function in wikiEdit, or implementing paragraph editing like wikipedia.
Also how about anchor in wikiedit and a way to link to them ?
--GiorgosKontopoulos
~&Hi George, have a look at AnchorAction (including my mods at the bottom of the page).
See http://www.dynamicdrive.com/dynamicindex11/findpage.htm for a "search in page" feature you might consider adding in. --GmBowen
=== 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
----
===Improved code for error messages in Action() method===
The ##Action()## method in ##wikka.php## produces errors in some cases; the error class was implemented as a span rather than directly on the <em> element surrounding the message. The span elements are superfluous and bad coding style.
Change:
%%(php;759) function Action($action, $forceLinkTracking = 0)
{
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
{
// treat everything after the first whitespace as parameter
preg_match("/^([A-Za-z0-9]*)\s+(.*)$/", $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all("/([A-Za-z0-9]*)=\"(.*)\"/U", $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[2][$a];
}
}
$vars["wikka_vars"] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>"; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
}
if (!preg_match("/^[a-zA-Z0-9]+$/", $action)) return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>";
if (!$forceLinkTracking) $this->StopLinkTracking();
$result = $this->IncludeBuffered(strtolower($action).".php", "<em>Unknown action \"$action\"</em>", $vars, $this->config["action_path"]);
$this->StartLinkTracking();
return $result;
}
%%---
to:
%%(php) // JW Action() modified to allow attributes in single quotes
// JW 2005-07-08 error class moved to em
function Action($action, $forceLinkTracking = 0)
{
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
{
// treat everything after the first whitespace as parameter
preg_match('/^([A-Za-z0-9]*)\s+(.*)$/', $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all('/([A-Za-z0-9]*)=("|\')(.*)\\2/U', $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[3][$a];
}
}
$vars['wikka_vars'] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
#return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
return '<em class="error">Unknown action; the action name must not contain special characters.</em>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
}
#if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>';
if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<em class="error">Unknown action; the action name must not contain special characters.</em>';
if (!$forceLinkTracking) $this->StopLinkTracking();
#$result = $this->IncludeBuffered(strtolower($action).'.php', '<em>Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$result = $this->IncludeBuffered(strtolower($action).'.php', '<em class="error">Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$this->StartLinkTracking();
return $result;
}
%%---
Now implemented as beta on this site. --JavaWoman
----
===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-adress 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
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===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
----
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
----
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
=== Image dimensions ===
The [[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 ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
=== 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;
%%
----
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
=== 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
----
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
===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''
----
===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
----
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
===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
----
CategoryDevelopmentSuggestions
Revision [15871]
Edited on 2007-01-10 06:40:47 by DarTar [cleaning up + updating some already migrated/solved issues]Additions:
[[Ticket:340]]
[[Ticket:230]]
=====Suggestions to be checked/migrated to the tracker=====
[[Ticket:230]]
=====Suggestions to be checked/migrated to the tracker=====
Deletions:
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
----
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) open a ##/raw## version of the page;
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
~1) open a text editor;
~1) copy the code block;
~1) paste it in the text editor;
~1) save the file.
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
Revision [15870]
Edited on 2007-01-10 03:05:15 by AndreasHeintze [cleaning up + updating some already migrated/solved issues]Additions:
~~& %%[[http://www.google.com Google target="_top"]]%%
Deletions:
Revision [15869]
Edited on 2007-01-10 03:04:48 by AndreasHeintze [cleaning up + updating some already migrated/solved issues]Additions:
~~& %%[[http://www.google.com My page target="_top"]]%%
Deletions:
Revision [15868]
Edited on 2007-01-10 03:02:37 by AndreasHeintze [cleaning up + updating some already migrated/solved issues]Additions:
~~& 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
~~& %%{{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
Deletions:
Revision [15867]
Edited on 2007-01-10 02:58:03 by AndreasHeintze [cleaning up + updating some already migrated/solved issues]Additions:
~~& I can now do forced links like this:
Deletions:
Revision [15866]
Edited on 2007-01-10 02:54:59 by AndreasHeintze [cleaning up + updating some already migrated/solved issues]Additions:
~~& 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 linkes like this:
~~& %%[[MyLittlePage My page target="_top"]]%%
~~&/AndreasHeintze
~~& %%(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 linkes like this:
~~& %%[[MyLittlePage My page target="_top"]]%%
~~&/AndreasHeintze
Revision [15844]
Edited on 2007-01-03 21:55:14 by BrianKoontz [Moved highlight discussion to ticket 281]Additions:
[[Ticket:281]]
Deletions:
Revision [15843]
Edited on 2007-01-03 21:53:44 by BrianKoontz [Moved highlight discussion to ticket 281]Additions:
[[Ticket: 281]]
Deletions:
I proposed an easy solution - HightlightSearch - which could replace the "show" handler. -- EmeraldIsland
Additions:
===Highlight text searched in a page ===
It might be nice to highlight the text searched in a page and not only in WikiEdit (despite you can find most things with Firefox search tool).
I proposed an easy solution - HightlightSearch - which could replace the "show" handler. -- EmeraldIsland
It might be nice to highlight the text searched in a page and not only in WikiEdit (despite you can find most things with Firefox search tool).
I proposed an easy solution - HightlightSearch - which could replace the "show" handler. -- EmeraldIsland
Revision [15372]
Edited on 2006-10-03 04:32:45 by DarTar [disabling feedback form - requests should be submitted to the tracker]Deletions:
Additions:
[[Ticket:259]]
[[Ticket:177]]
[[Ticket:175]]
[[Ticket:180]]
[[Ticket:258]]
===The access-key for "re-edit ===
[[Ticket:234]]
[[Ticket:177]]
[[Ticket:175]]
[[Ticket:180]]
[[Ticket:258]]
===The access-key for "re-edit ===
[[Ticket:234]]
Deletions:
Further info. If user 5 updates their personal diary at 1:00pm then the update they made (not their whole diary, just the latest entry or change) would display at the top of the consolidated diary page. If user 20 updates their diary at 1:05pm then their latest entry would appear just above user 5's latest updates on the consolidated page. Ideally the update would include the WIKI name of the source page/diary so you could click it to see the individuals diary in total.
Obviously this could have applications beyond a diary but that is the situation I am applying it to.
Any thoughts? Does this already exists under a different term? If it does I have not been able to find it.
I would like a function to export a static dump of all wiki pages a user has read access for for offline browsing. See Ticket:177
I think, it could be a nice idea to format links in pages corresponding to the user's right of reading the page, e.g. like it's already done with the recentlychanged action where page names only get linked when the user has the right to read the page. This might collide with user actions where she wants to create an already existing page. See Ticket:175
Additional, edit comments shouldn't be displayed for pages a user has no right to read. See Ticket:180
Another point: The access-key for "re-edit" is alt+p at the moment. Wouldn't alt+e be more logic? --NilsLindenberg
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
~~& Look at RobotFriendly for suggestions/solutions
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
Additions:
[[Ticket:44]]
[[Ticket:210]]
[[Ticket:211]]
[[Ticket:212]]
[[Ticket:213]]
[[Ticket:210]]
[[Ticket:211]]
[[Ticket:212]]
[[Ticket:213]]
Deletions:
Not sure where an appropriate place for feature requests is so here goes:
http://ross.typepad.com/blog/2005/08/wikiwyg.html
--gw.netwide.com.au (2005-08-22 02:28:01)
//now supports IE....see www.wikiwyg.net --GmBowen//
See [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --NilsLindenberg
~&Apparently Google uses **URLs** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our URLs inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). The only case I could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so Google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell Google to **not** follow the links on that page, Google can find orphan pages as well. So I don't really see how this could actually help, given the "lack of structure" of a wiki. --JavaWoman
In any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. While our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own Wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
The only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. There are two problems with this:
~1)Users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)Code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
Copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. If any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of Wikka). That leaves us with finding an escape method that's easy for users to implement.
There are two requirements for an "escaped" ""%%"" then:
~1)Easy to remember and apply by end users
~1)Not (not likely) part of the syntax of any language
One option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. A good candidate might be **DOUBLE_PERCENT** - it's easy enough to remember and easy to implement:
The formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to GeSHI for rendering; the grab code handler could just as easily replace it before making the code block available for download.
Thoughts anyone?
--JavaWoman
~&It's a good idea, but: You are sure DOUBLE_PERCENT is no reserved word in a language? Or unlikely to comme up in a code? --NilsLindenberg
~~&Try googling for 'DOUBLE_PERCENT': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). It's certainly not a reserved word in any of the languages GeSHi currently has support for, going by the language files it comes with. There's no way to be 100% certain but it seems to be a pretty safe bet. --JavaWoman
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
Additions:
[[Ticket:195]]
[[Ticket:196]]
[[Ticket:197]]
[[Ticket:196]]
[[Ticket:197]]
Deletions:
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
Revision [14377]
Edited on 2006-05-28 17:02:52 by NilsLindenberg [moving some issues to the tracker]Additions:
[[Ticket:73]]
[[Ticket:191]]
[[Ticket:192]]
[[Ticket:193]]
[[Ticket:161]]
[[Ticket:190]]
[[Ticket:191]]
[[Ticket:192]]
[[Ticket:193]]
[[Ticket:161]]
[[Ticket:190]]
Deletions:
it is trivial to add these, just edit actions/footer.php find the <a href>
and add //accesskey="key"//.
i have added "e" for edit, "h" history, "r" for revisions, and "s" for the searchbox.
it would be also nice to add "c" for ""CategoryCategory"" but i am not that
familiar with the header generating (yet).
Popular Scottish surnames such as McKenna are wrongly being interpreted as WikiNames - is there any way to prevent that happening?
-- host86-133-223-194.range86-133.btcentralplus.com (2005-07-09 13:23:06)
How about something like a lookup table where WikiAdmins enter a list of words that will be ignored for formatting on all pages? -- JsnX
~& Sounds like a nice addition. Two suggestions: 1) CamelCase parsing should be made optional in the config file. 2) the list of words to be skipped could be implemented as a wiki page (something similar has been proposed for menus, acronyms and group management): this would make it a lot easier to maintain the list. My 2 cents -- DarTar
~~& Displaying words with capital letters in the "middle" as WikiNames is a real problem. I don't want to turn off the automatic parsing because these words ARE WikiNames in most cases. It seems to me that a lookup table (e.g. a list of words as a wiki page) costs a lot of time to maintain. My suggestion is simple: "McKenna" should be interpreted as a wiki name. "Mc _ Kenna" (with underscore) should NOT be interpreted as a wiki name but written without underscore. "Mc _ _ Kenna" (with multiple underscores) should be converted to "Mc _ Kenna" (ignore the spaces, please). -- MichaelSchams
~~~& Ok this is probably stupid to point out but if you put double double quotes around words they aren't parsed by the wiki so if you want McKenna to not become a link you can say ""McKenna"" and voila... -- DanielMcNair (who has this problem regularly...) (-:
How can I import the Wikipedia database? I don't want to use MediaWiki. Any idea?
~& Sorry, there is no filter yet to convert MediaWiki content to WikkaWiki content, but it sounds like a nice feature suggestion. After all MW markup is quite stable... This said, do you //really// mean you want to import the actual Wikipedia database and have it run on a different wiki engine? -- DarTar
~& Yes, i want. It would be great. Maybe other sites will change to WikkaWikki when they can import a MediaWiki databse.
The current color formatting isn't very wiki like. Altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
%%^<color> text^%%
this regex syntax is lifted from a ""UseMod"" Wiki patch.
%%s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
I am by NO means a regex expert, but it seems that this should do the deal... I'm just not sure where it would go. By using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--MonstoBrukes
~&Please take a look at WikkaExtensibleMarkup --NilsLindenberg
~~&I looked at it. what point specifically did you intend i take from it?
~~~& JavaWoman had a proposal about a color-markup there. I think its the better place for the discussion. The recognition of markup is done in the formatter (formatters/wakka.php). I am no expert for regexps too, but wouldn't the first or catch too much? --NilsLindenberg
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
include ('Wakka.class.php');
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
Page output to an Adobe pdf file using FPDF.
Revision [14316]
Edited on 2006-05-23 07:07:48 by MasinAlDujaili [Ticket number corrected (176->175)]Additions:
I think, it could be a nice idea to format links in pages corresponding to the user's right of reading the page, e.g. like it's already done with the recentlychanged action where page names only get linked when the user has the right to read the page. This might collide with user actions where she wants to create an already existing page. See Ticket:175
Deletions:
Additions:
===Static HTML for offline browsing===
I would like a function to export a static dump of all wiki pages a user has read access for for offline browsing. See Ticket:177
===Link en- and disabling in respect to user rights===
I think, it could be a nice idea to format links in pages corresponding to the user's right of reading the page, e.g. like it's already done with the recentlychanged action where page names only get linked when the user has the right to read the page. This might collide with user actions where she wants to create an already existing page. See Ticket:176
===Edit comments displayed by user rights===
Additional, edit comments shouldn't be displayed for pages a user has no right to read. See Ticket:180
+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):
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
I would like a function to export a static dump of all wiki pages a user has read access for for offline browsing. See Ticket:177
===Link en- and disabling in respect to user rights===
I think, it could be a nice idea to format links in pages corresponding to the user's right of reading the page, e.g. like it's already done with the recentlychanged action where page names only get linked when the user has the right to read the page. This might collide with user actions where she wants to create an already existing page. See Ticket:176
===Edit comments displayed by user rights===
Additional, edit comments shouldn't be displayed for pages a user has no right to read. See Ticket:180
+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):
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Additions:
{{feedback}}
Deletions:
Revision [14305]
Edited on 2006-05-22 10:30:29 by NilsLindenberg [moved issues to trac, updated header]Additions:
[[Ticket:176]]
[[Ticket:21]]
A nice list of suggestions can be found at: [[http://smackaroo.net/by-blood-and-bone/MyNextWiki By Blood and bone]].
[[Ticket:21]]
A nice list of suggestions can be found at: [[http://smackaroo.net/by-blood-and-bone/MyNextWiki By Blood and bone]].
Deletions:
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
~-SuggestionsArchive for resolved suggestions
I've replaced the part
// use internal Wikka hilighter
$output = '<div class="code">'."\n";
$output .= $wakka->Format($code, $language);
$output .= "</div>\n";
with
// use internal Wikka hilighter
$wakka->formatter_nocode = false;
$output = $wakka->Format($code, $language);
if (!$wakka->formatter_nocode)
$output = '<div class="code">'."\n" . $output . "</div>\n";
in the file formatters/wakka.php to get this. This way I'm able to set $this->formatter_nocode=true in my formatter.
A nice list of suggestions can be found at: [[http://smackaroo.net/by-blood-and-bone/MyNextWiki By Blood and bone]].
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made it into a semi-spec.//
Every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
~-accept an //optional// parameter specifying an id and - if specified - use this to generate an id attribute
~-if the parameter is not specified, generate one using some algorithm to ensure it will be unique on the page (possibly using all provided parameters to create a hash, supplemented with a sequence number); only problem is this id might change when adding / inserting another form into a page but that could be worked around by actually specifying an id.
In addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). So the ##""FormOpen()""## method should also:
~-accept an //optional// parameter specifying a class and - if specified - use this to generate a class attribute (and no class attribute if not specified).
~&An implementation for this is now coded and tested (and will soon be added as a beta feature on this site). See AdvancedFormOpen and GenerateUniqueId for the code --JavaWoman
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
~& this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
Revision [14093]
Edited on 2006-05-04 14:01:46 by 24.113.139.159 [moved issues to trac, updated header]Additions:
===Is There a way to consolidate a bunch of page updates (the actual content that is) onto one page?===
In other words, If I had 20 users who all had a personal diary in the WIKI I would like to be able to have a single page where all 20 diaries would display their most recent updates in cronilogical order.
Further info. If user 5 updates their personal diary at 1:00pm then the update they made (not their whole diary, just the latest entry or change) would display at the top of the consolidated diary page. If user 20 updates their diary at 1:05pm then their latest entry would appear just above user 5's latest updates on the consolidated page. Ideally the update would include the WIKI name of the source page/diary so you could click it to see the individuals diary in total.
Obviously this could have applications beyond a diary but that is the situation I am applying it to.
Any thoughts? Does this already exists under a different term? If it does I have not been able to find it.
In other words, If I had 20 users who all had a personal diary in the WIKI I would like to be able to have a single page where all 20 diaries would display their most recent updates in cronilogical order.
Further info. If user 5 updates their personal diary at 1:00pm then the update they made (not their whole diary, just the latest entry or change) would display at the top of the consolidated diary page. If user 20 updates their diary at 1:05pm then their latest entry would appear just above user 5's latest updates on the consolidated page. Ideally the update would include the WIKI name of the source page/diary so you could click it to see the individuals diary in total.
Obviously this could have applications beyond a diary but that is the situation I am applying it to.
Any thoughts? Does this already exists under a different term? If it does I have not been able to find it.
Revision [13448]
Edited on 2006-03-12 19:09:12 by GiorgosKontopoulos [added link to SmiliesAction for PNG IE fix]Additions:
~~~& 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.
Revision [13446]
Edited on 2006-03-12 18:01:52 by GiorgosKontopoulos [RobotFriendly not RobotsFriendly]Additions:
~~& Look at RobotFriendly for suggestions/solutions
Deletions:
Additions:
===Please provide a way to add formatters, that don't get placed in '<div class = "code">'===
I've replaced the part
// use internal Wikka hilighter
$output = '<div class="code">'."\n";
$output .= $wakka->Format($code, $language);
$output .= "</div>\n";
with
// use internal Wikka hilighter
$wakka->formatter_nocode = false;
$output = $wakka->Format($code, $language);
if (!$wakka->formatter_nocode)
$output = '<div class="code">'."\n" . $output . "</div>\n";
in the file formatters/wakka.php to get this. This way I'm able to set $this->formatter_nocode=true in my formatter.
I've replaced the part
// use internal Wikka hilighter
$output = '<div class="code">'."\n";
$output .= $wakka->Format($code, $language);
$output .= "</div>\n";
with
// use internal Wikka hilighter
$wakka->formatter_nocode = false;
$output = $wakka->Format($code, $language);
if (!$wakka->formatter_nocode)
$output = '<div class="code">'."\n" . $output . "</div>\n";
in the file formatters/wakka.php to get this. This way I'm able to set $this->formatter_nocode=true in my formatter.
Additions:
~~& Look at RobotsFriendly for suggestions/solutions
Additions:
[[Ticket:123]]
Deletions:
~& Good point, agreed -- DarTar
===Documentation===
copied to DocumentationDiscussion. --NilsLindenberg
Additions:
[[Ticket:121]]
Deletions:
Additions:
[[Ticket121]]
Deletions:
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
Revision [12929]
Edited on 2006-01-19 10:54:38 by NilsLindenberg [moving some issues to the tracker]Additions:
[[Ticket:115]]
[[Ticket:116]]
[[Ticket:118]]
[[Ticket:117]]
[[Ticket:119]]
[[Ticket:116]]
[[Ticket:118]]
[[Ticket:117]]
[[Ticket:119]]
Deletions:
WikiJochen made a comment on my page that would like to see the latest comment shown first and not last. --NilsLindenberg
I think that it would be a good option to allow one to edit its own comments, sometimes, I make mistakes when commenting, typos or language things (i'm a foreigner) and I want my texts to all look clean.
Currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, I'm lazy, just like many other people. --SamuelDr
~&SamuelDr, this is a good suggestion. I've had the same thought about needing the ability to edit comments. The problem with "copy and then delete" is this can only be done until someone else comments. Otherwise the comments will be out of order. Consider it on the todo list for a future release. -- JsnX
//copied from a comment from AttachmentInfo --NilsLindenberg//
Does Wikka support versioning of attachments?
IMHO a good idea. --Nils
~&See allso WikkaLogicalDataModel --JavaWoman
By default PageIndex uses $this->""LoadAllPages""() which reads your **whole site** into one array. If you would use a new function like $this->""LoadAllPagesInfo""() you will get the same info but without the 'body' content. This should speed up PageIndex a bit on larger sites...
1) Find in ##wikka.php## (Around 33%)
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
And replace it with:
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }
function LoadAllPagesInfo() { return $this->LoadAll("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
1) Find in ##actions/pageindex.php## (top)
%%(php)if ($pages = $this->LoadAllPages())%%
And replace it with:
%%(php)if ($pages = $this->LoadAllPagesInfo())%%
1) Same trick as in (2) can be done in ##actions/mypages.php##...
-- OnegWR
~&See the first item on WikkaOptimization, too --NilsLindenberg
Single-click restore of previous versions (without copying/pasting). -Sam
~& ''Yes, this will be implemented at some point.'' - JsnX
~~&I should point out that there is an alternative to copying/pasting.
~~~& Go to the revisions page.
~~~& Click the date and time link that you would like to revert back to.
~~~& Click the 'Re-edit this old revision' button.
~~~& Click the 'Store' button.
Additions:
I think it would be a good ide to let the administrator choose if the field is mandatory.
[[Ticket:114]]
[[Ticket:114]]
Deletions:
If it is, the form doesn't submit until there is content into it, and it should warn too with an alertbox.
Only a little bit of PHP is necessary, the big part is in JS, if i don't make any mistake...
--SamuelDr
~& Actually, for the most basic validation, you don't even need any JS. I have implemented both, but the integration of the client side validation using JS is a bit of a hack (and needs to be streamlined, and own't currently work as an administrator setting), so I'm a bit hesistant to publish it (also I'm not sure on what page, I'm still a bit new here).
~& The server side validation goes like this. First, add a line to **wikka.config.php**:
~& %%(php) "edit_note_required" => true,%%
~& Then modify **handlers/page/edit.php**. Find the code that says
~& %%(php)
// check for overwriting
if ($this->page)
{
if ($this->page['id'] != $_POST['previous'])
{
$error = 'OVERWRITE ALERT: This page was modified by someone else while you were editing it.<br />'."\n".'Please copy your changes and re-edit this page.';
~& and modify it so it says:
~& %%(php)
// check for overwriting
if ($this->page)
{
if ($this->page['id'] != $_POST['previous'])
{
$error = 'OVERWRITE ALERT: This page was modified by someone else while you were editing it.<br />'."\n".'Please copy your changes and re-edit this page.';
// check for edit note
if ($this->config['edit_note_required'] && $_POST['note']=='')
{
$error .= 'EDIT NOTE ALERT: You must include an edit note!<br/>'."\n";
~& --CyneBeald
Deletions:
in my holy crusade of making wikka more corporate friendly i have rewritten another action.
my new ImageAction can be found here: http://obiit.org/wikka_patches/image_php.patch
it's nothing revolutionary, just a bit of cleanup, zapping empty class="" and a change of
philosophy: it's not checking for particular parameters, it takes anything. i find this sometimes
needed for onmouseover tricks, etc. so you just supply any number of attributes and they get added.
Additions:
====new ImageAction====
in my holy crusade of making wikka more corporate friendly i have rewritten another action.
my new ImageAction can be found here: http://obiit.org/wikka_patches/image_php.patch
it's nothing revolutionary, just a bit of cleanup, zapping empty class="" and a change of
philosophy: it's not checking for particular parameters, it takes anything. i find this sometimes
needed for onmouseover tricks, etc. so you just supply any number of attributes and they get added.
in my holy crusade of making wikka more corporate friendly i have rewritten another action.
my new ImageAction can be found here: http://obiit.org/wikka_patches/image_php.patch
it's nothing revolutionary, just a bit of cleanup, zapping empty class="" and a change of
philosophy: it's not checking for particular parameters, it takes anything. i find this sometimes
needed for onmouseover tricks, etc. so you just supply any number of attributes and they get added.
Additions:
""<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>""
<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>""
Deletions:
Additions:
====making user uploaded images more useful====
have a look at my suggestion at FilesAction
have a look at my suggestion at FilesAction
Additions:
before the ending </a> on line 659 of wikka.php and
Deletions:
Additions:
===LinkTails for IE===
i am aware of the LinkTails discussion, but i am trying to push wikka in our corporate environment as a documentation tool and our standard is internet explorer and so however elegant **:after** is, it is not acceptable for me to shut out IE users like this. as firefox itself doesn't pass the acid2 test (as of writing) i would recommend waiting with these more "exotic" css features. and however i dislike IE, i don't want to cripple my IE users.
i also don't want to make the empty links different colored/styled as i think that this would disctract the users.
so i added
<span class=\"missingpagetail\"> [empty]</span>%%
before the ending </a> on line 1206 of wikka.php and
%%(css)
.missingpagetail {
font-size: 10px;
in the css file.
i am aware of the LinkTails discussion, but i am trying to push wikka in our corporate environment as a documentation tool and our standard is internet explorer and so however elegant **:after** is, it is not acceptable for me to shut out IE users like this. as firefox itself doesn't pass the acid2 test (as of writing) i would recommend waiting with these more "exotic" css features. and however i dislike IE, i don't want to cripple my IE users.
i also don't want to make the empty links different colored/styled as i think that this would disctract the users.
so i added
<span class=\"missingpagetail\"> [empty]</span>%%
before the ending </a> on line 1206 of wikka.php and
%%(css)
.missingpagetail {
font-size: 10px;
in the css file.
Additions:
it would be also nice to add "c" for ""CategoryCategory"" but i am not that
Deletions:
should i submit this as a patch? how does one submit patches?
Additions:
~& Yeah, so I found this... RefactorWiki which supposedly does exactly that (I haven't tested it personally) - JonathanMitchem
Deletions:
Additions:
~& Yeah, so I found this... RefactorWiki which supposedly does exactly that (hasn't been tested)
Additions:
===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
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
Revision [12224]
Edited on 2005-12-11 05:25:46 by ip70-189-80-200.ok.ok.cox.net [a little comment on the McKenna issue]Additions:
~~~& Ok this is probably stupid to point out but if you put double double quotes around words they aren't parsed by the wiki so if you want McKenna to not become a link you can say ""McKenna"" and voila... -- DanielMcNair (who has this problem regularly...) (-:
Revision [12175]
Edited on 2005-12-09 10:46:48 by prgdc007.dhl.com [a little comment on the McKenna issue]Additions:
===Accesskeys for the footer functions===
accesskeys are great for more tech savvy users, a real time saver.
it is trivial to add these, just edit actions/footer.php find the <a href>
and add //accesskey="key"//.
i have added "e" for edit, "h" history, "r" for revisions, and "s" for the searchbox.
it would be also nice to add "c" for ""CategoryCategory"" but the i am not that
familiar with the header generating (yet).
should i submit this as a patch? how does one submit patches?
accesskeys are great for more tech savvy users, a real time saver.
it is trivial to add these, just edit actions/footer.php find the <a href>
and add //accesskey="key"//.
i have added "e" for edit, "h" history, "r" for revisions, and "s" for the searchbox.
it would be also nice to add "c" for ""CategoryCategory"" but the i am not that
familiar with the header generating (yet).
should i submit this as a patch? how does one submit patches?
Revision [12172]
Edited on 2005-12-09 00:20:46 by NickDamoulakis [a little comment on the McKenna issue]Additions:
~&Hi George, have a look at AnchorAction (including my mods at the bottom of the page).
Revision [12170]
Edited on 2005-12-08 22:57:01 by CyneBeald ["Note on edit, mandatory field" - added code for server side validation]Additions:
~& Actually, for the most basic validation, you don't even need any JS. I have implemented both, but the integration of the client side validation using JS is a bit of a hack (and needs to be streamlined, and own't currently work as an administrator setting), so I'm a bit hesistant to publish it (also I'm not sure on what page, I'm still a bit new here).
~& The server side validation goes like this. First, add a line to **wikka.config.php**:
~& %%(php) "edit_note_required" => true,%%
~& Then modify **handlers/page/edit.php**. Find the code that says
~& %%(php)
// check for overwriting
if ($this->page)
{
if ($this->page['id'] != $_POST['previous'])
{
$error = 'OVERWRITE ALERT: This page was modified by someone else while you were editing it.<br />'."\n".'Please copy your changes and re-edit this page.';
~& and modify it so it says:
~& %%(php)
// check for overwriting
if ($this->page)
{
if ($this->page['id'] != $_POST['previous'])
{
$error = 'OVERWRITE ALERT: This page was modified by someone else while you were editing it.<br />'."\n".'Please copy your changes and re-edit this page.';
// check for edit note
if ($this->config['edit_note_required'] && $_POST['note']=='')
{
$error .= 'EDIT NOTE ALERT: You must include an edit note!<br/>'."\n";
~& --CyneBeald
~& The server side validation goes like this. First, add a line to **wikka.config.php**:
~& %%(php) "edit_note_required" => true,%%
~& Then modify **handlers/page/edit.php**. Find the code that says
~& %%(php)
// check for overwriting
if ($this->page)
{
if ($this->page['id'] != $_POST['previous'])
{
$error = 'OVERWRITE ALERT: This page was modified by someone else while you were editing it.<br />'."\n".'Please copy your changes and re-edit this page.';
~& and modify it so it says:
~& %%(php)
// check for overwriting
if ($this->page)
{
if ($this->page['id'] != $_POST['previous'])
{
$error = 'OVERWRITE ALERT: This page was modified by someone else while you were editing it.<br />'."\n".'Please copy your changes and re-edit this page.';
// check for edit note
if ($this->config['edit_note_required'] && $_POST['note']=='')
{
$error .= 'EDIT NOTE ALERT: You must include an edit note!<br/>'."\n";
~& --CyneBeald
Additions:
""<div style="width:46%; float:center; 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. Should you need to report new bugs/issues or suggest new features, you are invited to use the tracker. Thanks for your understanding.</p></div>""
Deletions:
Additions:
""<div style="width:46%; float:center; 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. Should you need to report new bugs/issues, you are invited to use the new tracker. Thanks for your understanding.</p></div>""
Deletions:
Additions:
""<div style="width:50%; float:center; 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. Should you need to report new bugs/issues, you are invited to use the new tracker. Thanks for your understanding.</p></div>""
Deletions:
Additions:
~& 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
~& %%(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
Additions:
~~& Displaying words with capital letters in the "middle" as WikiNames is a real problem. I don't want to turn off the automatic parsing because these words ARE WikiNames in most cases. It seems to me that a lookup table (e.g. a list of words as a wiki page) costs a lot of time to maintain. My suggestion is simple: "McKenna" should be interpreted as a wiki name. "Mc _ Kenna" (with underscore) should NOT be interpreted as a wiki name but written without underscore. "Mc _ _ Kenna" (with multiple underscores) should be converted to "Mc _ Kenna" (ignore the spaces, please). -- MichaelSchams
Deletions:
Additions:
~~& Displaying words with capital letters in the "middle" as WikiNames is a real problem. I don't want to turn off the automatic parsing because these words ARE WikiNames in most cases. It seems to me that a lookup table (e.g. a list of words as a wiki page) costs a lot of time to maintain. My suggestion is simple: **McKenna** should be interpreted as a wiki name. **Mc_Kenna** (with underscore) should NOT be interpreted as a wiki name but written without underscore. **Mc__Kenna** (with multiple underscores) should be converted to Mc_Kenna. -- MichaelSchams
Additions:
""<div style="width:50%; float:center; padding:5px; background-color:#F66; border:1px solid #F33"><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. Should you need to report new bugs/issues, you are invited to use the new tracker. Thanks for your understanding.</p></div>""
Deletions:
Additions:
""<div style="width:60%; float:center; padding:5px; background-color:#F66; border:1px solid #F33"><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. Should you need to report new bugs/issues, you are invited to use the new tracker. Thanks for your understanding.</p></div>""
Deletions:
Additions:
""<div style="width:60%; float:center; padding:5px; background-color:#F66; border:1px solid #F33"><h5>New Wikka Tracker available</h5><p>We are happy to announce that Wikka has just opened a dedicated <a href="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. Should you need to report new bugs/issues, you are invited to use the new tracker. Thanks for your understanding.</p></div>""
Deletions:
Revision [11673]
Edited on 2005-11-06 15:51:11 by GmBowen [answer re: in-page search box for wikiedit]Additions:
See http://www.dynamicdrive.com/dynamicindex11/findpage.htm for a "search in page" feature you might consider adding in. --GmBowen
Revision [11669]
Edited on 2005-11-06 11:50:41 by oxfd-cache-2.server.ntli.net [answer re: in-page search box for wikiedit]Deletions:
Revision [11639]
Edited on 2005-10-29 15:14:24 by MichaelElsdoerfer [answer re: in-page search box for wikiedit]Additions:
===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?
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?
Revision [11628]
Edited on 2005-10-27 15:17:47 by c220-237-177-122.lowrp1.vic.optusnet.com.au [answer re: in-page search box for wikiedit]Additions:
=== Automatic conversion from HTML to WakkiWiki syntax ===
Does such thing exist? For a number of other Wikies, it does.
Does such thing exist? For a number of other Wikies, it does.
Deletions:
Does such think exist? For a number of other Wikies, it does.
Revision [11453]
Edited on 2005-10-16 23:53:19 by TomEk [answer re: in-page search box for wikiedit]Additions:
ANSWER:
Check the file ##wikka.config.php##
Probably you forgot the trailing slash at the end of your wikki path, Look for: "base_url"
--TomEk
Check the file ##wikka.config.php##
Probably you forgot the trailing slash at the end of your wikki path, Look for: "base_url"
--TomEk
Revision [11314]
Edited on 2005-10-09 09:27:49 by c-71-57-125-210.hsd1.il.comcast.net [answer re: in-page search box for wikiedit]Additions:
===IE SCREW UP===
Does a fresh install not work at all with IE? Im getting a screen w/o any css formatting..
Does a fresh install not work at all with IE? Im getting a screen w/o any css formatting..
Revision [11306]
Edited on 2005-10-08 03:28:26 by GmBowen [answer re: in-page search box for wikiedit]Additions:
//now supports IE....see www.wikiwyg.net --GmBowen//
//wikka convertor currently not working --GmBowen//
//wikka convertor currently not working --GmBowen//
Revision [11303]
Edited on 2005-10-07 22:58:38 by GiorgosKontopoulos [answer re: in-page search box for wikiedit]Additions:
===On WikiEdit===
Search within the textbox: its pain to find where you want to edit in long pages.
How about integrating a search function in wikiEdit, or implementing paragraph editing like wikipedia.
Also how about anchor in wikiedit and a way to link to them ?
--GiorgosKontopoulos
Search within the textbox: its pain to find where you want to edit in long pages.
How about integrating a search function in wikiEdit, or implementing paragraph editing like wikipedia.
Also how about anchor in wikiedit and a way to link to them ?
--GiorgosKontopoulos
Additions:
--gw.netwide.com.au (2005-08-22 02:28:01)
Revision [10793]
Edited on 2005-08-22 15:16:18 by NilsLindenberg [added suggestion from UnderDevelopment]Additions:
===wikiwyg===
//copied from UnderDevelopment --NilsLindenberg//
Not sure where an appropriate place for feature requests is so here goes:
http://ross.typepad.com/blog/2005/08/wikiwyg.html
//copied from UnderDevelopment --NilsLindenberg//
Not sure where an appropriate place for feature requests is so here goes:
http://ross.typepad.com/blog/2005/08/wikiwyg.html
Additions:
=====Suggestion Box=====
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
~-SuggestionsArchive for resolved suggestions
**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]]
~-UserMap
=== Automatic conversoin from HTML to WakkiWiki syntax ===
Does such think 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
===Improved code for error messages in Action() method===
The ##Action()## method in ##wikka.php## produces errors in some cases; the error class was implemented as a span rather than directly on the <em> element surrounding the message. The span elements are superfluous and bad coding style.
Change:
%%(php;759) function Action($action, $forceLinkTracking = 0)
preg_match("/^([A-Za-z0-9]*)\s+(.*)$/", $action, $matches);
preg_match_all("/([A-Za-z0-9]*)=\"(.*)\"/U", $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>"; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
if (!preg_match("/^[a-zA-Z0-9]+$/", $action)) return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>";
if (!$forceLinkTracking) $this->StopLinkTracking();
$result = $this->IncludeBuffered(strtolower($action).".php", "<em>Unknown action \"$action\"</em>", $vars, $this->config["action_path"]);
$this->StartLinkTracking();
%%(php) // JW Action() modified to allow attributes in single quotes
// JW 2005-07-08 error class moved to em
function Action($action, $forceLinkTracking = 0)
preg_match('/^([A-Za-z0-9]*)\s+(.*)$/', $action, $matches);
preg_match_all('/([A-Za-z0-9]*)=("|\')(.*)\\2/U', $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
#return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
return '<em class="error">Unknown action; the action name must not contain special characters.</em>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
#if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>';
if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<em class="error">Unknown action; the action name must not contain special characters.</em>';
if (!$forceLinkTracking) $this->StopLinkTracking();
#$result = $this->IncludeBuffered(strtolower($action).'.php', '<em>Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$result = $this->IncludeBuffered(strtolower($action).'.php', '<em class="error">Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$this->StartLinkTracking();
Now implemented as beta on this site. --JavaWoman
===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
===Exclude certain CamelCase words from formatting===
Popular Scottish surnames such as McKenna are wrongly being interpreted as WikiNames - is there any way to prevent that happening?
How about something like a lookup table where WikiAdmins enter a list of words that will be ignored for formatting on all pages? -- JsnX
~& Sounds like a nice addition. Two suggestions: 1) CamelCase parsing should be made optional in the config file. 2) the list of words to be skipped could be implemented as a wiki page (something similar has been proposed for menus, acronyms and group management): this would make it a lot easier to maintain the list. My 2 cents -- DarTar
===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]].
===Import WikiPedia database===
How can I import the Wikipedia database? I don't want to use MediaWiki. Any idea?
~& Sorry, there is no filter yet to convert MediaWiki content to WikkaWiki content, but it sounds like a nice feature suggestion. After all MW markup is quite stable... This said, do you //really// mean you want to import the actual Wikipedia database and have it run on a different wiki engine? -- DarTar
~& Yes, i want. It would be great. Maybe other sites will change to WikkaWikki when they can import a MediaWiki databse.
===Note on edit, mandatory field===
I think it would be a good ide to let the administrator choose if the field is mandatory.
If it is, the form doesn't submit until there is content into it, and it should warn too with an alertbox.
Only a little bit of PHP is necessary, the big part is in JS, if i don't make any mistake...
--SamuelDr
===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.
if ($existingUser["password"] == md5($_POST["password"]) || $existingUser["password"]==$_POST["password"])
This is the current version:
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
===Order of comments===
WikiJochen made a comment on my page that would like to see the latest comment shown first and not last. --NilsLindenberg
===Own comments editing===
I think that it would be a good option to allow one to edit its own comments, sometimes, I make mistakes when commenting, typos or language things (i'm a foreigner) and I want my texts to all look clean.
Currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, I'm lazy, just like many other people. --SamuelDr
~&SamuelDr, this is a good suggestion. I've had the same thought about needing the ability to edit comments. The problem with "copy and then delete" is this can only be done until someone else comments. Otherwise the comments will be out of order. Consider it on the todo list for a future release. -- JsnX
===Google Sitemap===
See [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --NilsLindenberg
~&Apparently Google uses **URLs** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our URLs inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). The only case I could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so Google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell Google to **not** follow the links on that page, Google can find orphan pages as well. So I don't really see how this could actually help, given the "lack of structure" of a wiki. --JavaWoman
//copied from a comment from AttachmentInfo --NilsLindenberg//
Does Wikka support versioning of attachments?
IMHO a good idea. --Nils
~&See allso WikkaLogicalDataModel --JavaWoman
===Making PageIndex go faster===
By default PageIndex uses $this->""LoadAllPages""() which reads your **whole site** into one array. If you would use a new function like $this->""LoadAllPagesInfo""() you will get the same info but without the 'body' content. This should speed up PageIndex a bit on larger sites...
1) Find in ##wikka.php## (Around 33%)
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
And replace it with:
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }
function LoadAllPagesInfo() { return $this->LoadAll("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
1) Find in ##actions/pageindex.php## (top)
%%(php)if ($pages = $this->LoadAllPages())%%
And replace it with:
%%(php)if ($pages = $this->LoadAllPagesInfo())%%
1) Same trick as in (2) can be done in ##actions/mypages.php##...
-- OnegWR
~&See the first item on WikkaOptimization, too --NilsLindenberg
===Generate ID in forms; allow class===
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made it into a semi-spec.//
Every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
In addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). So the ##""FormOpen()""## method should also:
--JavaWoman
~&An implementation for this is now coded and tested (and will soon be added as a beta feature on this site). See AdvancedFormOpen and GenerateUniqueId for the code --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");
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-adress 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
===Single-click restore of previous versions===
//copied from WikkaBugs - this is a suggestion, not a bug --NilsLindenberg//
Single-click restore of previous versions (without copying/pasting). -Sam
~& ''Yes, this will be implemented at some point.'' - JsnX
~~&I should point out that there is an alternative to copying/pasting.
~~~& Go to the revisions page.
~~~& Click the date and time link that you would like to revert back to.
~~~& Click the 'Re-edit this old revision' button.
~~~& Click the 'Store' button.
In any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. While our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own Wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
The only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. There are two problems with this:
~1)Users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)Code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
Copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. If any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of Wikka). That leaves us with finding an escape method that's easy for users to implement.
There are two requirements for an "escaped" ""%%"" then:
~1)Easy to remember and apply by end users
~1)Not (not likely) part of the syntax of any language
One option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. A good candidate might be **DOUBLE_PERCENT** - it's easy enough to remember and easy to implement:
The formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to GeSHI for rendering; the grab code handler could just as easily replace it before making the code block available for download.
Thoughts anyone?
--JavaWoman
~&It's a good idea, but: You are sure DOUBLE_PERCENT is no reserved word in a language? Or unlikely to comme up in a code? --NilsLindenberg
~~&Try googling for 'DOUBLE_PERCENT': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). It's certainly not a reserved word in any of the languages GeSHi currently has support for, going by the language files it comes with. There's no way to be 100% certain but it seems to be a pretty safe bet. --JavaWoman
===Preview===
A doubleclick on a page in the preview should lead to "re-edit" of the text. --NilsLindenberg
~& Good point, agreed -- DarTar
Another point: The access-key for "re-edit" is alt+p at the moment. Wouldn't alt+e be more logic? --NilsLindenberg
===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
===Color Formatting===
The current color formatting isn't very wiki like. Altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
this regex syntax is lifted from a ""UseMod"" Wiki patch.
%%s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
I am by NO means a regex expert, but it seems that this should do the deal... I'm just not sure where it would go. By using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--MonstoBrukes
~&Please take a look at WikkaExtensibleMarkup --NilsLindenberg
~~&I looked at it. what point specifically did you intend i take from it?
~~~& JavaWoman had a proposal about a color-markup there. I think its the better place for the discussion. The recognition of markup is done in the formatter (formatters/wakka.php). I am no expert for regexps too, but wouldn't the first or catch too much? --NilsLindenberg
===Integration into existing site===
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
===Documentation===
copied to DocumentationDiscussion. --NilsLindenberg
===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:
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
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
===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
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
~~& 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
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
===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"))
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
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
include ('Wakka.class.php');
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
===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):
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
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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:
~&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
Is there a way to include a target in a link, so that the Link opens in a new window?
--GregorLindner
===Signature===
//(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)//
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
=== 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
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-- KarmaTester (2005-01-26 06:52:07)
=== Image dimensions ===
The [[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
===Clearing ACLs===
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
function ExistsEmail($email)
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
return ($count > 0) ? TRUE : FALSE;
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
=== RSS options ===
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
=== 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
if ($pages = $this->LoadPagesLinkingTo($this->getPageTag())) {
$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
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
=== 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!";
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
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
===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
===Local links===
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--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...
- 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''
===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
===Online editing of mindmaps would be great===
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
===How to format code to get two % characters without space together?===
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
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:
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?:
$timestamp = $wakka->GetPageTime(); //hopefully this function returns the right format?
return (++$trigger_deleted % 2 ? "<DEL datetime=\"$timestamp\">" : "</DEL>");
--NilsLindenberg
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
===Language support===
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
=== 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
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
~& this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
=== 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
The edit page handler seems to convert spaces to tabs throughout the entire document, including Code blocks.
**From edit.php**
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
===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
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
CategoryDevelopmentSuggestions
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
~-SuggestionsArchive for resolved suggestions
**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]]
~-UserMap
=== Automatic conversoin from HTML to WakkiWiki syntax ===
Does such think 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
===Improved code for error messages in Action() method===
The ##Action()## method in ##wikka.php## produces errors in some cases; the error class was implemented as a span rather than directly on the <em> element surrounding the message. The span elements are superfluous and bad coding style.
Change:
%%(php;759) function Action($action, $forceLinkTracking = 0)
preg_match("/^([A-Za-z0-9]*)\s+(.*)$/", $action, $matches);
preg_match_all("/([A-Za-z0-9]*)=\"(.*)\"/U", $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>"; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
if (!preg_match("/^[a-zA-Z0-9]+$/", $action)) return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>";
if (!$forceLinkTracking) $this->StopLinkTracking();
$result = $this->IncludeBuffered(strtolower($action).".php", "<em>Unknown action \"$action\"</em>", $vars, $this->config["action_path"]);
$this->StartLinkTracking();
%%(php) // JW Action() modified to allow attributes in single quotes
// JW 2005-07-08 error class moved to em
function Action($action, $forceLinkTracking = 0)
preg_match('/^([A-Za-z0-9]*)\s+(.*)$/', $action, $matches);
preg_match_all('/([A-Za-z0-9]*)=("|\')(.*)\\2/U', $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
#return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
return '<em class="error">Unknown action; the action name must not contain special characters.</em>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
#if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>';
if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<em class="error">Unknown action; the action name must not contain special characters.</em>';
if (!$forceLinkTracking) $this->StopLinkTracking();
#$result = $this->IncludeBuffered(strtolower($action).'.php', '<em>Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$result = $this->IncludeBuffered(strtolower($action).'.php', '<em class="error">Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$this->StartLinkTracking();
Now implemented as beta on this site. --JavaWoman
===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
===Exclude certain CamelCase words from formatting===
Popular Scottish surnames such as McKenna are wrongly being interpreted as WikiNames - is there any way to prevent that happening?
How about something like a lookup table where WikiAdmins enter a list of words that will be ignored for formatting on all pages? -- JsnX
~& Sounds like a nice addition. Two suggestions: 1) CamelCase parsing should be made optional in the config file. 2) the list of words to be skipped could be implemented as a wiki page (something similar has been proposed for menus, acronyms and group management): this would make it a lot easier to maintain the list. My 2 cents -- DarTar
===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]].
===Import WikiPedia database===
How can I import the Wikipedia database? I don't want to use MediaWiki. Any idea?
~& Sorry, there is no filter yet to convert MediaWiki content to WikkaWiki content, but it sounds like a nice feature suggestion. After all MW markup is quite stable... This said, do you //really// mean you want to import the actual Wikipedia database and have it run on a different wiki engine? -- DarTar
~& Yes, i want. It would be great. Maybe other sites will change to WikkaWikki when they can import a MediaWiki databse.
===Note on edit, mandatory field===
I think it would be a good ide to let the administrator choose if the field is mandatory.
If it is, the form doesn't submit until there is content into it, and it should warn too with an alertbox.
Only a little bit of PHP is necessary, the big part is in JS, if i don't make any mistake...
--SamuelDr
===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.
if ($existingUser["password"] == md5($_POST["password"]) || $existingUser["password"]==$_POST["password"])
This is the current version:
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
===Order of comments===
WikiJochen made a comment on my page that would like to see the latest comment shown first and not last. --NilsLindenberg
===Own comments editing===
I think that it would be a good option to allow one to edit its own comments, sometimes, I make mistakes when commenting, typos or language things (i'm a foreigner) and I want my texts to all look clean.
Currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, I'm lazy, just like many other people. --SamuelDr
~&SamuelDr, this is a good suggestion. I've had the same thought about needing the ability to edit comments. The problem with "copy and then delete" is this can only be done until someone else comments. Otherwise the comments will be out of order. Consider it on the todo list for a future release. -- JsnX
===Google Sitemap===
See [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --NilsLindenberg
~&Apparently Google uses **URLs** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our URLs inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). The only case I could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so Google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell Google to **not** follow the links on that page, Google can find orphan pages as well. So I don't really see how this could actually help, given the "lack of structure" of a wiki. --JavaWoman
//copied from a comment from AttachmentInfo --NilsLindenberg//
Does Wikka support versioning of attachments?
IMHO a good idea. --Nils
~&See allso WikkaLogicalDataModel --JavaWoman
===Making PageIndex go faster===
By default PageIndex uses $this->""LoadAllPages""() which reads your **whole site** into one array. If you would use a new function like $this->""LoadAllPagesInfo""() you will get the same info but without the 'body' content. This should speed up PageIndex a bit on larger sites...
1) Find in ##wikka.php## (Around 33%)
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
And replace it with:
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }
function LoadAllPagesInfo() { return $this->LoadAll("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
1) Find in ##actions/pageindex.php## (top)
%%(php)if ($pages = $this->LoadAllPages())%%
And replace it with:
%%(php)if ($pages = $this->LoadAllPagesInfo())%%
1) Same trick as in (2) can be done in ##actions/mypages.php##...
-- OnegWR
~&See the first item on WikkaOptimization, too --NilsLindenberg
===Generate ID in forms; allow class===
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made it into a semi-spec.//
Every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
In addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). So the ##""FormOpen()""## method should also:
--JavaWoman
~&An implementation for this is now coded and tested (and will soon be added as a beta feature on this site). See AdvancedFormOpen and GenerateUniqueId for the code --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");
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-adress 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
===Single-click restore of previous versions===
//copied from WikkaBugs - this is a suggestion, not a bug --NilsLindenberg//
Single-click restore of previous versions (without copying/pasting). -Sam
~& ''Yes, this will be implemented at some point.'' - JsnX
~~&I should point out that there is an alternative to copying/pasting.
~~~& Go to the revisions page.
~~~& Click the date and time link that you would like to revert back to.
~~~& Click the 'Re-edit this old revision' button.
~~~& Click the 'Store' button.
In any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. While our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own Wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
The only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. There are two problems with this:
~1)Users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)Code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
Copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. If any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of Wikka). That leaves us with finding an escape method that's easy for users to implement.
There are two requirements for an "escaped" ""%%"" then:
~1)Easy to remember and apply by end users
~1)Not (not likely) part of the syntax of any language
One option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. A good candidate might be **DOUBLE_PERCENT** - it's easy enough to remember and easy to implement:
The formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to GeSHI for rendering; the grab code handler could just as easily replace it before making the code block available for download.
Thoughts anyone?
--JavaWoman
~&It's a good idea, but: You are sure DOUBLE_PERCENT is no reserved word in a language? Or unlikely to comme up in a code? --NilsLindenberg
~~&Try googling for 'DOUBLE_PERCENT': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). It's certainly not a reserved word in any of the languages GeSHi currently has support for, going by the language files it comes with. There's no way to be 100% certain but it seems to be a pretty safe bet. --JavaWoman
===Preview===
A doubleclick on a page in the preview should lead to "re-edit" of the text. --NilsLindenberg
~& Good point, agreed -- DarTar
Another point: The access-key for "re-edit" is alt+p at the moment. Wouldn't alt+e be more logic? --NilsLindenberg
===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
===Color Formatting===
The current color formatting isn't very wiki like. Altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
this regex syntax is lifted from a ""UseMod"" Wiki patch.
%%s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
I am by NO means a regex expert, but it seems that this should do the deal... I'm just not sure where it would go. By using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--MonstoBrukes
~&Please take a look at WikkaExtensibleMarkup --NilsLindenberg
~~&I looked at it. what point specifically did you intend i take from it?
~~~& JavaWoman had a proposal about a color-markup there. I think its the better place for the discussion. The recognition of markup is done in the formatter (formatters/wakka.php). I am no expert for regexps too, but wouldn't the first or catch too much? --NilsLindenberg
===Integration into existing site===
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
===Documentation===
copied to DocumentationDiscussion. --NilsLindenberg
===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:
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
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
===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
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
~~& 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
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
===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"))
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
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
include ('Wakka.class.php');
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
===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):
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
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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:
~&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
Is there a way to include a target in a link, so that the Link opens in a new window?
--GregorLindner
===Signature===
//(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)//
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
=== 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
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-- KarmaTester (2005-01-26 06:52:07)
=== Image dimensions ===
The [[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
===Clearing ACLs===
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
function ExistsEmail($email)
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
return ($count > 0) ? TRUE : FALSE;
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
=== RSS options ===
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
=== 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
if ($pages = $this->LoadPagesLinkingTo($this->getPageTag())) {
$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
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
=== 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!";
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
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
===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
===Local links===
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--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...
- 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''
===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
===Online editing of mindmaps would be great===
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
===How to format code to get two % characters without space together?===
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
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:
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?:
$timestamp = $wakka->GetPageTime(); //hopefully this function returns the right format?
return (++$trigger_deleted % 2 ? "<DEL datetime=\"$timestamp\">" : "</DEL>");
--NilsLindenberg
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
===Language support===
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
=== 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
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
~& this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
=== 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
The edit page handler seems to convert spaces to tabs throughout the entire document, including Code blocks.
**From edit.php**
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
===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
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
CategoryDevelopmentSuggestions
Deletions:
=====suggestion box=====
feedback is welcomed and appreciated. use the form or edit this page.
**please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== bugs vs. feature suggestions ===
please post issues/bugs to the appropriate page:
~-general bugs/issues: wikkabugs
~-css layout issues: wikkacss
~-suggestionsarchive for resolved suggestions
**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]]
~-usermap
=== automatic conversoin from html to wakkiwiki syntax ===
does such think 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
===improved code for error messages in action() method===
the ##action()## method in ##wikka.php## produces errors in some cases; the error class was implemented as a span rather than directly on the <em> element surrounding the message. the span elements are superfluous and bad coding style.
change:
%%(php;759) function action($action, $forcelinktracking = 0)
preg_match("/^([a-za-z0-9]*)\s+(.*)$/", $action, $matches);
preg_match_all("/([a-za-z0-9]*)=\"(.*)\"/u", $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->includebuffered())
return "<span class='error'><em>unknown action; the action name must not contain special characters.</em></span>"; // <<< the pattern ([a-za-z0-9])\s+ didn't match!
if (!preg_match("/^[a-za-z0-9]+$/", $action)) return "<span class='error'><em>unknown action; the action name must not contain special characters.</em></span>";
if (!$forcelinktracking) $this->stoplinktracking();
$result = $this->includebuffered(strtolower($action).".php", "<em>unknown action \"$action\"</em>", $vars, $this->config["action_path"]);
$this->startlinktracking();
%%(php) // jw action() modified to allow attributes in single quotes
// jw 2005-07-08 error class moved to em
function action($action, $forcelinktracking = 0)
preg_match('/^([a-za-z0-9]*)\s+(.*)$/', $action, $matches);
preg_match_all('/([a-za-z0-9]*)=("|\')(.*)\\2/u', $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->includebuffered())
#return '<span class="error"><em>unknown action; the action name must not contain special characters.</em></span>'; // <<< the pattern ([a-za-z0-9])\s+ didn't match!
return '<em class="error">unknown action; the action name must not contain special characters.</em>'; // <<< the pattern ([a-za-z0-9])\s+ didn't match!
#if (!preg_match('/^[a-za-z0-9]+$/', $action)) return '<span class="error"><em>unknown action; the action name must not contain special characters.</em></span>';
if (!preg_match('/^[a-za-z0-9]+$/', $action)) return '<em class="error">unknown action; the action name must not contain special characters.</em>';
if (!$forcelinktracking) $this->stoplinktracking();
#$result = $this->includebuffered(strtolower($action).'.php', '<em>unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$result = $this->includebuffered(strtolower($action).'.php', '<em class="error">unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$this->startlinktracking();
now implemented as beta on this site. --javawoman
===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
===exclude certain camelcase words from formatting===
popular scottish surnames such as mckenna are wrongly being interpreted as wikinames - is there any way to prevent that happening?
how about something like a lookup table where wikiadmins enter a list of words that will be ignored for formatting on all pages? -- jsnx
~& sounds like a nice addition. two suggestions: 1) camelcase parsing should be made optional in the config file. 2) the list of words to be skipped could be implemented as a wiki page (something similar has been proposed for menus, acronyms and group management): this would make it a lot easier to maintain the list. my 2 cents -- dartar
===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]].
===import wikipedia database===
how can i import the wikipedia database? i don't want to use mediawiki. any idea?
~& sorry, there is no filter yet to convert mediawiki content to wikkawiki content, but it sounds like a nice feature suggestion. after all mw markup is quite stable... this said, do you //really// mean you want to import the actual wikipedia database and have it run on a different wiki engine? -- dartar
~& yes, i want. it would be great. maybe other sites will change to wikkawikki when they can import a mediawiki databse.
===note on edit, mandatory field===
i think it would be a good ide to let the administrator choose if the field is mandatory.
if it is, the form doesn't submit until there is content into it, and it should warn too with an alertbox.
only a little bit of php is necessary, the big part is in js, if i don't make any mistake...
--samueldr
===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.
if ($existinguser["password"] == md5($_post["password"]) || $existinguser["password"]==$_post["password"])
this is the current version:
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
===order of comments===
wikijochen made a comment on my page that would like to see the latest comment shown first and not last. --nilslindenberg
===own comments editing===
i think that it would be a good option to allow one to edit its own comments, sometimes, i make mistakes when commenting, typos or language things (i'm a foreigner) and i want my texts to all look clean.
currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, i'm lazy, just like many other people. --samueldr
~&samueldr, this is a good suggestion. i've had the same thought about needing the ability to edit comments. the problem with "copy and then delete" is this can only be done until someone else comments. otherwise the comments will be out of order. consider it on the todo list for a future release. -- jsnx
===google sitemap===
see [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --nilslindenberg
~&apparently google uses **urls** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our urls inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). the only case i could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell google to **not** follow the links on that page, google can find orphan pages as well. so i don't really see how this could actually help, given the "lack of structure" of a wiki. --javawoman
//copied from a comment from attachmentinfo --nilslindenberg//
does wikka support versioning of attachments?
imho a good idea. --nils
~&see allso wikkalogicaldatamodel --javawoman
===making pageindex go faster===
by default pageindex uses $this->""loadallpages""() which reads your **whole site** into one array. if you would use a new function like $this->""loadallpagesinfo""() you will get the same info but without the 'body' content. this should speed up pageindex a bit on larger sites...
1) find in ##wikka.php## (around 33%)
%%(php) function loadallpages() { return $this->loadall("select * from ".$this->config["table_prefix"]."pages where latest = 'y' order by tag"); }%%
and replace it with:
%%(php) function loadallpages() { return $this->loadall("select * from ".$this->config["table_prefix"]."pages where latest = 'y' order by tag"); }
function loadallpagesinfo() { return $this->loadall("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'y' order by tag"); }%%
1) find in ##actions/pageindex.php## (top)
%%(php)if ($pages = $this->loadallpages())%%
and replace it with:
%%(php)if ($pages = $this->loadallpagesinfo())%%
1) same trick as in (2) can be done in ##actions/mypages.php##...
-- onegwr
~&see the first item on wikkaoptimization, too --nilslindenberg
===generate id in forms; allow class===
//i know we've dicussed this multiple times but could not find an actual suggestion; i've made it into a semi-spec.//
every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and javascript, if desired). we have a ##""formopen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""formclose())""## - but this method does not generate an id nor accept a parameter to create one. it should be able to do both:
in addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). so the ##""formopen()""## method should also:
--javawoman
~&an implementation for this is now coded and tested (and will soon be added as a beta feature on this site). see advancedformopen and generateuniqueid for the code --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");
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-adress 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
===single-click restore of previous versions===
//copied from wikkabugs - this is a suggestion, not a bug --nilslindenberg//
single-click restore of previous versions (without copying/pasting). -sam
~& ''yes, this will be implemented at some point.'' - jsnx
~~&i should point out that there is an alternative to copying/pasting.
~~~& go to the revisions page.
~~~& click the date and time link that you would like to revert back to.
~~~& click the 're-edit this old revision' button.
~~~& click the 'store' button.
in any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. while our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
the only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. there are two problems with this:
~1)users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. if any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of wikka). that leaves us with finding an escape method that's easy for users to implement.
there are two requirements for an "escaped" ""%%"" then:
~1)easy to remember and apply by end users
~1)not (not likely) part of the syntax of any language
one option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. a good candidate might be **double_percent** - it's easy enough to remember and easy to implement:
the formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to geshi for rendering; the grab code handler could just as easily replace it before making the code block available for download.
thoughts anyone?
--javawoman
~&it's a good idea, but: you are sure double_percent is no reserved word in a language? or unlikely to comme up in a code? --nilslindenberg
~~&try googling for 'double_percent': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). it's certainly not a reserved word in any of the languages geshi currently has support for, going by the language files it comes with. there's no way to be 100% certain but it seems to be a pretty safe bet. --javawoman
===preview===
a doubleclick on a page in the preview should lead to "re-edit" of the text. --nilslindenberg
~& good point, agreed -- dartar
another point: the access-key for "re-edit" is alt+p at the moment. wouldn't alt+e be more logic? --nilslindenberg
===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
===color formatting===
the current color formatting isn't very wiki like. altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
this regex syntax is lifted from a ""usemod"" wiki patch.
%%s/\^([a-za-z]{1,}|#[0-9a-fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
i am by no means a regex expert, but it seems that this should do the deal... i'm just not sure where it would go. by using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--monstobrukes
~&please take a look at wikkaextensiblemarkup --nilslindenberg
~~&i looked at it. what point specifically did you intend i take from it?
~~~& javawoman had a proposal about a color-markup there. i think its the better place for the discussion. the recognition of markup is done in the formatter (formatters/wakka.php). i am no expert for regexps too, but wouldn't the first or catch too much? --nilslindenberg
===integration into existing site===
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
===documentation===
copied to documentationdiscussion. --nilslindenberg
===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:
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
===sending 403 headers===
(related to the //search engine results inflation// item below)
for pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //you aren't allowed to read this page// message - a http header like the following:
%%(php) header('http/1.0 403 forbidden');%%
-- dartar
~& oh, and maybe 404 headers for missing pages (which would help prevent se from spidering links to non existing pages)? -- dartar
===numbers as page names?===
i'm curious about the wikka convention that numbers cannot be page names. i'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature i'd definitely suggest.
btw, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
thx, robertdaeley
~& agreed, we should drop this restriction. numbers in page names might also be useful to use wikka as a [[wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[socialsoftware social software]] community. robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: jwcalendarwithpagecreation -- dartar
===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
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
~~& 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
==wikka markup inside tables==
- i think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - richardterry
~&richard, thanks for the feedback. it is on my agenda to look at another solution for tables. my plan is to allow straight html table syntax after running it through the "safehtml" checker. but i need to check that there are no security risks with this first. also, i'll take a peak at your suggestion too. -- jsnx
~&check out my proposal for an extended tableaction which does provide this. (tableaction is intended as a preliminary solution until we have table markup.) --javawoman
===robot friendly pages===
right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. it'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --barkerjr
~&ah, maybe this is why a now non-existent page that i deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --gmbowen
~&see robotfriendly. --dotmg
=== //kant-en-klaar// code blocks ===
a micro-idea before going to bed. we all know it's a bad idea to copy code blocks from the formatted version of a page.
if i want to test some freshly posted code, here's what i have to do:
~1) scan the page for the chunk of code i want to save (this can be pretty difficult on long source pages with no syntax highlighting);
wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
see grabcodehandler for a first proposal -- dartar
===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"))
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
(the following was copied from a comment on modrewrite -- javawoman)
//hi, i discovered that the default .htaccess included did not work for my setup up. i needed to include ""rewritebase"" /directory/ as well since wikka is installed in a subdirectory. i hope this helps anyone having trouble getting wikka to work.
the installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""rewritebase"" statement to take care of this. --javawoman
===separation of wakka class from wikka.php===
i use wikka as wiki engine of [[http://diantn.free.fr my page]].
imo, the wikka.php file is too big to be one single file. i suggest that we separate the wakka class into new file, say wakka.class.php
and then in the wikka.php, e.g at line where the wakka class previously located, simply we put:
include ('wakka.class.php');
-- din
~&din, this is a //very// good idea. i fact, the idea had crossed my mind already, but thanks for the reminder. :) indeed, a class belongs in a file of its own. --javawoman
~~&maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --nilslindenberg
~~~&with my current proposed structure on wikkacodestructure, it would go into the library folder; classes that are shared, into library/common. i prefer a //functional// separation rather than one based on coding format. --javawoman
===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):
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
===save pages to pdf format===
(copied from wikkadevelopment --nils)
page output to an adobe pdf file using fpdf.
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:
~&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
is there a way to include a target in a link, so that the link opens in a new window?
--gregorlindner
===signature===
//(copied from wikkafaq, but perhaps better at wantedformatters? --nilslindenberg)//
does wikka support automatic user signatures in pages (not comments)? i need some code so that users don't need to enter their username and time/date when they are working on a page in threadmode. i've searched in the docs, but i could not find anything about this, any ideas?
-- jeroenjansen (2005-01-28 11:35:43)
~& jeroen, there is a hack for automatically adding a user's signature in wakkawiki posted by nickk on his [[http://wakkawiki.de/nickk homepage]]. it should be easy to adapt to wikka. -- dartar
~~& dartar, just saw your reply. thanks for the hint! --jeroenjansen
=== 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
=== create rewrite rules on install ===
~//copied from comment on wikkainstallation --javawoman//
since i installed wikka in a subdirectory under the domain root i needed to add the following to the .htaccess file just under """rewriteengine on""":
""rewritebase"" /subdirectory/
devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-- karmatester (2005-01-26 06:52:07)
=== image dimensions ===
the [[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
~~~¬ed. 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
===clearing acls===
there should be a button on the acl page to "reset acls to default". what this would do is delete the record for the current page from the acls table. there is a distinction between setting the acls to the sites default values and not having acls defined for a page. if the acls are set and the default values get changed, the page will remain at the set values. however, if no acls are defined, the page will always use the default values.
to help show the distinction, there should be a visual indicator on the acl handler page which states whether the page has acls defined or is using the site's default values. basically, just check for a record in the acls table for the current page, and display a message accordingly. -- jsnx
== user registration control ==
it would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (or at least the configurable option to check for only one email/one account.)
it should also then be easier (i would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful aclswithusergroups hack that christian created to make a list of banned users by username. yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --movielady
~&you know how many testusers my wikka already has? *g* this should do the job (this time no config option, sorry jw :)
function existsemail($email)
$query = "select count(email)
from ".$this->config['table_prefix']."users
where email='".mysql_real_escape_string($email)."'";
if ($r = $this->query($query))
return ($count > 0) ? true : false;
~&place this function in wikka.php right after function userwantscomments(). and change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "password too short.";
else if (strlen($password) < 5) $error = "password too short.";
else if ($this->existsemail($email)) $error = "you already have a username.";
~&--nilslindenberg
~~& lol i can imagine. thanks so much for this - i'll try it out this evening. --movielady
~& speaking of registration control, note to self: make a configuration option to turn off new account registrations. some sites might be private and not want people registering. admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- jsnx
~~& (you saw userregistration by nils? i think it, or something like it, should be standard. mike)
~~~& doh! i somehow missed that. that's pretty much what i had in mind. nice job, nils! :) -- jsnx
~~~~&thank you. about your admin-adding-user case: that's an addition to useradmin, not for usersettings. --nilslindenberg
~~~&there's also code around that uses gd & that could be built onto nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. ultimately, as the bots become more sophisticated i think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what i mean (i like the simplicity of the first version in the second example). -- gmbowen
~~~~&yes, "captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). add a sound equivalent? well, there are people who are deaf **and** blind. are we going to deny them access to our wikis? i'm not in favor of making wikka **in**accessible when we should be working towards making it **more** accessible. --javawoman.
=== rss options ===
it would be wonderful to be able to choose what kind of rss feed is created for a page. for example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --movielady
=== 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
~¬ed - good suggestion. --javawoman
if ($pages = $this->loadpageslinkingto($this->getpagetag())) {
$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
=== language file ===
i would be nice to see all phrases put into a single file. this would allow to translate the wiki in a few hours without changes every single file.
~&look at dotmgs approach at wikkainternationalization. but at least it should work for languages in the range of the "normal" (ascii?) code. if you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --nilslindenberg
~~&the most flexible and powerful way to support i18n is still gettext which is supported by php. if we go in that direction (likely), manually creating a "language file" is needless work since gettext does all that automatically for you. and it supports options for handling plurals and such which simple string-to-string language files cannot handle. the problem is that code needs to be written in a way to properly be able to use gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any html markup (actually this is true for simple laguage files as well). currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --javawoman
=== 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!";
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
===finally using cvs?===
i apologize since this idea has been suggested before, and i believe the developers are working to implement it already. however, with the beta of 1.1.6.0 released, i think it would be a good time now to start using cvs. this allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. in addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
also, i am willing to help with the cvs migration process if needed and help anyone who is interested in learning how to use cvs.
-- mikexstudios
~&there is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. just has to be updated --nilslindenberg
~~&actually, nils, we need a lot more than "just updating" the cvs at sourceforge. we need to integrate cvs in our development process - and develop a process for doing so. that requires a bit of planning... :) and while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with cvs specifically, so a bit of study will be required before we can start planning. help with learning how to use cvs //well// from someone who has experience with it would certainly be welcome, mike! thanks for the offer. --javawoman ''(reading manuals....)''
~~~& the "just was meant as an addition to existing ("of course" would have been better, though :). i just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case mike does not no. it is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --nilslindenberg
~~~~& hi nils. actually, i did find wikka's cvs repository at sf weeks ago, but i forgot to mention it in my above post. javawoman pretty much echoed my thoughts. we need to actively use cvs/update it constantly as changes are made. i run a project called [[http://xcomic.sourceforge.net xcomic]] that uses sourceforge's cvs a lot, so i have some experience with that. in addition, i recently set something up for my project that i think will be pretty cool if wikka decides to really use cvs: a commit mailing list. anytime someone makes a change to the cvs (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). in any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --mikexstudios
~~~~~&mike, i for one would welcome your insights in using cvs. both dartar and i have some ideas about how we want it set up - but no experience in doing so (in cvs). may i suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? for this type of thing i think that would be the best medium to discuss thoughs and methods. i like the idea of a commit mailing list. --javawoman
===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
===local links===
it would be nice if a link to the same host as the wikka install was not flagged as 'external'. i've added a 'hack' to my personal page: kickthedonkey. works fine here.
--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...
- 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''
===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
===online editing of mindmaps would be great===
(copied from sourceforge.net --nilslindenberg)
it would be great, if users should work together on mindmaps.
maybe by downloading/ open with freemind and then having a possiblity to save changes in freemind directly back to the online mindmap.
===how to format code to get two % characters without space together?===
i want to produce a code sample page in wikka with dos batch code. the code syntax requires two percent characters together to markup a variable. example: % %variable% % (without the spaces). wikka always tries to format the text as code, even if i format the dos code inside a code block, even if i %% marked it as code with two percent characters like this here%%
is there a solution? i could not find a literal entity for "percent"
''you could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. see: %%some text with %% embedded in it%%
but it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (and how do you markup wiki markup as **code**?) -- javawoman''
how about the € (euro) symbol? or is it to new? --nilslindenberg
''the main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. and it might occur in code as well (imagine a sample conversion routine). wiki markup should be easy to type. so we need a symbol (or sumbol combination, maybe), that's:
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of apl!)
the **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). maybe we should do a search (google?) to check whether **!!** or a combo is actually an operator in any language.
-- javawoman''
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:
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?:
$timestamp = $wakka->getpagetime(); //hopefully this function returns the right format?
return (++$trigger_deleted % 2 ? "<del datetime=\"$timestamp\">" : "</del>");
--nilslindenberg
working on a test installation, i found the user setting "show comments by default" did not work. testing it here, i found it doesn't work here, either.
haven't dug in the code yet to find where this should happen (but will).
i'm quite happy with wikka's capabilities out of the box - good starting point! :) i'll likely stay with it - but i'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
great work! javawoman
it does work.... just not as might be expected. comment preference is stored for each page as you browse the wiki. so, if you browse a few pages with comments not showing, it remembers this. then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
try this:
- browse to usersettings and check off "show comments by default" and click "update settings".
- now **close all browser windows**
- open back up your browser and go to the same pages......
- comments are now showing by default, right?
- jsnx
right. i see it does work. ;) somewhat, um, counterintuitive, though. so i guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). that would, i think, be more in line with expected behavior. possible? (i haven't looked at that area of the code yet.) --javawoman.
===language support===
i was searching almost whole site to check what kind of languages are supported by this wiki. i was unsuccessful. is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
thanks mdd
=== 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
== question: note? ==
it is me again! what is the function of the "please add a note on your edit" - field? again and again: keep on the good work.
-- skywalk
~& this note is shown in some lists like the recentchanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --dreckfehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --georgepetsagourakis
=== 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
the edit page handler seems to convert spaces to tabs throughout the entire document, including code blocks.
**from edit.php**
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
===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
===mod_rewrite===
take a look at favicondotico and robotsdottxt
categorydevelopmentsuggestions
Additions:
[[http://zona.pl/best/hotel_malysia hotel_malysia]] hotel malysia [[http://zona.pl/best/irs_levy irs_levy]] irs levy [[http://zona.pl/best/irs_problem irs_problem]] irs problem [[http://zona.pl/best/keno keno]] keno [[http://zona.pl/best/mlm_lead mlm_lead]] mlm lead [[http://zona.pl/best/wagering wagering]] wagering
=====suggestion box=====
feedback is welcomed and appreciated. use the form or edit this page.
**please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== bugs vs. feature suggestions ===
please post issues/bugs to the appropriate page:
~-general bugs/issues: wikkabugs
~-css layout issues: wikkacss
~-suggestionsarchive for resolved suggestions
**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]]
~-usermap
=== automatic conversoin from html to wakkiwiki syntax ===
does such think 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
===improved code for error messages in action() method===
the ##action()## method in ##wikka.php## produces errors in some cases; the error class was implemented as a span rather than directly on the <em> element surrounding the message. the span elements are superfluous and bad coding style.
change:
%%(php;759) function action($action, $forcelinktracking = 0)
preg_match("/^([a-za-z0-9]*)\s+(.*)$/", $action, $matches);
preg_match_all("/([a-za-z0-9]*)=\"(.*)\"/u", $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->includebuffered())
return "<span class='error'><em>unknown action; the action name must not contain special characters.</em></span>"; // <<< the pattern ([a-za-z0-9])\s+ didn't match!
if (!preg_match("/^[a-za-z0-9]+$/", $action)) return "<span class='error'><em>unknown action; the action name must not contain special characters.</em></span>";
if (!$forcelinktracking) $this->stoplinktracking();
$result = $this->includebuffered(strtolower($action).".php", "<em>unknown action \"$action\"</em>", $vars, $this->config["action_path"]);
$this->startlinktracking();
%%(php) // jw action() modified to allow attributes in single quotes
// jw 2005-07-08 error class moved to em
function action($action, $forcelinktracking = 0)
preg_match('/^([a-za-z0-9]*)\s+(.*)$/', $action, $matches);
preg_match_all('/([a-za-z0-9]*)=("|\')(.*)\\2/u', $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->includebuffered())
#return '<span class="error"><em>unknown action; the action name must not contain special characters.</em></span>'; // <<< the pattern ([a-za-z0-9])\s+ didn't match!
return '<em class="error">unknown action; the action name must not contain special characters.</em>'; // <<< the pattern ([a-za-z0-9])\s+ didn't match!
#if (!preg_match('/^[a-za-z0-9]+$/', $action)) return '<span class="error"><em>unknown action; the action name must not contain special characters.</em></span>';
if (!preg_match('/^[a-za-z0-9]+$/', $action)) return '<em class="error">unknown action; the action name must not contain special characters.</em>';
if (!$forcelinktracking) $this->stoplinktracking();
#$result = $this->includebuffered(strtolower($action).'.php', '<em>unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$result = $this->includebuffered(strtolower($action).'.php', '<em class="error">unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$this->startlinktracking();
now implemented as beta on this site. --javawoman
===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
===exclude certain camelcase words from formatting===
popular scottish surnames such as mckenna are wrongly being interpreted as wikinames - is there any way to prevent that happening?
how about something like a lookup table where wikiadmins enter a list of words that will be ignored for formatting on all pages? -- jsnx
~& sounds like a nice addition. two suggestions: 1) camelcase parsing should be made optional in the config file. 2) the list of words to be skipped could be implemented as a wiki page (something similar has been proposed for menus, acronyms and group management): this would make it a lot easier to maintain the list. my 2 cents -- dartar
===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]].
===import wikipedia database===
how can i import the wikipedia database? i don't want to use mediawiki. any idea?
~& sorry, there is no filter yet to convert mediawiki content to wikkawiki content, but it sounds like a nice feature suggestion. after all mw markup is quite stable... this said, do you //really// mean you want to import the actual wikipedia database and have it run on a different wiki engine? -- dartar
~& yes, i want. it would be great. maybe other sites will change to wikkawikki when they can import a mediawiki databse.
===note on edit, mandatory field===
i think it would be a good ide to let the administrator choose if the field is mandatory.
if it is, the form doesn't submit until there is content into it, and it should warn too with an alertbox.
only a little bit of php is necessary, the big part is in js, if i don't make any mistake...
--samueldr
===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.
if ($existinguser["password"] == md5($_post["password"]) || $existinguser["password"]==$_post["password"])
this is the current version:
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
===order of comments===
wikijochen made a comment on my page that would like to see the latest comment shown first and not last. --nilslindenberg
===own comments editing===
i think that it would be a good option to allow one to edit its own comments, sometimes, i make mistakes when commenting, typos or language things (i'm a foreigner) and i want my texts to all look clean.
currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, i'm lazy, just like many other people. --samueldr
~&samueldr, this is a good suggestion. i've had the same thought about needing the ability to edit comments. the problem with "copy and then delete" is this can only be done until someone else comments. otherwise the comments will be out of order. consider it on the todo list for a future release. -- jsnx
===google sitemap===
see [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --nilslindenberg
~&apparently google uses **urls** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our urls inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). the only case i could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell google to **not** follow the links on that page, google can find orphan pages as well. so i don't really see how this could actually help, given the "lack of structure" of a wiki. --javawoman
//copied from a comment from attachmentinfo --nilslindenberg//
does wikka support versioning of attachments?
imho a good idea. --nils
~&see allso wikkalogicaldatamodel --javawoman
===making pageindex go faster===
by default pageindex uses $this->""loadallpages""() which reads your **whole site** into one array. if you would use a new function like $this->""loadallpagesinfo""() you will get the same info but without the 'body' content. this should speed up pageindex a bit on larger sites...
1) find in ##wikka.php## (around 33%)
%%(php) function loadallpages() { return $this->loadall("select * from ".$this->config["table_prefix"]."pages where latest = 'y' order by tag"); }%%
and replace it with:
%%(php) function loadallpages() { return $this->loadall("select * from ".$this->config["table_prefix"]."pages where latest = 'y' order by tag"); }
function loadallpagesinfo() { return $this->loadall("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'y' order by tag"); }%%
1) find in ##actions/pageindex.php## (top)
%%(php)if ($pages = $this->loadallpages())%%
and replace it with:
%%(php)if ($pages = $this->loadallpagesinfo())%%
1) same trick as in (2) can be done in ##actions/mypages.php##...
-- onegwr
~&see the first item on wikkaoptimization, too --nilslindenberg
===generate id in forms; allow class===
//i know we've dicussed this multiple times but could not find an actual suggestion; i've made it into a semi-spec.//
every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and javascript, if desired). we have a ##""formopen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""formclose())""## - but this method does not generate an id nor accept a parameter to create one. it should be able to do both:
in addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). so the ##""formopen()""## method should also:
--javawoman
~&an implementation for this is now coded and tested (and will soon be added as a beta feature on this site). see advancedformopen and generateuniqueid for the code --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");
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-adress 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
===single-click restore of previous versions===
//copied from wikkabugs - this is a suggestion, not a bug --nilslindenberg//
single-click restore of previous versions (without copying/pasting). -sam
~& ''yes, this will be implemented at some point.'' - jsnx
~~&i should point out that there is an alternative to copying/pasting.
~~~& go to the revisions page.
~~~& click the date and time link that you would like to revert back to.
~~~& click the 're-edit this old revision' button.
~~~& click the 'store' button.
in any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. while our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
the only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. there are two problems with this:
~1)users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. if any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of wikka). that leaves us with finding an escape method that's easy for users to implement.
there are two requirements for an "escaped" ""%%"" then:
~1)easy to remember and apply by end users
~1)not (not likely) part of the syntax of any language
one option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. a good candidate might be **double_percent** - it's easy enough to remember and easy to implement:
the formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to geshi for rendering; the grab code handler could just as easily replace it before making the code block available for download.
thoughts anyone?
--javawoman
~&it's a good idea, but: you are sure double_percent is no reserved word in a language? or unlikely to comme up in a code? --nilslindenberg
~~&try googling for 'double_percent': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). it's certainly not a reserved word in any of the languages geshi currently has support for, going by the language files it comes with. there's no way to be 100% certain but it seems to be a pretty safe bet. --javawoman
===preview===
a doubleclick on a page in the preview should lead to "re-edit" of the text. --nilslindenberg
~& good point, agreed -- dartar
another point: the access-key for "re-edit" is alt+p at the moment. wouldn't alt+e be more logic? --nilslindenberg
===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
===color formatting===
the current color formatting isn't very wiki like. altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
this regex syntax is lifted from a ""usemod"" wiki patch.
%%s/\^([a-za-z]{1,}|#[0-9a-fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
i am by no means a regex expert, but it seems that this should do the deal... i'm just not sure where it would go. by using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--monstobrukes
~&please take a look at wikkaextensiblemarkup --nilslindenberg
~~&i looked at it. what point specifically did you intend i take from it?
~~~& javawoman had a proposal about a color-markup there. i think its the better place for the discussion. the recognition of markup is done in the formatter (formatters/wakka.php). i am no expert for regexps too, but wouldn't the first or catch too much? --nilslindenberg
===integration into existing site===
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
===documentation===
copied to documentationdiscussion. --nilslindenberg
===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:
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
===sending 403 headers===
(related to the //search engine results inflation// item below)
for pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //you aren't allowed to read this page// message - a http header like the following:
%%(php) header('http/1.0 403 forbidden');%%
-- dartar
~& oh, and maybe 404 headers for missing pages (which would help prevent se from spidering links to non existing pages)? -- dartar
===numbers as page names?===
i'm curious about the wikka convention that numbers cannot be page names. i'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature i'd definitely suggest.
btw, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
thx, robertdaeley
~& agreed, we should drop this restriction. numbers in page names might also be useful to use wikka as a [[wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[socialsoftware social software]] community. robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: jwcalendarwithpagecreation -- dartar
===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
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
~~& 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
==wikka markup inside tables==
- i think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - richardterry
~&richard, thanks for the feedback. it is on my agenda to look at another solution for tables. my plan is to allow straight html table syntax after running it through the "safehtml" checker. but i need to check that there are no security risks with this first. also, i'll take a peak at your suggestion too. -- jsnx
~&check out my proposal for an extended tableaction which does provide this. (tableaction is intended as a preliminary solution until we have table markup.) --javawoman
===robot friendly pages===
right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. it'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --barkerjr
~&ah, maybe this is why a now non-existent page that i deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --gmbowen
~&see robotfriendly. --dotmg
=== //kant-en-klaar// code blocks ===
a micro-idea before going to bed. we all know it's a bad idea to copy code blocks from the formatted version of a page.
if i want to test some freshly posted code, here's what i have to do:
~1) scan the page for the chunk of code i want to save (this can be pretty difficult on long source pages with no syntax highlighting);
wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
see grabcodehandler for a first proposal -- dartar
===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"))
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
(the following was copied from a comment on modrewrite -- javawoman)
//hi, i discovered that the default .htaccess included did not work for my setup up. i needed to include ""rewritebase"" /directory/ as well since wikka is installed in a subdirectory. i hope this helps anyone having trouble getting wikka to work.
the installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""rewritebase"" statement to take care of this. --javawoman
===separation of wakka class from wikka.php===
i use wikka as wiki engine of [[http://diantn.free.fr my page]].
imo, the wikka.php file is too big to be one single file. i suggest that we separate the wakka class into new file, say wakka.class.php
and then in the wikka.php, e.g at line where the wakka class previously located, simply we put:
include ('wakka.class.php');
-- din
~&din, this is a //very// good idea. i fact, the idea had crossed my mind already, but thanks for the reminder. :) indeed, a class belongs in a file of its own. --javawoman
~~&maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --nilslindenberg
~~~&with my current proposed structure on wikkacodestructure, it would go into the library folder; classes that are shared, into library/common. i prefer a //functional// separation rather than one based on coding format. --javawoman
===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):
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
===save pages to pdf format===
(copied from wikkadevelopment --nils)
page output to an adobe pdf file using fpdf.
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:
~&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
is there a way to include a target in a link, so that the link opens in a new window?
--gregorlindner
===signature===
//(copied from wikkafaq, but perhaps better at wantedformatters? --nilslindenberg)//
does wikka support automatic user signatures in pages (not comments)? i need some code so that users don't need to enter their username and time/date when they are working on a page in threadmode. i've searched in the docs, but i could not find anything about this, any ideas?
-- jeroenjansen (2005-01-28 11:35:43)
~& jeroen, there is a hack for automatically adding a user's signature in wakkawiki posted by nickk on his [[http://wakkawiki.de/nickk homepage]]. it should be easy to adapt to wikka. -- dartar
~~& dartar, just saw your reply. thanks for the hint! --jeroenjansen
=== 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
=== create rewrite rules on install ===
~//copied from comment on wikkainstallation --javawoman//
since i installed wikka in a subdirectory under the domain root i needed to add the following to the .htaccess file just under """rewriteengine on""":
""rewritebase"" /subdirectory/
devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-- karmatester (2005-01-26 06:52:07)
=== image dimensions ===
the [[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
~~~¬ed. 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
===clearing acls===
there should be a button on the acl page to "reset acls to default". what this would do is delete the record for the current page from the acls table. there is a distinction between setting the acls to the sites default values and not having acls defined for a page. if the acls are set and the default values get changed, the page will remain at the set values. however, if no acls are defined, the page will always use the default values.
to help show the distinction, there should be a visual indicator on the acl handler page which states whether the page has acls defined or is using the site's default values. basically, just check for a record in the acls table for the current page, and display a message accordingly. -- jsnx
== user registration control ==
it would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (or at least the configurable option to check for only one email/one account.)
it should also then be easier (i would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful aclswithusergroups hack that christian created to make a list of banned users by username. yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --movielady
~&you know how many testusers my wikka already has? *g* this should do the job (this time no config option, sorry jw :)
function existsemail($email)
$query = "select count(email)
from ".$this->config['table_prefix']."users
where email='".mysql_real_escape_string($email)."'";
if ($r = $this->query($query))
return ($count > 0) ? true : false;
~&place this function in wikka.php right after function userwantscomments(). and change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "password too short.";
else if (strlen($password) < 5) $error = "password too short.";
else if ($this->existsemail($email)) $error = "you already have a username.";
~&--nilslindenberg
~~& lol i can imagine. thanks so much for this - i'll try it out this evening. --movielady
~& speaking of registration control, note to self: make a configuration option to turn off new account registrations. some sites might be private and not want people registering. admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- jsnx
~~& (you saw userregistration by nils? i think it, or something like it, should be standard. mike)
~~~& doh! i somehow missed that. that's pretty much what i had in mind. nice job, nils! :) -- jsnx
~~~~&thank you. about your admin-adding-user case: that's an addition to useradmin, not for usersettings. --nilslindenberg
~~~&there's also code around that uses gd & that could be built onto nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. ultimately, as the bots become more sophisticated i think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what i mean (i like the simplicity of the first version in the second example). -- gmbowen
~~~~&yes, "captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). add a sound equivalent? well, there are people who are deaf **and** blind. are we going to deny them access to our wikis? i'm not in favor of making wikka **in**accessible when we should be working towards making it **more** accessible. --javawoman.
=== rss options ===
it would be wonderful to be able to choose what kind of rss feed is created for a page. for example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --movielady
=== 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
~¬ed - good suggestion. --javawoman
if ($pages = $this->loadpageslinkingto($this->getpagetag())) {
$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
=== language file ===
i would be nice to see all phrases put into a single file. this would allow to translate the wiki in a few hours without changes every single file.
~&look at dotmgs approach at wikkainternationalization. but at least it should work for languages in the range of the "normal" (ascii?) code. if you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --nilslindenberg
~~&the most flexible and powerful way to support i18n is still gettext which is supported by php. if we go in that direction (likely), manually creating a "language file" is needless work since gettext does all that automatically for you. and it supports options for handling plurals and such which simple string-to-string language files cannot handle. the problem is that code needs to be written in a way to properly be able to use gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any html markup (actually this is true for simple laguage files as well). currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --javawoman
=== 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!";
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
===finally using cvs?===
i apologize since this idea has been suggested before, and i believe the developers are working to implement it already. however, with the beta of 1.1.6.0 released, i think it would be a good time now to start using cvs. this allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. in addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
also, i am willing to help with the cvs migration process if needed and help anyone who is interested in learning how to use cvs.
-- mikexstudios
~&there is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. just has to be updated --nilslindenberg
~~&actually, nils, we need a lot more than "just updating" the cvs at sourceforge. we need to integrate cvs in our development process - and develop a process for doing so. that requires a bit of planning... :) and while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with cvs specifically, so a bit of study will be required before we can start planning. help with learning how to use cvs //well// from someone who has experience with it would certainly be welcome, mike! thanks for the offer. --javawoman ''(reading manuals....)''
~~~& the "just was meant as an addition to existing ("of course" would have been better, though :). i just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case mike does not no. it is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --nilslindenberg
~~~~& hi nils. actually, i did find wikka's cvs repository at sf weeks ago, but i forgot to mention it in my above post. javawoman pretty much echoed my thoughts. we need to actively use cvs/update it constantly as changes are made. i run a project called [[http://xcomic.sourceforge.net xcomic]] that uses sourceforge's cvs a lot, so i have some experience with that. in addition, i recently set something up for my project that i think will be pretty cool if wikka decides to really use cvs: a commit mailing list. anytime someone makes a change to the cvs (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). in any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --mikexstudios
~~~~~&mike, i for one would welcome your insights in using cvs. both dartar and i have some ideas about how we want it set up - but no experience in doing so (in cvs). may i suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? for this type of thing i think that would be the best medium to discuss thoughs and methods. i like the idea of a commit mailing list. --javawoman
===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
===local links===
it would be nice if a link to the same host as the wikka install was not flagged as 'external'. i've added a 'hack' to my personal page: kickthedonkey. works fine here.
--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...
- 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''
===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
===online editing of mindmaps would be great===
(copied from sourceforge.net --nilslindenberg)
it would be great, if users should work together on mindmaps.
maybe by downloading/ open with freemind and then having a possiblity to save changes in freemind directly back to the online mindmap.
===how to format code to get two % characters without space together?===
i want to produce a code sample page in wikka with dos batch code. the code syntax requires two percent characters together to markup a variable. example: % %variable% % (without the spaces). wikka always tries to format the text as code, even if i format the dos code inside a code block, even if i %% marked it as code with two percent characters like this here%%
is there a solution? i could not find a literal entity for "percent"
''you could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. see: %%some text with %% embedded in it%%
but it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (and how do you markup wiki markup as **code**?) -- javawoman''
how about the € (euro) symbol? or is it to new? --nilslindenberg
''the main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. and it might occur in code as well (imagine a sample conversion routine). wiki markup should be easy to type. so we need a symbol (or sumbol combination, maybe), that's:
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of apl!)
the **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). maybe we should do a search (google?) to check whether **!!** or a combo is actually an operator in any language.
-- javawoman''
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:
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?:
$timestamp = $wakka->getpagetime(); //hopefully this function returns the right format?
return (++$trigger_deleted % 2 ? "<del datetime=\"$timestamp\">" : "</del>");
--nilslindenberg
working on a test installation, i found the user setting "show comments by default" did not work. testing it here, i found it doesn't work here, either.
haven't dug in the code yet to find where this should happen (but will).
i'm quite happy with wikka's capabilities out of the box - good starting point! :) i'll likely stay with it - but i'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
great work! javawoman
it does work.... just not as might be expected. comment preference is stored for each page as you browse the wiki. so, if you browse a few pages with comments not showing, it remembers this. then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
try this:
- browse to usersettings and check off "show comments by default" and click "update settings".
- now **close all browser windows**
- open back up your browser and go to the same pages......
- comments are now showing by default, right?
- jsnx
right. i see it does work. ;) somewhat, um, counterintuitive, though. so i guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). that would, i think, be more in line with expected behavior. possible? (i haven't looked at that area of the code yet.) --javawoman.
===language support===
i was searching almost whole site to check what kind of languages are supported by this wiki. i was unsuccessful. is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
thanks mdd
=== 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
== question: note? ==
it is me again! what is the function of the "please add a note on your edit" - field? again and again: keep on the good work.
-- skywalk
~& this note is shown in some lists like the recentchanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --dreckfehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --georgepetsagourakis
=== 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
the edit page handler seems to convert spaces to tabs throughout the entire document, including code blocks.
**from edit.php**
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
===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
===mod_rewrite===
take a look at favicondotico and robotsdottxt
categorydevelopmentsuggestions
=====suggestion box=====
feedback is welcomed and appreciated. use the form or edit this page.
**please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== bugs vs. feature suggestions ===
please post issues/bugs to the appropriate page:
~-general bugs/issues: wikkabugs
~-css layout issues: wikkacss
~-suggestionsarchive for resolved suggestions
**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]]
~-usermap
=== automatic conversoin from html to wakkiwiki syntax ===
does such think 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
===improved code for error messages in action() method===
the ##action()## method in ##wikka.php## produces errors in some cases; the error class was implemented as a span rather than directly on the <em> element surrounding the message. the span elements are superfluous and bad coding style.
change:
%%(php;759) function action($action, $forcelinktracking = 0)
preg_match("/^([a-za-z0-9]*)\s+(.*)$/", $action, $matches);
preg_match_all("/([a-za-z0-9]*)=\"(.*)\"/u", $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->includebuffered())
return "<span class='error'><em>unknown action; the action name must not contain special characters.</em></span>"; // <<< the pattern ([a-za-z0-9])\s+ didn't match!
if (!preg_match("/^[a-za-z0-9]+$/", $action)) return "<span class='error'><em>unknown action; the action name must not contain special characters.</em></span>";
if (!$forcelinktracking) $this->stoplinktracking();
$result = $this->includebuffered(strtolower($action).".php", "<em>unknown action \"$action\"</em>", $vars, $this->config["action_path"]);
$this->startlinktracking();
%%(php) // jw action() modified to allow attributes in single quotes
// jw 2005-07-08 error class moved to em
function action($action, $forcelinktracking = 0)
preg_match('/^([a-za-z0-9]*)\s+(.*)$/', $action, $matches);
preg_match_all('/([a-za-z0-9]*)=("|\')(.*)\\2/u', $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->includebuffered())
#return '<span class="error"><em>unknown action; the action name must not contain special characters.</em></span>'; // <<< the pattern ([a-za-z0-9])\s+ didn't match!
return '<em class="error">unknown action; the action name must not contain special characters.</em>'; // <<< the pattern ([a-za-z0-9])\s+ didn't match!
#if (!preg_match('/^[a-za-z0-9]+$/', $action)) return '<span class="error"><em>unknown action; the action name must not contain special characters.</em></span>';
if (!preg_match('/^[a-za-z0-9]+$/', $action)) return '<em class="error">unknown action; the action name must not contain special characters.</em>';
if (!$forcelinktracking) $this->stoplinktracking();
#$result = $this->includebuffered(strtolower($action).'.php', '<em>unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$result = $this->includebuffered(strtolower($action).'.php', '<em class="error">unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$this->startlinktracking();
now implemented as beta on this site. --javawoman
===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
===exclude certain camelcase words from formatting===
popular scottish surnames such as mckenna are wrongly being interpreted as wikinames - is there any way to prevent that happening?
how about something like a lookup table where wikiadmins enter a list of words that will be ignored for formatting on all pages? -- jsnx
~& sounds like a nice addition. two suggestions: 1) camelcase parsing should be made optional in the config file. 2) the list of words to be skipped could be implemented as a wiki page (something similar has been proposed for menus, acronyms and group management): this would make it a lot easier to maintain the list. my 2 cents -- dartar
===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]].
===import wikipedia database===
how can i import the wikipedia database? i don't want to use mediawiki. any idea?
~& sorry, there is no filter yet to convert mediawiki content to wikkawiki content, but it sounds like a nice feature suggestion. after all mw markup is quite stable... this said, do you //really// mean you want to import the actual wikipedia database and have it run on a different wiki engine? -- dartar
~& yes, i want. it would be great. maybe other sites will change to wikkawikki when they can import a mediawiki databse.
===note on edit, mandatory field===
i think it would be a good ide to let the administrator choose if the field is mandatory.
if it is, the form doesn't submit until there is content into it, and it should warn too with an alertbox.
only a little bit of php is necessary, the big part is in js, if i don't make any mistake...
--samueldr
===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.
if ($existinguser["password"] == md5($_post["password"]) || $existinguser["password"]==$_post["password"])
this is the current version:
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
===order of comments===
wikijochen made a comment on my page that would like to see the latest comment shown first and not last. --nilslindenberg
===own comments editing===
i think that it would be a good option to allow one to edit its own comments, sometimes, i make mistakes when commenting, typos or language things (i'm a foreigner) and i want my texts to all look clean.
currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, i'm lazy, just like many other people. --samueldr
~&samueldr, this is a good suggestion. i've had the same thought about needing the ability to edit comments. the problem with "copy and then delete" is this can only be done until someone else comments. otherwise the comments will be out of order. consider it on the todo list for a future release. -- jsnx
===google sitemap===
see [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --nilslindenberg
~&apparently google uses **urls** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our urls inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). the only case i could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell google to **not** follow the links on that page, google can find orphan pages as well. so i don't really see how this could actually help, given the "lack of structure" of a wiki. --javawoman
//copied from a comment from attachmentinfo --nilslindenberg//
does wikka support versioning of attachments?
imho a good idea. --nils
~&see allso wikkalogicaldatamodel --javawoman
===making pageindex go faster===
by default pageindex uses $this->""loadallpages""() which reads your **whole site** into one array. if you would use a new function like $this->""loadallpagesinfo""() you will get the same info but without the 'body' content. this should speed up pageindex a bit on larger sites...
1) find in ##wikka.php## (around 33%)
%%(php) function loadallpages() { return $this->loadall("select * from ".$this->config["table_prefix"]."pages where latest = 'y' order by tag"); }%%
and replace it with:
%%(php) function loadallpages() { return $this->loadall("select * from ".$this->config["table_prefix"]."pages where latest = 'y' order by tag"); }
function loadallpagesinfo() { return $this->loadall("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'y' order by tag"); }%%
1) find in ##actions/pageindex.php## (top)
%%(php)if ($pages = $this->loadallpages())%%
and replace it with:
%%(php)if ($pages = $this->loadallpagesinfo())%%
1) same trick as in (2) can be done in ##actions/mypages.php##...
-- onegwr
~&see the first item on wikkaoptimization, too --nilslindenberg
===generate id in forms; allow class===
//i know we've dicussed this multiple times but could not find an actual suggestion; i've made it into a semi-spec.//
every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and javascript, if desired). we have a ##""formopen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""formclose())""## - but this method does not generate an id nor accept a parameter to create one. it should be able to do both:
in addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). so the ##""formopen()""## method should also:
--javawoman
~&an implementation for this is now coded and tested (and will soon be added as a beta feature on this site). see advancedformopen and generateuniqueid for the code --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");
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-adress 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
===single-click restore of previous versions===
//copied from wikkabugs - this is a suggestion, not a bug --nilslindenberg//
single-click restore of previous versions (without copying/pasting). -sam
~& ''yes, this will be implemented at some point.'' - jsnx
~~&i should point out that there is an alternative to copying/pasting.
~~~& go to the revisions page.
~~~& click the date and time link that you would like to revert back to.
~~~& click the 're-edit this old revision' button.
~~~& click the 'store' button.
in any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. while our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
the only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. there are two problems with this:
~1)users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. if any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of wikka). that leaves us with finding an escape method that's easy for users to implement.
there are two requirements for an "escaped" ""%%"" then:
~1)easy to remember and apply by end users
~1)not (not likely) part of the syntax of any language
one option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. a good candidate might be **double_percent** - it's easy enough to remember and easy to implement:
the formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to geshi for rendering; the grab code handler could just as easily replace it before making the code block available for download.
thoughts anyone?
--javawoman
~&it's a good idea, but: you are sure double_percent is no reserved word in a language? or unlikely to comme up in a code? --nilslindenberg
~~&try googling for 'double_percent': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). it's certainly not a reserved word in any of the languages geshi currently has support for, going by the language files it comes with. there's no way to be 100% certain but it seems to be a pretty safe bet. --javawoman
===preview===
a doubleclick on a page in the preview should lead to "re-edit" of the text. --nilslindenberg
~& good point, agreed -- dartar
another point: the access-key for "re-edit" is alt+p at the moment. wouldn't alt+e be more logic? --nilslindenberg
===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
===color formatting===
the current color formatting isn't very wiki like. altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
this regex syntax is lifted from a ""usemod"" wiki patch.
%%s/\^([a-za-z]{1,}|#[0-9a-fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
i am by no means a regex expert, but it seems that this should do the deal... i'm just not sure where it would go. by using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--monstobrukes
~&please take a look at wikkaextensiblemarkup --nilslindenberg
~~&i looked at it. what point specifically did you intend i take from it?
~~~& javawoman had a proposal about a color-markup there. i think its the better place for the discussion. the recognition of markup is done in the formatter (formatters/wakka.php). i am no expert for regexps too, but wouldn't the first or catch too much? --nilslindenberg
===integration into existing site===
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
===documentation===
copied to documentationdiscussion. --nilslindenberg
===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:
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
===sending 403 headers===
(related to the //search engine results inflation// item below)
for pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //you aren't allowed to read this page// message - a http header like the following:
%%(php) header('http/1.0 403 forbidden');%%
-- dartar
~& oh, and maybe 404 headers for missing pages (which would help prevent se from spidering links to non existing pages)? -- dartar
===numbers as page names?===
i'm curious about the wikka convention that numbers cannot be page names. i'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature i'd definitely suggest.
btw, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
thx, robertdaeley
~& agreed, we should drop this restriction. numbers in page names might also be useful to use wikka as a [[wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[socialsoftware social software]] community. robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: jwcalendarwithpagecreation -- dartar
===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
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
~~& 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
==wikka markup inside tables==
- i think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - richardterry
~&richard, thanks for the feedback. it is on my agenda to look at another solution for tables. my plan is to allow straight html table syntax after running it through the "safehtml" checker. but i need to check that there are no security risks with this first. also, i'll take a peak at your suggestion too. -- jsnx
~&check out my proposal for an extended tableaction which does provide this. (tableaction is intended as a preliminary solution until we have table markup.) --javawoman
===robot friendly pages===
right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. it'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --barkerjr
~&ah, maybe this is why a now non-existent page that i deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --gmbowen
~&see robotfriendly. --dotmg
=== //kant-en-klaar// code blocks ===
a micro-idea before going to bed. we all know it's a bad idea to copy code blocks from the formatted version of a page.
if i want to test some freshly posted code, here's what i have to do:
~1) scan the page for the chunk of code i want to save (this can be pretty difficult on long source pages with no syntax highlighting);
wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
see grabcodehandler for a first proposal -- dartar
===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"))
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
(the following was copied from a comment on modrewrite -- javawoman)
//hi, i discovered that the default .htaccess included did not work for my setup up. i needed to include ""rewritebase"" /directory/ as well since wikka is installed in a subdirectory. i hope this helps anyone having trouble getting wikka to work.
the installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""rewritebase"" statement to take care of this. --javawoman
===separation of wakka class from wikka.php===
i use wikka as wiki engine of [[http://diantn.free.fr my page]].
imo, the wikka.php file is too big to be one single file. i suggest that we separate the wakka class into new file, say wakka.class.php
and then in the wikka.php, e.g at line where the wakka class previously located, simply we put:
include ('wakka.class.php');
-- din
~&din, this is a //very// good idea. i fact, the idea had crossed my mind already, but thanks for the reminder. :) indeed, a class belongs in a file of its own. --javawoman
~~&maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --nilslindenberg
~~~&with my current proposed structure on wikkacodestructure, it would go into the library folder; classes that are shared, into library/common. i prefer a //functional// separation rather than one based on coding format. --javawoman
===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):
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
===save pages to pdf format===
(copied from wikkadevelopment --nils)
page output to an adobe pdf file using fpdf.
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:
~&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
is there a way to include a target in a link, so that the link opens in a new window?
--gregorlindner
===signature===
//(copied from wikkafaq, but perhaps better at wantedformatters? --nilslindenberg)//
does wikka support automatic user signatures in pages (not comments)? i need some code so that users don't need to enter their username and time/date when they are working on a page in threadmode. i've searched in the docs, but i could not find anything about this, any ideas?
-- jeroenjansen (2005-01-28 11:35:43)
~& jeroen, there is a hack for automatically adding a user's signature in wakkawiki posted by nickk on his [[http://wakkawiki.de/nickk homepage]]. it should be easy to adapt to wikka. -- dartar
~~& dartar, just saw your reply. thanks for the hint! --jeroenjansen
=== 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
=== create rewrite rules on install ===
~//copied from comment on wikkainstallation --javawoman//
since i installed wikka in a subdirectory under the domain root i needed to add the following to the .htaccess file just under """rewriteengine on""":
""rewritebase"" /subdirectory/
devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-- karmatester (2005-01-26 06:52:07)
=== image dimensions ===
the [[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
~~~¬ed. 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
===clearing acls===
there should be a button on the acl page to "reset acls to default". what this would do is delete the record for the current page from the acls table. there is a distinction between setting the acls to the sites default values and not having acls defined for a page. if the acls are set and the default values get changed, the page will remain at the set values. however, if no acls are defined, the page will always use the default values.
to help show the distinction, there should be a visual indicator on the acl handler page which states whether the page has acls defined or is using the site's default values. basically, just check for a record in the acls table for the current page, and display a message accordingly. -- jsnx
== user registration control ==
it would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (or at least the configurable option to check for only one email/one account.)
it should also then be easier (i would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful aclswithusergroups hack that christian created to make a list of banned users by username. yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --movielady
~&you know how many testusers my wikka already has? *g* this should do the job (this time no config option, sorry jw :)
function existsemail($email)
$query = "select count(email)
from ".$this->config['table_prefix']."users
where email='".mysql_real_escape_string($email)."'";
if ($r = $this->query($query))
return ($count > 0) ? true : false;
~&place this function in wikka.php right after function userwantscomments(). and change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "password too short.";
else if (strlen($password) < 5) $error = "password too short.";
else if ($this->existsemail($email)) $error = "you already have a username.";
~&--nilslindenberg
~~& lol i can imagine. thanks so much for this - i'll try it out this evening. --movielady
~& speaking of registration control, note to self: make a configuration option to turn off new account registrations. some sites might be private and not want people registering. admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- jsnx
~~& (you saw userregistration by nils? i think it, or something like it, should be standard. mike)
~~~& doh! i somehow missed that. that's pretty much what i had in mind. nice job, nils! :) -- jsnx
~~~~&thank you. about your admin-adding-user case: that's an addition to useradmin, not for usersettings. --nilslindenberg
~~~&there's also code around that uses gd & that could be built onto nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. ultimately, as the bots become more sophisticated i think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what i mean (i like the simplicity of the first version in the second example). -- gmbowen
~~~~&yes, "captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). add a sound equivalent? well, there are people who are deaf **and** blind. are we going to deny them access to our wikis? i'm not in favor of making wikka **in**accessible when we should be working towards making it **more** accessible. --javawoman.
=== rss options ===
it would be wonderful to be able to choose what kind of rss feed is created for a page. for example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --movielady
=== 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
~¬ed - good suggestion. --javawoman
if ($pages = $this->loadpageslinkingto($this->getpagetag())) {
$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
=== language file ===
i would be nice to see all phrases put into a single file. this would allow to translate the wiki in a few hours without changes every single file.
~&look at dotmgs approach at wikkainternationalization. but at least it should work for languages in the range of the "normal" (ascii?) code. if you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --nilslindenberg
~~&the most flexible and powerful way to support i18n is still gettext which is supported by php. if we go in that direction (likely), manually creating a "language file" is needless work since gettext does all that automatically for you. and it supports options for handling plurals and such which simple string-to-string language files cannot handle. the problem is that code needs to be written in a way to properly be able to use gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any html markup (actually this is true for simple laguage files as well). currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --javawoman
=== 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!";
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
===finally using cvs?===
i apologize since this idea has been suggested before, and i believe the developers are working to implement it already. however, with the beta of 1.1.6.0 released, i think it would be a good time now to start using cvs. this allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. in addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
also, i am willing to help with the cvs migration process if needed and help anyone who is interested in learning how to use cvs.
-- mikexstudios
~&there is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. just has to be updated --nilslindenberg
~~&actually, nils, we need a lot more than "just updating" the cvs at sourceforge. we need to integrate cvs in our development process - and develop a process for doing so. that requires a bit of planning... :) and while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with cvs specifically, so a bit of study will be required before we can start planning. help with learning how to use cvs //well// from someone who has experience with it would certainly be welcome, mike! thanks for the offer. --javawoman ''(reading manuals....)''
~~~& the "just was meant as an addition to existing ("of course" would have been better, though :). i just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case mike does not no. it is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --nilslindenberg
~~~~& hi nils. actually, i did find wikka's cvs repository at sf weeks ago, but i forgot to mention it in my above post. javawoman pretty much echoed my thoughts. we need to actively use cvs/update it constantly as changes are made. i run a project called [[http://xcomic.sourceforge.net xcomic]] that uses sourceforge's cvs a lot, so i have some experience with that. in addition, i recently set something up for my project that i think will be pretty cool if wikka decides to really use cvs: a commit mailing list. anytime someone makes a change to the cvs (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). in any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --mikexstudios
~~~~~&mike, i for one would welcome your insights in using cvs. both dartar and i have some ideas about how we want it set up - but no experience in doing so (in cvs). may i suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? for this type of thing i think that would be the best medium to discuss thoughs and methods. i like the idea of a commit mailing list. --javawoman
===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
===local links===
it would be nice if a link to the same host as the wikka install was not flagged as 'external'. i've added a 'hack' to my personal page: kickthedonkey. works fine here.
--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...
- 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''
===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
===online editing of mindmaps would be great===
(copied from sourceforge.net --nilslindenberg)
it would be great, if users should work together on mindmaps.
maybe by downloading/ open with freemind and then having a possiblity to save changes in freemind directly back to the online mindmap.
===how to format code to get two % characters without space together?===
i want to produce a code sample page in wikka with dos batch code. the code syntax requires two percent characters together to markup a variable. example: % %variable% % (without the spaces). wikka always tries to format the text as code, even if i format the dos code inside a code block, even if i %% marked it as code with two percent characters like this here%%
is there a solution? i could not find a literal entity for "percent"
''you could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. see: %%some text with %% embedded in it%%
but it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (and how do you markup wiki markup as **code**?) -- javawoman''
how about the € (euro) symbol? or is it to new? --nilslindenberg
''the main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. and it might occur in code as well (imagine a sample conversion routine). wiki markup should be easy to type. so we need a symbol (or sumbol combination, maybe), that's:
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of apl!)
the **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). maybe we should do a search (google?) to check whether **!!** or a combo is actually an operator in any language.
-- javawoman''
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:
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?:
$timestamp = $wakka->getpagetime(); //hopefully this function returns the right format?
return (++$trigger_deleted % 2 ? "<del datetime=\"$timestamp\">" : "</del>");
--nilslindenberg
working on a test installation, i found the user setting "show comments by default" did not work. testing it here, i found it doesn't work here, either.
haven't dug in the code yet to find where this should happen (but will).
i'm quite happy with wikka's capabilities out of the box - good starting point! :) i'll likely stay with it - but i'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
great work! javawoman
it does work.... just not as might be expected. comment preference is stored for each page as you browse the wiki. so, if you browse a few pages with comments not showing, it remembers this. then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
try this:
- browse to usersettings and check off "show comments by default" and click "update settings".
- now **close all browser windows**
- open back up your browser and go to the same pages......
- comments are now showing by default, right?
- jsnx
right. i see it does work. ;) somewhat, um, counterintuitive, though. so i guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). that would, i think, be more in line with expected behavior. possible? (i haven't looked at that area of the code yet.) --javawoman.
===language support===
i was searching almost whole site to check what kind of languages are supported by this wiki. i was unsuccessful. is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
thanks mdd
=== 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
== question: note? ==
it is me again! what is the function of the "please add a note on your edit" - field? again and again: keep on the good work.
-- skywalk
~& this note is shown in some lists like the recentchanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --dreckfehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --georgepetsagourakis
=== 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
the edit page handler seems to convert spaces to tabs throughout the entire document, including code blocks.
**from edit.php**
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
===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
===mod_rewrite===
take a look at favicondotico and robotsdottxt
categorydevelopmentsuggestions
Deletions:
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
~-SuggestionsArchive for resolved suggestions
**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]]
~-UserMap
=== Automatic conversoin from HTML to WakkiWiki syntax ===
Does such think 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
===Improved code for error messages in Action() method===
The ##Action()## method in ##wikka.php## produces errors in some cases; the error class was implemented as a span rather than directly on the <em> element surrounding the message. The span elements are superfluous and bad coding style.
Change:
%%(php;759) function Action($action, $forceLinkTracking = 0)
preg_match("/^([A-Za-z0-9]*)\s+(.*)$/", $action, $matches);
preg_match_all("/([A-Za-z0-9]*)=\"(.*)\"/U", $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>"; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
if (!preg_match("/^[a-zA-Z0-9]+$/", $action)) return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>";
if (!$forceLinkTracking) $this->StopLinkTracking();
$result = $this->IncludeBuffered(strtolower($action).".php", "<em>Unknown action \"$action\"</em>", $vars, $this->config["action_path"]);
$this->StartLinkTracking();
%%(php) // JW Action() modified to allow attributes in single quotes
// JW 2005-07-08 error class moved to em
function Action($action, $forceLinkTracking = 0)
preg_match('/^([A-Za-z0-9]*)\s+(.*)$/', $action, $matches);
preg_match_all('/([A-Za-z0-9]*)=("|\')(.*)\\2/U', $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
#return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
return '<em class="error">Unknown action; the action name must not contain special characters.</em>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
#if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>';
if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<em class="error">Unknown action; the action name must not contain special characters.</em>';
if (!$forceLinkTracking) $this->StopLinkTracking();
#$result = $this->IncludeBuffered(strtolower($action).'.php', '<em>Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$result = $this->IncludeBuffered(strtolower($action).'.php', '<em class="error">Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$this->StartLinkTracking();
Now implemented as beta on this site. --JavaWoman
===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
===Exclude certain CamelCase words from formatting===
Popular Scottish surnames such as McKenna are wrongly being interpreted as WikiNames - is there any way to prevent that happening?
How about something like a lookup table where WikiAdmins enter a list of words that will be ignored for formatting on all pages? -- JsnX
~& Sounds like a nice addition. Two suggestions: 1) CamelCase parsing should be made optional in the config file. 2) the list of words to be skipped could be implemented as a wiki page (something similar has been proposed for menus, acronyms and group management): this would make it a lot easier to maintain the list. My 2 cents -- DarTar
===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]].
===Import WikiPedia database===
How can I import the Wikipedia database? I don't want to use MediaWiki. Any idea?
~& Sorry, there is no filter yet to convert MediaWiki content to WikkaWiki content, but it sounds like a nice feature suggestion. After all MW markup is quite stable... This said, do you //really// mean you want to import the actual Wikipedia database and have it run on a different wiki engine? -- DarTar
~& Yes, i want. It would be great. Maybe other sites will change to WikkaWikki when they can import a MediaWiki databse.
===Note on edit, mandatory field===
I think it would be a good ide to let the administrator choose if the field is mandatory.
If it is, the form doesn't submit until there is content into it, and it should warn too with an alertbox.
Only a little bit of PHP is necessary, the big part is in JS, if i don't make any mistake...
--SamuelDr
===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.
if ($existingUser["password"] == md5($_POST["password"]) || $existingUser["password"]==$_POST["password"])
This is the current version:
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
===Order of comments===
WikiJochen made a comment on my page that would like to see the latest comment shown first and not last. --NilsLindenberg
===Own comments editing===
I think that it would be a good option to allow one to edit its own comments, sometimes, I make mistakes when commenting, typos or language things (i'm a foreigner) and I want my texts to all look clean.
Currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, I'm lazy, just like many other people. --SamuelDr
~&SamuelDr, this is a good suggestion. I've had the same thought about needing the ability to edit comments. The problem with "copy and then delete" is this can only be done until someone else comments. Otherwise the comments will be out of order. Consider it on the todo list for a future release. -- JsnX
===Google Sitemap===
See [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --NilsLindenberg
~&Apparently Google uses **URLs** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our URLs inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). The only case I could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so Google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell Google to **not** follow the links on that page, Google can find orphan pages as well. So I don't really see how this could actually help, given the "lack of structure" of a wiki. --JavaWoman
//copied from a comment from AttachmentInfo --NilsLindenberg//
Does Wikka support versioning of attachments?
IMHO a good idea. --Nils
~&See allso WikkaLogicalDataModel --JavaWoman
===Making PageIndex go faster===
By default PageIndex uses $this->""LoadAllPages""() which reads your **whole site** into one array. If you would use a new function like $this->""LoadAllPagesInfo""() you will get the same info but without the 'body' content. This should speed up PageIndex a bit on larger sites...
1) Find in ##wikka.php## (Around 33%)
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
And replace it with:
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }
function LoadAllPagesInfo() { return $this->LoadAll("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
1) Find in ##actions/pageindex.php## (top)
%%(php)if ($pages = $this->LoadAllPages())%%
And replace it with:
%%(php)if ($pages = $this->LoadAllPagesInfo())%%
1) Same trick as in (2) can be done in ##actions/mypages.php##...
-- OnegWR
~&See the first item on WikkaOptimization, too --NilsLindenberg
===Generate ID in forms; allow class===
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made it into a semi-spec.//
Every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
In addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). So the ##""FormOpen()""## method should also:
--JavaWoman
~&An implementation for this is now coded and tested (and will soon be added as a beta feature on this site). See AdvancedFormOpen and GenerateUniqueId for the code --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");
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-adress 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
===Single-click restore of previous versions===
//copied from WikkaBugs - this is a suggestion, not a bug --NilsLindenberg//
Single-click restore of previous versions (without copying/pasting). -Sam
~& ''Yes, this will be implemented at some point.'' - JsnX
~~&I should point out that there is an alternative to copying/pasting.
~~~& Go to the revisions page.
~~~& Click the date and time link that you would like to revert back to.
~~~& Click the 'Re-edit this old revision' button.
~~~& Click the 'Store' button.
In any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. While our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own Wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
The only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. There are two problems with this:
~1)Users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)Code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
Copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. If any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of Wikka). That leaves us with finding an escape method that's easy for users to implement.
There are two requirements for an "escaped" ""%%"" then:
~1)Easy to remember and apply by end users
~1)Not (not likely) part of the syntax of any language
One option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. A good candidate might be **DOUBLE_PERCENT** - it's easy enough to remember and easy to implement:
The formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to GeSHI for rendering; the grab code handler could just as easily replace it before making the code block available for download.
Thoughts anyone?
--JavaWoman
~&It's a good idea, but: You are sure DOUBLE_PERCENT is no reserved word in a language? Or unlikely to comme up in a code? --NilsLindenberg
~~&Try googling for 'DOUBLE_PERCENT': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). It's certainly not a reserved word in any of the languages GeSHi currently has support for, going by the language files it comes with. There's no way to be 100% certain but it seems to be a pretty safe bet. --JavaWoman
===Preview===
A doubleclick on a page in the preview should lead to "re-edit" of the text. --NilsLindenberg
~& Good point, agreed -- DarTar
Another point: The access-key for "re-edit" is alt+p at the moment. Wouldn't alt+e be more logic? --NilsLindenberg
===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
===Color Formatting===
The current color formatting isn't very wiki like. Altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
this regex syntax is lifted from a ""UseMod"" Wiki patch.
%%s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
I am by NO means a regex expert, but it seems that this should do the deal... I'm just not sure where it would go. By using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--MonstoBrukes
~&Please take a look at WikkaExtensibleMarkup --NilsLindenberg
~~&I looked at it. what point specifically did you intend i take from it?
~~~& JavaWoman had a proposal about a color-markup there. I think its the better place for the discussion. The recognition of markup is done in the formatter (formatters/wakka.php). I am no expert for regexps too, but wouldn't the first or catch too much? --NilsLindenberg
===Integration into existing site===
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
===Documentation===
copied to DocumentationDiscussion. --NilsLindenberg
===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:
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
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
===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
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
~~& 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
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
===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"))
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
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
include ('Wakka.class.php');
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
===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):
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
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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:
~&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
Is there a way to include a target in a link, so that the Link opens in a new window?
--GregorLindner
===Signature===
//(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)//
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
=== 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
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-- KarmaTester (2005-01-26 06:52:07)
=== Image dimensions ===
The [[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
===Clearing ACLs===
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
function ExistsEmail($email)
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
return ($count > 0) ? TRUE : FALSE;
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
=== RSS options ===
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
=== 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
if ($pages = $this->LoadPagesLinkingTo($this->getPageTag())) {
$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
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
=== 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!";
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
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
===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
===Local links===
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--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...
- 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''
===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
===Online editing of mindmaps would be great===
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
===How to format code to get two % characters without space together?===
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
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:
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?:
$timestamp = $wakka->GetPageTime(); //hopefully this function returns the right format?
return (++$trigger_deleted % 2 ? "<DEL datetime=\"$timestamp\">" : "</DEL>");
--NilsLindenberg
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
===Language support===
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
=== 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
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
~& this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
=== 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
The edit page handler seems to convert spaces to tabs throughout the entire document, including Code blocks.
**From edit.php**
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
===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
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
CategoryDevelopmentSuggestions
Revision [10249]
Edited on 2005-07-29 21:03:26 by dsl-082-082-148-112.arcor-ip.net [reply (html -> wikka)]Additions:
:Try out http://diberri.dyndns.org/html2wiki.html (Won't work with tables yet). --NilsLindenberg
Additions:
--CsillagKristof
Revision [10132]
Edited on 2005-07-19 15:50:56 by CsillagKristof [Removed spelling errors from my former suggestion]Additions:
Does such think exist? For a number of other Wikies, it does.
It should be nice (one could say, essential) to have this here, too.
It should be nice (one could say, essential) to have this here, too.
Deletions:
It should be nice. (One could say, essential) to have this here, too.
Revision [10131]
Edited on 2005-07-19 14:46:40 by CsillagKristof [Removed spelling errors from my former suggestion]Additions:
=== Automatic conversoin from HTML to WakkiWiki syntax ===
Does such think exist? For a number of other Wikies, i does.
It should be nice. (One could say, essential) to have this here, too.
Does such think exist? For a number of other Wikies, i does.
It should be nice. (One could say, essential) to have this here, too.
Additions:
===Improved code for error messages in Action() method===
The ##Action()## method in ##wikka.php## produces errors in some cases; the error class was implemented as a span rather than directly on the <em> element surrounding the message. The span elements are superfluous and bad coding style.
Change:
%%(php;759) function Action($action, $forceLinkTracking = 0)
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
// treat everything after the first whitespace as parameter
preg_match("/^([A-Za-z0-9]*)\s+(.*)$/", $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all("/([A-Za-z0-9]*)=\"(.*)\"/U", $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[2][$a];
}
}
$vars["wikka_vars"] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>"; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
if (!preg_match("/^[a-zA-Z0-9]+$/", $action)) return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>";
if (!$forceLinkTracking) $this->StopLinkTracking();
$result = $this->IncludeBuffered(strtolower($action).".php", "<em>Unknown action \"$action\"</em>", $vars, $this->config["action_path"]);
$this->StartLinkTracking();
return $result;
%%---
to:
%%(php) // JW Action() modified to allow attributes in single quotes
// JW 2005-07-08 error class moved to em
function Action($action, $forceLinkTracking = 0)
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
// treat everything after the first whitespace as parameter
preg_match('/^([A-Za-z0-9]*)\s+(.*)$/', $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all('/([A-Za-z0-9]*)=("|\')(.*)\\2/U', $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[3][$a];
}
}
$vars['wikka_vars'] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
#return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
return '<em class="error">Unknown action; the action name must not contain special characters.</em>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
#if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>';
if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<em class="error">Unknown action; the action name must not contain special characters.</em>';
if (!$forceLinkTracking) $this->StopLinkTracking();
#$result = $this->IncludeBuffered(strtolower($action).'.php', '<em>Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$result = $this->IncludeBuffered(strtolower($action).'.php', '<em class="error">Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$this->StartLinkTracking();
return $result;
%%---
Now implemented as beta on this site. --JavaWoman
function LoadAllPagesInfo() { return $this->LoadAll("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
The ##Action()## method in ##wikka.php## produces errors in some cases; the error class was implemented as a span rather than directly on the <em> element surrounding the message. The span elements are superfluous and bad coding style.
Change:
%%(php;759) function Action($action, $forceLinkTracking = 0)
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
// treat everything after the first whitespace as parameter
preg_match("/^([A-Za-z0-9]*)\s+(.*)$/", $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all("/([A-Za-z0-9]*)=\"(.*)\"/U", $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[2][$a];
}
}
$vars["wikka_vars"] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>"; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
if (!preg_match("/^[a-zA-Z0-9]+$/", $action)) return "<span class='error'><em>Unknown action; the action name must not contain special characters.</em></span>";
if (!$forceLinkTracking) $this->StopLinkTracking();
$result = $this->IncludeBuffered(strtolower($action).".php", "<em>Unknown action \"$action\"</em>", $vars, $this->config["action_path"]);
$this->StartLinkTracking();
return $result;
%%---
to:
%%(php) // JW Action() modified to allow attributes in single quotes
// JW 2005-07-08 error class moved to em
function Action($action, $forceLinkTracking = 0)
$action = trim($action);
$vars=array();
// only search for parameters if there is a space
if (is_int(strpos($action, ' ')))
// treat everything after the first whitespace as parameter
preg_match('/^([A-Za-z0-9]*)\s+(.*)$/', $action, $matches);
// extract $action and $vars_temp ("raw" attributes)
list(, $action, $vars_temp) = $matches;
if ($action) {
// match all attributes (key and value)
preg_match_all('/([A-Za-z0-9]*)=("|\')(.*)\\2/U', $vars_temp, $matches);
// prepare an array for extract() to work with (in $this->IncludeBuffered())
if (is_array($matches)) {
for ($a = 0; $a < count($matches[0]); $a++) {
$vars[$matches[1][$a]] = $matches[3][$a];
}
}
$vars['wikka_vars'] = trim($vars_temp); // <<< add the buffered parameter-string to the array
} else {
#return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
return '<em class="error">Unknown action; the action name must not contain special characters.</em>'; // <<< the pattern ([A-Za-z0-9])\s+ didn't match!
}
#if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<span class="error"><em>Unknown action; the action name must not contain special characters.</em></span>';
if (!preg_match('/^[a-zA-Z0-9]+$/', $action)) return '<em class="error">Unknown action; the action name must not contain special characters.</em>';
if (!$forceLinkTracking) $this->StopLinkTracking();
#$result = $this->IncludeBuffered(strtolower($action).'.php', '<em>Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$result = $this->IncludeBuffered(strtolower($action).'.php', '<em class="error">Unknown action "'.$action.'"</em>', $vars, $this->config['action_path']);
$this->StartLinkTracking();
return $result;
%%---
Now implemented as beta on this site. --JavaWoman
function LoadAllPagesInfo() { return $this->LoadAll("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
Deletions:
Additions:
===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
//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
Additions:
=====Suggestion Box=====
{{lastedit show="3"}}
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
~-SuggestionsArchive for resolved suggestions
**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
>>{{feedback}}
::c::
----
===Exclude certain CamelCase words from formatting===
Popular Scottish surnames such as McKenna are wrongly being interpreted as WikiNames - is there any way to prevent that happening?
-- host86-133-223-194.range86-133.btcentralplus.com (2005-07-09 13:23:06)
How about something like a lookup table where WikiAdmins enter a list of words that will be ignored for formatting on all pages? -- JsnX
~& Sounds like a nice addition. Two suggestions: 1) CamelCase parsing should be made optional in the config file. 2) the list of words to be skipped could be implemented as a wiki page (something similar has been proposed for menus, acronyms and group management): this would make it a lot easier to maintain the list. My 2 cents -- DarTar
----
===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]].
----
===Import WikiPedia database===
How can I import the Wikipedia database? I don't want to use MediaWiki. Any idea?
~& Sorry, there is no filter yet to convert MediaWiki content to WikkaWiki content, but it sounds like a nice feature suggestion. After all MW markup is quite stable... This said, do you //really// mean you want to import the actual Wikipedia database and have it run on a different wiki engine? -- DarTar
~& Yes, i want. It would be great. Maybe other sites will change to WikkaWikki when they can import a MediaWiki databse.
----
===Note on edit, mandatory field===
I think it would be a good ide to let the administrator choose if the field is mandatory.
If it is, the form doesn't submit until there is content into it, and it should warn too with an alertbox.
Only a little bit of PHP is necessary, the big part is in JS, if i don't make any mistake...
--SamuelDr
----
===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
----
===Order of comments===
WikiJochen made a comment on my page that would like to see the latest comment shown first and not last. --NilsLindenberg
----
===Own comments editing===
I think that it would be a good option to allow one to edit its own comments, sometimes, I make mistakes when commenting, typos or language things (i'm a foreigner) and I want my texts to all look clean.
Currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, I'm lazy, just like many other people. --SamuelDr
~&SamuelDr, this is a good suggestion. I've had the same thought about needing the ability to edit comments. The problem with "copy and then delete" is this can only be done until someone else comments. Otherwise the comments will be out of order. Consider it on the todo list for a future release. -- JsnX
----
===Google Sitemap===
See [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --NilsLindenberg
~&Apparently Google uses **URLs** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our URLs inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). The only case I could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so Google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell Google to **not** follow the links on that page, Google can find orphan pages as well. So I don't really see how this could actually help, given the "lack of structure" of a wiki. --JavaWoman
----
===versioning of attachments===
//copied from a comment from AttachmentInfo --NilsLindenberg//
Does Wikka support versioning of attachments?
IMHO a good idea. --Nils
~&See allso WikkaLogicalDataModel --JavaWoman
----
===Making PageIndex go faster===
By default PageIndex uses $this->""LoadAllPages""() which reads your **whole site** into one array. If you would use a new function like $this->""LoadAllPagesInfo""() you will get the same info but without the 'body' content. This should speed up PageIndex a bit on larger sites...
1) Find in ##wikka.php## (Around 33%)
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
And replace it with:
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }
function LoadAllPagesInfo() { return $this->LoadAll("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
1) Find in ##actions/pageindex.php## (top)
%%(php)if ($pages = $this->LoadAllPages())%%
And replace it with:
%%(php)if ($pages = $this->LoadAllPagesInfo())%%
1) Same trick as in (2) can be done in ##actions/mypages.php##...
-- OnegWR
~&See the first item on WikkaOptimization, too --NilsLindenberg
----
===Generate ID in forms; allow class===
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made it into a semi-spec.//
Every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
~-accept an //optional// parameter specifying an id and - if specified - use this to generate an id attribute
~-if the parameter is not specified, generate one using some algorithm to ensure it will be unique on the page (possibly using all provided parameters to create a hash, supplemented with a sequence number); only problem is this id might change when adding / inserting another form into a page but that could be worked around by actually specifying an id.
In addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). So the ##""FormOpen()""## method should also:
~-accept an //optional// parameter specifying a class and - if specified - use this to generate a class attribute (and no class attribute if not specified).
--JavaWoman
~&An implementation for this is now coded and tested (and will soon be added as a beta feature on this site). See AdvancedFormOpen and GenerateUniqueId for the code --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-adress 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
----
===Single-click restore of previous versions===
//copied from WikkaBugs - this is a suggestion, not a bug --NilsLindenberg//
Single-click restore of previous versions (without copying/pasting). -Sam
~& ''Yes, this will be implemented at some point.'' - JsnX
~~&I should point out that there is an alternative to copying/pasting.
~~~& Go to the revisions page.
~~~& Click the date and time link that you would like to revert back to.
~~~& Click the 'Re-edit this old revision' button.
~~~& Click the 'Store' button.
----
===""%%"" in code blocks: a possible workaround===
In any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. While our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own Wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
The only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. There are two problems with this:
~1)Users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)Code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
Copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. If any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of Wikka). That leaves us with finding an escape method that's easy for users to implement.
There are two requirements for an "escaped" ""%%"" then:
~1)Easy to remember and apply by end users
~1)Not (not likely) part of the syntax of any language
One option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. A good candidate might be **DOUBLE_PERCENT** - it's easy enough to remember and easy to implement:
The formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to GeSHI for rendering; the grab code handler could just as easily replace it before making the code block available for download.
Thoughts anyone?
--JavaWoman
~&It's a good idea, but: You are sure DOUBLE_PERCENT is no reserved word in a language? Or unlikely to comme up in a code? --NilsLindenberg
~~&Try googling for 'DOUBLE_PERCENT': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). It's certainly not a reserved word in any of the languages GeSHi currently has support for, going by the language files it comes with. There's no way to be 100% certain but it seems to be a pretty safe bet. --JavaWoman
----
===Preview===
A doubleclick on a page in the preview should lead to "re-edit" of the text. --NilsLindenberg
~& Good point, agreed -- DarTar
Another point: The access-key for "re-edit" is alt+p at the moment. Wouldn't alt+e be more logic? --NilsLindenberg
----
===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
----
===Color Formatting===
The current color formatting isn't very wiki like. Altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
%%^<color> text^%%
this regex syntax is lifted from a ""UseMod"" Wiki patch.
%%s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
I am by NO means a regex expert, but it seems that this should do the deal... I'm just not sure where it would go. By using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--MonstoBrukes
~&Please take a look at WikkaExtensibleMarkup --NilsLindenberg
~~&I looked at it. what point specifically did you intend i take from it?
~~~& JavaWoman had a proposal about a color-markup there. I think its the better place for the discussion. The recognition of markup is done in the formatter (formatters/wakka.php). I am no expert for regexps too, but wouldn't the first or catch too much? --NilsLindenberg
----
===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
----
===Documentation===
copied to DocumentationDiscussion. --NilsLindenberg
----
===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
----
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
~~& 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
----
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
----
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
----
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) open a ##/raw## version of the page;
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
~1) open a text editor;
~1) copy the code block;
~1) paste it in the text editor;
~1) save the file.
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
%%
include ('Wakka.class.php');
%%
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
----
===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
----
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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?
--GregorLindner
----
===Signature===
//(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)//
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
----
=== 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
----
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
=== Image dimensions ===
The [[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
----
===Clearing ACLs===
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
----
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
=== RSS options ===
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
----
=== 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;
%%
----
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
=== 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
----
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
===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
----
===Local links===
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--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''
----
===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
----
===Online editing of mindmaps would be great===
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
----
===How to format code to get two % characters without space together?===
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
----
===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
----
===showing comments===
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
----
===Language support===
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
----
=== 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
----
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
~& this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
----
=== 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
----
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
----
{{lastedit show="3"}}
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
~-SuggestionsArchive for resolved suggestions
**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
>>{{feedback}}
::c::
----
===Exclude certain CamelCase words from formatting===
Popular Scottish surnames such as McKenna are wrongly being interpreted as WikiNames - is there any way to prevent that happening?
-- host86-133-223-194.range86-133.btcentralplus.com (2005-07-09 13:23:06)
How about something like a lookup table where WikiAdmins enter a list of words that will be ignored for formatting on all pages? -- JsnX
~& Sounds like a nice addition. Two suggestions: 1) CamelCase parsing should be made optional in the config file. 2) the list of words to be skipped could be implemented as a wiki page (something similar has been proposed for menus, acronyms and group management): this would make it a lot easier to maintain the list. My 2 cents -- DarTar
----
===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]].
----
===Import WikiPedia database===
How can I import the Wikipedia database? I don't want to use MediaWiki. Any idea?
~& Sorry, there is no filter yet to convert MediaWiki content to WikkaWiki content, but it sounds like a nice feature suggestion. After all MW markup is quite stable... This said, do you //really// mean you want to import the actual Wikipedia database and have it run on a different wiki engine? -- DarTar
~& Yes, i want. It would be great. Maybe other sites will change to WikkaWikki when they can import a MediaWiki databse.
----
===Note on edit, mandatory field===
I think it would be a good ide to let the administrator choose if the field is mandatory.
If it is, the form doesn't submit until there is content into it, and it should warn too with an alertbox.
Only a little bit of PHP is necessary, the big part is in JS, if i don't make any mistake...
--SamuelDr
----
===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
----
===Order of comments===
WikiJochen made a comment on my page that would like to see the latest comment shown first and not last. --NilsLindenberg
----
===Own comments editing===
I think that it would be a good option to allow one to edit its own comments, sometimes, I make mistakes when commenting, typos or language things (i'm a foreigner) and I want my texts to all look clean.
Currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, I'm lazy, just like many other people. --SamuelDr
~&SamuelDr, this is a good suggestion. I've had the same thought about needing the ability to edit comments. The problem with "copy and then delete" is this can only be done until someone else comments. Otherwise the comments will be out of order. Consider it on the todo list for a future release. -- JsnX
----
===Google Sitemap===
See [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --NilsLindenberg
~&Apparently Google uses **URLs** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our URLs inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). The only case I could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so Google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell Google to **not** follow the links on that page, Google can find orphan pages as well. So I don't really see how this could actually help, given the "lack of structure" of a wiki. --JavaWoman
----
===versioning of attachments===
//copied from a comment from AttachmentInfo --NilsLindenberg//
Does Wikka support versioning of attachments?
IMHO a good idea. --Nils
~&See allso WikkaLogicalDataModel --JavaWoman
----
===Making PageIndex go faster===
By default PageIndex uses $this->""LoadAllPages""() which reads your **whole site** into one array. If you would use a new function like $this->""LoadAllPagesInfo""() you will get the same info but without the 'body' content. This should speed up PageIndex a bit on larger sites...
1) Find in ##wikka.php## (Around 33%)
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
And replace it with:
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }
function LoadAllPagesInfo() { return $this->LoadAll("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
1) Find in ##actions/pageindex.php## (top)
%%(php)if ($pages = $this->LoadAllPages())%%
And replace it with:
%%(php)if ($pages = $this->LoadAllPagesInfo())%%
1) Same trick as in (2) can be done in ##actions/mypages.php##...
-- OnegWR
~&See the first item on WikkaOptimization, too --NilsLindenberg
----
===Generate ID in forms; allow class===
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made it into a semi-spec.//
Every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
~-accept an //optional// parameter specifying an id and - if specified - use this to generate an id attribute
~-if the parameter is not specified, generate one using some algorithm to ensure it will be unique on the page (possibly using all provided parameters to create a hash, supplemented with a sequence number); only problem is this id might change when adding / inserting another form into a page but that could be worked around by actually specifying an id.
In addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). So the ##""FormOpen()""## method should also:
~-accept an //optional// parameter specifying a class and - if specified - use this to generate a class attribute (and no class attribute if not specified).
--JavaWoman
~&An implementation for this is now coded and tested (and will soon be added as a beta feature on this site). See AdvancedFormOpen and GenerateUniqueId for the code --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-adress 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
----
===Single-click restore of previous versions===
//copied from WikkaBugs - this is a suggestion, not a bug --NilsLindenberg//
Single-click restore of previous versions (without copying/pasting). -Sam
~& ''Yes, this will be implemented at some point.'' - JsnX
~~&I should point out that there is an alternative to copying/pasting.
~~~& Go to the revisions page.
~~~& Click the date and time link that you would like to revert back to.
~~~& Click the 'Re-edit this old revision' button.
~~~& Click the 'Store' button.
----
===""%%"" in code blocks: a possible workaround===
In any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. While our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own Wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
The only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. There are two problems with this:
~1)Users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)Code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
Copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. If any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of Wikka). That leaves us with finding an escape method that's easy for users to implement.
There are two requirements for an "escaped" ""%%"" then:
~1)Easy to remember and apply by end users
~1)Not (not likely) part of the syntax of any language
One option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. A good candidate might be **DOUBLE_PERCENT** - it's easy enough to remember and easy to implement:
The formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to GeSHI for rendering; the grab code handler could just as easily replace it before making the code block available for download.
Thoughts anyone?
--JavaWoman
~&It's a good idea, but: You are sure DOUBLE_PERCENT is no reserved word in a language? Or unlikely to comme up in a code? --NilsLindenberg
~~&Try googling for 'DOUBLE_PERCENT': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). It's certainly not a reserved word in any of the languages GeSHi currently has support for, going by the language files it comes with. There's no way to be 100% certain but it seems to be a pretty safe bet. --JavaWoman
----
===Preview===
A doubleclick on a page in the preview should lead to "re-edit" of the text. --NilsLindenberg
~& Good point, agreed -- DarTar
Another point: The access-key for "re-edit" is alt+p at the moment. Wouldn't alt+e be more logic? --NilsLindenberg
----
===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
----
===Color Formatting===
The current color formatting isn't very wiki like. Altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
%%^<color> text^%%
this regex syntax is lifted from a ""UseMod"" Wiki patch.
%%s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
I am by NO means a regex expert, but it seems that this should do the deal... I'm just not sure where it would go. By using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--MonstoBrukes
~&Please take a look at WikkaExtensibleMarkup --NilsLindenberg
~~&I looked at it. what point specifically did you intend i take from it?
~~~& JavaWoman had a proposal about a color-markup there. I think its the better place for the discussion. The recognition of markup is done in the formatter (formatters/wakka.php). I am no expert for regexps too, but wouldn't the first or catch too much? --NilsLindenberg
----
===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
----
===Documentation===
copied to DocumentationDiscussion. --NilsLindenberg
----
===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
----
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
~~& 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
----
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
----
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
----
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) open a ##/raw## version of the page;
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
~1) open a text editor;
~1) copy the code block;
~1) paste it in the text editor;
~1) save the file.
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
%%
include ('Wakka.class.php');
%%
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
----
===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
----
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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?
--GregorLindner
----
===Signature===
//(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)//
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
----
=== 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
----
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
=== Image dimensions ===
The [[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
----
===Clearing ACLs===
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
----
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
=== RSS options ===
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
----
=== 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;
%%
----
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
=== 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
----
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
===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
----
===Local links===
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--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''
----
===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
----
===Online editing of mindmaps would be great===
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
----
===How to format code to get two % characters without space together?===
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
----
===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
----
===showing comments===
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
----
===Language support===
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
----
=== 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
----
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
~& this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
----
=== 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
----
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
----
Deletions:
{{lastedit show="3"}}
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
~-SuggestionsArchive for resolved suggestions
**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
>>{{feedback}}
::c::
----
===Exclude certain CamelCase words from formatting===
Popular Scottish surnames such as McKenna are wrongly being interpreted as WikiNames - is there any way to prevent that happening?
-- host86-133-223-194.range86-133.btcentralplus.com (2005-07-09 13:23:06)
How about something like a lookup table where WikiAdmins enter a list of words that will be ignored for formatting on all pages? -- JsnX
----
===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]].
----
===Import WikiPedia database===
How can I import the Wikipedia database? I don't want to use MediaWiki. Any idea?
~& Sorry, there is no filter yet to convert MediaWiki content to WikkaWiki content, but it sounds like a nice feature suggestion. After all MW markup is quite stable... This said, do you //really// mean you want to import the actual Wikipedia database and have it run on a different wiki engine? -- DarTar
~& Yes, i want. It would be great. Maybe other sites will change to WikkaWikki when they can import a MediaWiki databse.
----
===Note on edit, mandatory field===
I think it would be a good ide to let the administrator choose if the field is mandatory.
If it is, the form doesn't submit until there is content into it, and it should warn too with an alertbox.
Only a little bit of PHP is necessary, the big part is in JS, if i don't make any mistake...
--SamuelDr
----
===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
----
===Order of comments===
WikiJochen made a comment on my page that would like to see the latest comment shown first and not last. --NilsLindenberg
----
===Own comments editing===
I think that it would be a good option to allow one to edit its own comments, sometimes, I make mistakes when commenting, typos or language things (i'm a foreigner) and I want my texts to all look clean.
Currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, I'm lazy, just like many other people. --SamuelDr
~&SamuelDr, this is a good suggestion. I've had the same thought about needing the ability to edit comments. The problem with "copy and then delete" is this can only be done until someone else comments. Otherwise the comments will be out of order. Consider it on the todo list for a future release. -- JsnX
----
===Google Sitemap===
See [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --NilsLindenberg
~&Apparently Google uses **URLs** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our URLs inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). The only case I could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so Google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell Google to **not** follow the links on that page, Google can find orphan pages as well. So I don't really see how this could actually help, given the "lack of structure" of a wiki. --JavaWoman
----
===versioning of attachments===
//copied from a comment from AttachmentInfo --NilsLindenberg//
Does Wikka support versioning of attachments?
IMHO a good idea. --Nils
~&See allso WikkaLogicalDataModel --JavaWoman
----
===Making PageIndex go faster===
By default PageIndex uses $this->""LoadAllPages""() which reads your **whole site** into one array. If you would use a new function like $this->""LoadAllPagesInfo""() you will get the same info but without the 'body' content. This should speed up PageIndex a bit on larger sites...
1) Find in ##wikka.php## (Around 33%)
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
And replace it with:
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }
function LoadAllPagesInfo() { return $this->LoadAll("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
1) Find in ##actions/pageindex.php## (top)
%%(php)if ($pages = $this->LoadAllPages())%%
And replace it with:
%%(php)if ($pages = $this->LoadAllPagesInfo())%%
1) Same trick as in (2) can be done in ##actions/mypages.php##...
-- OnegWR
~&See the first item on WikkaOptimization, too --NilsLindenberg
----
===Generate ID in forms; allow class===
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made it into a semi-spec.//
Every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
~-accept an //optional// parameter specifying an id and - if specified - use this to generate an id attribute
~-if the parameter is not specified, generate one using some algorithm to ensure it will be unique on the page (possibly using all provided parameters to create a hash, supplemented with a sequence number); only problem is this id might change when adding / inserting another form into a page but that could be worked around by actually specifying an id.
In addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). So the ##""FormOpen()""## method should also:
~-accept an //optional// parameter specifying a class and - if specified - use this to generate a class attribute (and no class attribute if not specified).
--JavaWoman
~&An implementation for this is now coded and tested (and will soon be added as a beta feature on this site). See AdvancedFormOpen and GenerateUniqueId for the code --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-adress 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
----
===Single-click restore of previous versions===
//copied from WikkaBugs - this is a suggestion, not a bug --NilsLindenberg//
Single-click restore of previous versions (without copying/pasting). -Sam
~& ''Yes, this will be implemented at some point.'' - JsnX
~~&I should point out that there is an alternative to copying/pasting.
~~~& Go to the revisions page.
~~~& Click the date and time link that you would like to revert back to.
~~~& Click the 'Re-edit this old revision' button.
~~~& Click the 'Store' button.
----
===""%%"" in code blocks: a possible workaround===
In any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. While our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own Wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
The only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. There are two problems with this:
~1)Users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)Code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
Copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. If any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of Wikka). That leaves us with finding an escape method that's easy for users to implement.
There are two requirements for an "escaped" ""%%"" then:
~1)Easy to remember and apply by end users
~1)Not (not likely) part of the syntax of any language
One option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. A good candidate might be **DOUBLE_PERCENT** - it's easy enough to remember and easy to implement:
The formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to GeSHI for rendering; the grab code handler could just as easily replace it before making the code block available for download.
Thoughts anyone?
--JavaWoman
~&It's a good idea, but: You are sure DOUBLE_PERCENT is no reserved word in a language? Or unlikely to comme up in a code? --NilsLindenberg
~~&Try googling for 'DOUBLE_PERCENT': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). It's certainly not a reserved word in any of the languages GeSHi currently has support for, going by the language files it comes with. There's no way to be 100% certain but it seems to be a pretty safe bet. --JavaWoman
----
===Preview===
A doubleclick on a page in the preview should lead to "re-edit" of the text. --NilsLindenberg
~& Good point, agreed -- DarTar
Another point: The access-key for "re-edit" is alt+p at the moment. Wouldn't alt+e be more logic? --NilsLindenberg
----
===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
----
===Color Formatting===
The current color formatting isn't very wiki like. Altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
%%^<color> text^%%
this regex syntax is lifted from a ""UseMod"" Wiki patch.
%%s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
I am by NO means a regex expert, but it seems that this should do the deal... I'm just not sure where it would go. By using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--MonstoBrukes
~&Please take a look at WikkaExtensibleMarkup --NilsLindenberg
~~&I looked at it. what point specifically did you intend i take from it?
~~~& JavaWoman had a proposal about a color-markup there. I think its the better place for the discussion. The recognition of markup is done in the formatter (formatters/wakka.php). I am no expert for regexps too, but wouldn't the first or catch too much? --NilsLindenberg
----
===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
----
===Documentation===
copied to DocumentationDiscussion. --NilsLindenberg
----
===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
----
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
~~& 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
----
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
----
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
----
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) open a ##/raw## version of the page;
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
~1) open a text editor;
~1) copy the code block;
~1) paste it in the text editor;
~1) save the file.
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
%%
include ('Wakka.class.php');
%%
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
----
===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
----
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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?
--GregorLindner
----
===Signature===
//(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)//
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
----
=== 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
----
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
=== Image dimensions ===
The [[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
----
===Clearing ACLs===
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
----
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
=== RSS options ===
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
----
=== 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;
%%
----
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
=== 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
----
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
===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
----
===Local links===
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--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''
----
===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
----
===Online editing of mindmaps would be great===
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
----
===How to format code to get two % characters without space together?===
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
----
===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
----
===showing comments===
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
----
===Language support===
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
----
=== 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
----
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
~& this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
----
=== 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
----
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
----
Revision [9910]
Edited on 2005-07-09 14:03:06 by JsnX [Added --> Exclude certain CamelCase words from formatting]Additions:
=====Suggestion Box=====
{{lastedit show="3"}}
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
~-SuggestionsArchive for resolved suggestions
**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
>>{{feedback}}
::c::
----
===Exclude certain CamelCase words from formatting===
Popular Scottish surnames such as McKenna are wrongly being interpreted as WikiNames - is there any way to prevent that happening?
-- host86-133-223-194.range86-133.btcentralplus.com (2005-07-09 13:23:06)
How about something like a lookup table where WikiAdmins enter a list of words that will be ignored for formatting on all pages? -- JsnX
----
===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]].
----
===Import WikiPedia database===
How can I import the Wikipedia database? I don't want to use MediaWiki. Any idea?
~& Sorry, there is no filter yet to convert MediaWiki content to WikkaWiki content, but it sounds like a nice feature suggestion. After all MW markup is quite stable... This said, do you //really// mean you want to import the actual Wikipedia database and have it run on a different wiki engine? -- DarTar
~& Yes, i want. It would be great. Maybe other sites will change to WikkaWikki when they can import a MediaWiki databse.
----
===Note on edit, mandatory field===
I think it would be a good ide to let the administrator choose if the field is mandatory.
If it is, the form doesn't submit until there is content into it, and it should warn too with an alertbox.
Only a little bit of PHP is necessary, the big part is in JS, if i don't make any mistake...
--SamuelDr
----
===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
----
===Order of comments===
WikiJochen made a comment on my page that would like to see the latest comment shown first and not last. --NilsLindenberg
----
===Own comments editing===
I think that it would be a good option to allow one to edit its own comments, sometimes, I make mistakes when commenting, typos or language things (i'm a foreigner) and I want my texts to all look clean.
Currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, I'm lazy, just like many other people. --SamuelDr
~&SamuelDr, this is a good suggestion. I've had the same thought about needing the ability to edit comments. The problem with "copy and then delete" is this can only be done until someone else comments. Otherwise the comments will be out of order. Consider it on the todo list for a future release. -- JsnX
----
===Google Sitemap===
See [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --NilsLindenberg
~&Apparently Google uses **URLs** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our URLs inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). The only case I could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so Google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell Google to **not** follow the links on that page, Google can find orphan pages as well. So I don't really see how this could actually help, given the "lack of structure" of a wiki. --JavaWoman
----
===versioning of attachments===
//copied from a comment from AttachmentInfo --NilsLindenberg//
Does Wikka support versioning of attachments?
IMHO a good idea. --Nils
~&See allso WikkaLogicalDataModel --JavaWoman
----
===Making PageIndex go faster===
By default PageIndex uses $this->""LoadAllPages""() which reads your **whole site** into one array. If you would use a new function like $this->""LoadAllPagesInfo""() you will get the same info but without the 'body' content. This should speed up PageIndex a bit on larger sites...
1) Find in ##wikka.php## (Around 33%)
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
And replace it with:
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }
function LoadAllPagesInfo() { return $this->LoadAll("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
1) Find in ##actions/pageindex.php## (top)
%%(php)if ($pages = $this->LoadAllPages())%%
And replace it with:
%%(php)if ($pages = $this->LoadAllPagesInfo())%%
1) Same trick as in (2) can be done in ##actions/mypages.php##...
-- OnegWR
~&See the first item on WikkaOptimization, too --NilsLindenberg
----
===Generate ID in forms; allow class===
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made it into a semi-spec.//
Every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
~-accept an //optional// parameter specifying an id and - if specified - use this to generate an id attribute
~-if the parameter is not specified, generate one using some algorithm to ensure it will be unique on the page (possibly using all provided parameters to create a hash, supplemented with a sequence number); only problem is this id might change when adding / inserting another form into a page but that could be worked around by actually specifying an id.
In addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). So the ##""FormOpen()""## method should also:
~-accept an //optional// parameter specifying a class and - if specified - use this to generate a class attribute (and no class attribute if not specified).
--JavaWoman
~&An implementation for this is now coded and tested (and will soon be added as a beta feature on this site). See AdvancedFormOpen and GenerateUniqueId for the code --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-adress 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
----
===Single-click restore of previous versions===
//copied from WikkaBugs - this is a suggestion, not a bug --NilsLindenberg//
Single-click restore of previous versions (without copying/pasting). -Sam
~& ''Yes, this will be implemented at some point.'' - JsnX
~~&I should point out that there is an alternative to copying/pasting.
~~~& Go to the revisions page.
~~~& Click the date and time link that you would like to revert back to.
~~~& Click the 'Re-edit this old revision' button.
~~~& Click the 'Store' button.
----
===""%%"" in code blocks: a possible workaround===
In any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. While our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own Wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
The only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. There are two problems with this:
~1)Users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)Code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
Copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. If any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of Wikka). That leaves us with finding an escape method that's easy for users to implement.
There are two requirements for an "escaped" ""%%"" then:
~1)Easy to remember and apply by end users
~1)Not (not likely) part of the syntax of any language
One option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. A good candidate might be **DOUBLE_PERCENT** - it's easy enough to remember and easy to implement:
The formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to GeSHI for rendering; the grab code handler could just as easily replace it before making the code block available for download.
Thoughts anyone?
--JavaWoman
~&It's a good idea, but: You are sure DOUBLE_PERCENT is no reserved word in a language? Or unlikely to comme up in a code? --NilsLindenberg
~~&Try googling for 'DOUBLE_PERCENT': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). It's certainly not a reserved word in any of the languages GeSHi currently has support for, going by the language files it comes with. There's no way to be 100% certain but it seems to be a pretty safe bet. --JavaWoman
----
===Preview===
A doubleclick on a page in the preview should lead to "re-edit" of the text. --NilsLindenberg
~& Good point, agreed -- DarTar
Another point: The access-key for "re-edit" is alt+p at the moment. Wouldn't alt+e be more logic? --NilsLindenberg
----
===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
----
===Color Formatting===
The current color formatting isn't very wiki like. Altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
%%^<color> text^%%
this regex syntax is lifted from a ""UseMod"" Wiki patch.
%%s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
I am by NO means a regex expert, but it seems that this should do the deal... I'm just not sure where it would go. By using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--MonstoBrukes
~&Please take a look at WikkaExtensibleMarkup --NilsLindenberg
~~&I looked at it. what point specifically did you intend i take from it?
~~~& JavaWoman had a proposal about a color-markup there. I think its the better place for the discussion. The recognition of markup is done in the formatter (formatters/wakka.php). I am no expert for regexps too, but wouldn't the first or catch too much? --NilsLindenberg
----
===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
----
===Documentation===
copied to DocumentationDiscussion. --NilsLindenberg
----
===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
----
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
~~& 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
----
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
----
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
----
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) open a ##/raw## version of the page;
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
~1) open a text editor;
~1) copy the code block;
~1) paste it in the text editor;
~1) save the file.
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
%%
include ('Wakka.class.php');
%%
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
----
===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
----
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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?
--GregorLindner
----
===Signature===
//(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)//
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
----
=== 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
----
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
=== Image dimensions ===
The [[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
----
===Clearing ACLs===
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
----
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
=== RSS options ===
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
----
=== 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;
%%
----
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
=== 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
----
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
===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
----
===Local links===
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--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''
----
===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
----
===Online editing of mindmaps would be great===
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
----
===How to format code to get two % characters without space together?===
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
----
===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
----
===showing comments===
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
----
===Language support===
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
----
=== 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
----
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
~& this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
----
=== 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
----
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
----
{{lastedit show="3"}}
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
~-SuggestionsArchive for resolved suggestions
**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
>>{{feedback}}
::c::
----
===Exclude certain CamelCase words from formatting===
Popular Scottish surnames such as McKenna are wrongly being interpreted as WikiNames - is there any way to prevent that happening?
-- host86-133-223-194.range86-133.btcentralplus.com (2005-07-09 13:23:06)
How about something like a lookup table where WikiAdmins enter a list of words that will be ignored for formatting on all pages? -- JsnX
----
===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]].
----
===Import WikiPedia database===
How can I import the Wikipedia database? I don't want to use MediaWiki. Any idea?
~& Sorry, there is no filter yet to convert MediaWiki content to WikkaWiki content, but it sounds like a nice feature suggestion. After all MW markup is quite stable... This said, do you //really// mean you want to import the actual Wikipedia database and have it run on a different wiki engine? -- DarTar
~& Yes, i want. It would be great. Maybe other sites will change to WikkaWikki when they can import a MediaWiki databse.
----
===Note on edit, mandatory field===
I think it would be a good ide to let the administrator choose if the field is mandatory.
If it is, the form doesn't submit until there is content into it, and it should warn too with an alertbox.
Only a little bit of PHP is necessary, the big part is in JS, if i don't make any mistake...
--SamuelDr
----
===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
----
===Order of comments===
WikiJochen made a comment on my page that would like to see the latest comment shown first and not last. --NilsLindenberg
----
===Own comments editing===
I think that it would be a good option to allow one to edit its own comments, sometimes, I make mistakes when commenting, typos or language things (i'm a foreigner) and I want my texts to all look clean.
Currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, I'm lazy, just like many other people. --SamuelDr
~&SamuelDr, this is a good suggestion. I've had the same thought about needing the ability to edit comments. The problem with "copy and then delete" is this can only be done until someone else comments. Otherwise the comments will be out of order. Consider it on the todo list for a future release. -- JsnX
----
===Google Sitemap===
See [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --NilsLindenberg
~&Apparently Google uses **URLs** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our URLs inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). The only case I could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so Google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell Google to **not** follow the links on that page, Google can find orphan pages as well. So I don't really see how this could actually help, given the "lack of structure" of a wiki. --JavaWoman
----
===versioning of attachments===
//copied from a comment from AttachmentInfo --NilsLindenberg//
Does Wikka support versioning of attachments?
IMHO a good idea. --Nils
~&See allso WikkaLogicalDataModel --JavaWoman
----
===Making PageIndex go faster===
By default PageIndex uses $this->""LoadAllPages""() which reads your **whole site** into one array. If you would use a new function like $this->""LoadAllPagesInfo""() you will get the same info but without the 'body' content. This should speed up PageIndex a bit on larger sites...
1) Find in ##wikka.php## (Around 33%)
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
And replace it with:
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }
function LoadAllPagesInfo() { return $this->LoadAll("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
1) Find in ##actions/pageindex.php## (top)
%%(php)if ($pages = $this->LoadAllPages())%%
And replace it with:
%%(php)if ($pages = $this->LoadAllPagesInfo())%%
1) Same trick as in (2) can be done in ##actions/mypages.php##...
-- OnegWR
~&See the first item on WikkaOptimization, too --NilsLindenberg
----
===Generate ID in forms; allow class===
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made it into a semi-spec.//
Every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
~-accept an //optional// parameter specifying an id and - if specified - use this to generate an id attribute
~-if the parameter is not specified, generate one using some algorithm to ensure it will be unique on the page (possibly using all provided parameters to create a hash, supplemented with a sequence number); only problem is this id might change when adding / inserting another form into a page but that could be worked around by actually specifying an id.
In addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). So the ##""FormOpen()""## method should also:
~-accept an //optional// parameter specifying a class and - if specified - use this to generate a class attribute (and no class attribute if not specified).
--JavaWoman
~&An implementation for this is now coded and tested (and will soon be added as a beta feature on this site). See AdvancedFormOpen and GenerateUniqueId for the code --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-adress 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
----
===Single-click restore of previous versions===
//copied from WikkaBugs - this is a suggestion, not a bug --NilsLindenberg//
Single-click restore of previous versions (without copying/pasting). -Sam
~& ''Yes, this will be implemented at some point.'' - JsnX
~~&I should point out that there is an alternative to copying/pasting.
~~~& Go to the revisions page.
~~~& Click the date and time link that you would like to revert back to.
~~~& Click the 'Re-edit this old revision' button.
~~~& Click the 'Store' button.
----
===""%%"" in code blocks: a possible workaround===
In any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. While our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own Wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
The only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. There are two problems with this:
~1)Users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)Code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
Copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. If any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of Wikka). That leaves us with finding an escape method that's easy for users to implement.
There are two requirements for an "escaped" ""%%"" then:
~1)Easy to remember and apply by end users
~1)Not (not likely) part of the syntax of any language
One option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. A good candidate might be **DOUBLE_PERCENT** - it's easy enough to remember and easy to implement:
The formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to GeSHI for rendering; the grab code handler could just as easily replace it before making the code block available for download.
Thoughts anyone?
--JavaWoman
~&It's a good idea, but: You are sure DOUBLE_PERCENT is no reserved word in a language? Or unlikely to comme up in a code? --NilsLindenberg
~~&Try googling for 'DOUBLE_PERCENT': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). It's certainly not a reserved word in any of the languages GeSHi currently has support for, going by the language files it comes with. There's no way to be 100% certain but it seems to be a pretty safe bet. --JavaWoman
----
===Preview===
A doubleclick on a page in the preview should lead to "re-edit" of the text. --NilsLindenberg
~& Good point, agreed -- DarTar
Another point: The access-key for "re-edit" is alt+p at the moment. Wouldn't alt+e be more logic? --NilsLindenberg
----
===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
----
===Color Formatting===
The current color formatting isn't very wiki like. Altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
%%^<color> text^%%
this regex syntax is lifted from a ""UseMod"" Wiki patch.
%%s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
I am by NO means a regex expert, but it seems that this should do the deal... I'm just not sure where it would go. By using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--MonstoBrukes
~&Please take a look at WikkaExtensibleMarkup --NilsLindenberg
~~&I looked at it. what point specifically did you intend i take from it?
~~~& JavaWoman had a proposal about a color-markup there. I think its the better place for the discussion. The recognition of markup is done in the formatter (formatters/wakka.php). I am no expert for regexps too, but wouldn't the first or catch too much? --NilsLindenberg
----
===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
----
===Documentation===
copied to DocumentationDiscussion. --NilsLindenberg
----
===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
----
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
~~& 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
----
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
----
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
----
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) open a ##/raw## version of the page;
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
~1) open a text editor;
~1) copy the code block;
~1) paste it in the text editor;
~1) save the file.
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
%%
include ('Wakka.class.php');
%%
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
----
===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
----
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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?
--GregorLindner
----
===Signature===
//(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)//
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
----
=== 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
----
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
=== Image dimensions ===
The [[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
----
===Clearing ACLs===
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
----
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
=== RSS options ===
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
----
=== 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;
%%
----
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
=== 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
----
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
===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
----
===Local links===
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--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''
----
===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
----
===Online editing of mindmaps would be great===
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
----
===How to format code to get two % characters without space together?===
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
----
===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
----
===showing comments===
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
----
===Language support===
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
----
=== 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
----
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
~& this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
----
=== 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
----
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
----
Deletions:
{{lastedit show="3"}}
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
~-SuggestionsArchive for resolved suggestions
**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
>>{{feedback}}
::c::
----
===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]].
----
===Import WikiPedia database===
How can I import the Wikipedia database? I don't want to use MediaWiki. Any idea?
~& Sorry, there is no filter yet to convert MediaWiki content to WikkaWiki content, but it sounds like a nice feature suggestion. After all MW markup is quite stable... This said, do you //really// mean you want to import the actual Wikipedia database and have it run on a different wiki engine? -- DarTar
~& Yes, i want. It would be great. Maybe other sites will change to WikkaWikki when they can import a MediaWiki databse.
----
===Note on edit, mandatory field===
I think it would be a good ide to let the administrator choose if the field is mandatory.
If it is, the form doesn't submit until there is content into it, and it should warn too with an alertbox.
Only a little bit of PHP is necessary, the big part is in JS, if i don't make any mistake...
--SamuelDr
----
===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
----
===Order of comments===
WikiJochen made a comment on my page that would like to see the latest comment shown first and not last. --NilsLindenberg
----
===Own comments editing===
I think that it would be a good option to allow one to edit its own comments, sometimes, I make mistakes when commenting, typos or language things (i'm a foreigner) and I want my texts to all look clean.
Currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, I'm lazy, just like many other people. --SamuelDr
~&SamuelDr, this is a good suggestion. I've had the same thought about needing the ability to edit comments. The problem with "copy and then delete" is this can only be done until someone else comments. Otherwise the comments will be out of order. Consider it on the todo list for a future release. -- JsnX
----
===Google Sitemap===
See [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --NilsLindenberg
~&Apparently Google uses **URLs** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our URLs inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). The only case I could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so Google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell Google to **not** follow the links on that page, Google can find orphan pages as well. So I don't really see how this could actually help, given the "lack of structure" of a wiki. --JavaWoman
----
===versioning of attachments===
//copied from a comment from AttachmentInfo --NilsLindenberg//
Does Wikka support versioning of attachments?
IMHO a good idea. --Nils
~&See allso WikkaLogicalDataModel --JavaWoman
----
===Making PageIndex go faster===
By default PageIndex uses $this->""LoadAllPages""() which reads your **whole site** into one array. If you would use a new function like $this->""LoadAllPagesInfo""() you will get the same info but without the 'body' content. This should speed up PageIndex a bit on larger sites...
1) Find in ##wikka.php## (Around 33%)
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
And replace it with:
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }
function LoadAllPagesInfo() { return $this->LoadAll("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
1) Find in ##actions/pageindex.php## (top)
%%(php)if ($pages = $this->LoadAllPages())%%
And replace it with:
%%(php)if ($pages = $this->LoadAllPagesInfo())%%
1) Same trick as in (2) can be done in ##actions/mypages.php##...
-- OnegWR
~&See the first item on WikkaOptimization, too --NilsLindenberg
----
===Generate ID in forms; allow class===
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made it into a semi-spec.//
Every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
~-accept an //optional// parameter specifying an id and - if specified - use this to generate an id attribute
~-if the parameter is not specified, generate one using some algorithm to ensure it will be unique on the page (possibly using all provided parameters to create a hash, supplemented with a sequence number); only problem is this id might change when adding / inserting another form into a page but that could be worked around by actually specifying an id.
In addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). So the ##""FormOpen()""## method should also:
~-accept an //optional// parameter specifying a class and - if specified - use this to generate a class attribute (and no class attribute if not specified).
--JavaWoman
~&An implementation for this is now coded and tested (and will soon be added as a beta feature on this site). See AdvancedFormOpen and GenerateUniqueId for the code --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-adress 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
----
===Single-click restore of previous versions===
//copied from WikkaBugs - this is a suggestion, not a bug --NilsLindenberg//
Single-click restore of previous versions (without copying/pasting). -Sam
~& ''Yes, this will be implemented at some point.'' - JsnX
~~&I should point out that there is an alternative to copying/pasting.
~~~& Go to the revisions page.
~~~& Click the date and time link that you would like to revert back to.
~~~& Click the 'Re-edit this old revision' button.
~~~& Click the 'Store' button.
----
===""%%"" in code blocks: a possible workaround===
In any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. While our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own Wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
The only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. There are two problems with this:
~1)Users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)Code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
Copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. If any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of Wikka). That leaves us with finding an escape method that's easy for users to implement.
There are two requirements for an "escaped" ""%%"" then:
~1)Easy to remember and apply by end users
~1)Not (not likely) part of the syntax of any language
One option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. A good candidate might be **DOUBLE_PERCENT** - it's easy enough to remember and easy to implement:
The formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to GeSHI for rendering; the grab code handler could just as easily replace it before making the code block available for download.
Thoughts anyone?
--JavaWoman
~&It's a good idea, but: You are sure DOUBLE_PERCENT is no reserved word in a language? Or unlikely to comme up in a code? --NilsLindenberg
~~&Try googling for 'DOUBLE_PERCENT': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). It's certainly not a reserved word in any of the languages GeSHi currently has support for, going by the language files it comes with. There's no way to be 100% certain but it seems to be a pretty safe bet. --JavaWoman
----
===Preview===
A doubleclick on a page in the preview should lead to "re-edit" of the text. --NilsLindenberg
~& Good point, agreed -- DarTar
Another point: The access-key for "re-edit" is alt+p at the moment. Wouldn't alt+e be more logic? --NilsLindenberg
----
===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
----
===Color Formatting===
The current color formatting isn't very wiki like. Altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
%%^<color> text^%%
this regex syntax is lifted from a ""UseMod"" Wiki patch.
%%s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
I am by NO means a regex expert, but it seems that this should do the deal... I'm just not sure where it would go. By using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--MonstoBrukes
~&Please take a look at WikkaExtensibleMarkup --NilsLindenberg
~~&I looked at it. what point specifically did you intend i take from it?
~~~& JavaWoman had a proposal about a color-markup there. I think its the better place for the discussion. The recognition of markup is done in the formatter (formatters/wakka.php). I am no expert for regexps too, but wouldn't the first or catch too much? --NilsLindenberg
----
===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
----
===Documentation===
copied to DocumentationDiscussion. --NilsLindenberg
----
===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
----
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
~~& 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
----
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
----
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
----
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) open a ##/raw## version of the page;
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
~1) open a text editor;
~1) copy the code block;
~1) paste it in the text editor;
~1) save the file.
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
%%
include ('Wakka.class.php');
%%
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
----
===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
----
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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?
--GregorLindner
----
===Signature===
//(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)//
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
----
=== 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
----
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
=== Image dimensions ===
The [[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
----
===Clearing ACLs===
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
----
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
=== RSS options ===
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
----
=== 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;
%%
----
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
=== 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
----
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
===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
----
===Local links===
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--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''
----
===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
----
===Online editing of mindmaps would be great===
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
----
===How to format code to get two % characters without space together?===
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
----
===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
----
===showing comments===
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
----
===Language support===
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
----
=== 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
----
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
~& this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
----
=== 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
----
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
----
Additions:
===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 ?
//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 ?
No Differences
No Differences
Additions:
===Improving Wikka===
Deletions:
Additions:
===Improving Wikka==
A nice list of suggestions can be found at: [[http://smackaroo.net/by-blood-and-bone/MyNextWiki By Blood and bone]].
A nice list of suggestions can be found at: [[http://smackaroo.net/by-blood-and-bone/MyNextWiki By Blood and bone]].
Revision [9679]
Edited on 2005-06-28 09:16:47 by 195.145.211.199 [suggestions for wikka improvement]Additions:
How can I import the Wikipedia database? I don't want to use MediaWiki. Any idea?
~& Yes, i want. It would be great. Maybe other sites will change to WikkaWikki when they can import a MediaWiki databse.
~& Yes, i want. It would be great. Maybe other sites will change to WikkaWikki when they can import a MediaWiki databse.
Deletions:
Additions:
~& Sorry, there is no filter yet to convert MediaWiki content to WikkaWiki content, but it sounds like a nice feature suggestion. After all MW markup is quite stable... This said, do you //really// mean you want to import the actual Wikipedia database and have it run on a different wiki engine? -- DarTar
Deletions:
Additions:
===Import WikiPedia database===
~- Sorry, there is no filter yet to convert MediaWiki content to WikkaWiki content, but it sounds like a nice feature suggestion. After all MW markup is quite stable... -- DarTar
~- Sorry, there is no filter yet to convert MediaWiki content to WikkaWiki content, but it sounds like a nice feature suggestion. After all MW markup is quite stable... -- DarTar
Deletions:
No Differences
No Differences
Additions:
===Import WikiPedia database====
How can I import the Wikipedia database? I don't want to use Wikimedia. Any idea?
How can I import the Wikipedia database? I don't want to use Wikimedia. Any idea?
Additions:
--SamuelDr
Additions:
===Note on edit, mandatory field===
I think it would be a good ide to let the administrator choose if the field is mandatory.
If it is, the form doesn't submit until there is content into it, and it should warn too with an alertbox.
Only a little bit of PHP is necessary, the big part is in JS, if i don't make any mistake...
I think it would be a good ide to let the administrator choose if the field is mandatory.
If it is, the form doesn't submit until there is content into it, and it should warn too with an alertbox.
Only a little bit of PHP is necessary, the big part is in JS, if i don't make any mistake...
Additions:
~&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
Additions:
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
This is the current version:
// usersettings.php current line 130
The first one works for me. Is there a problem with security in using that version?
// usersettings.php line 130 fixed
This is the current version:
// usersettings.php current line 130
The first one works for me. Is there a problem with security in using that version?
Deletions:
// line 130
to this code
// current line 130
The first one works for me, but what I think is the current version of usersettings.php does not.
Additions:
===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? Or was there a change in usersettings.php that changed this code
// line 130
if ($existingUser["password"] == md5($_POST["password"]) || $existingUser["password"]==$_POST["password"])
to this code
// current line 130
if ($existingUser["password"] == md5($_POST["password"]))
The first one works for me, but what I think is the current version of usersettings.php does not.
-CharlotteFischer
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? Or was there a change in usersettings.php that changed this code
// line 130
if ($existingUser["password"] == md5($_POST["password"]) || $existingUser["password"]==$_POST["password"])
to this code
// current line 130
if ($existingUser["password"] == md5($_POST["password"]))
The first one works for me, but what I think is the current version of usersettings.php does not.
-CharlotteFischer
Revision [9599]
Edited on 2005-06-24 19:08:21 by NilsLindenberg [added WikiJochens Porposal for comment-order]Additions:
===Order of comments===
WikiJochen made a comment on my page that would like to see the latest comment shown first and not last. --NilsLindenberg
WikiJochen made a comment on my page that would like to see the latest comment shown first and not last. --NilsLindenberg
Additions:
~&SamuelDr, this is a good suggestion. I've had the same thought about needing the ability to edit comments. The problem with "copy and then delete" is this can only be done until someone else comments. Otherwise the comments will be out of order. Consider it on the todo list for a future release. -- JsnX
Additions:
Currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, I'm lazy, just like many other people. --SamuelDr
===Other method to attach files===
===Other method to attach files===
Deletions:
==Other method to attach files==
Additions:
===Own comments editing===
I think that it would be a good option to allow one to edit its own comments, sometimes, I make mistakes when commenting, typos or language things (i'm a foreigner) and I want my texts to all look clean.
Currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, I'm lazy, just like many other people.
I think that it would be a good option to allow one to edit its own comments, sometimes, I make mistakes when commenting, typos or language things (i'm a foreigner) and I want my texts to all look clean.
Currently, we can still copy and then delete the comment, but it is a pain to do so... sorry, I'm lazy, just like many other people.
Revision [9186]
Edited on 2005-06-13 08:00:37 by JavaWoman [Mod_rewrite moved here from WikkaBugs; category removed]Additions:
===Mod_rewrite===
take a look at FaviconDotIco and RobotsDotTxt
take a look at FaviconDotIco and RobotsDotTxt
Deletions:
Additions:
~-[[TableofcontentsAction Table of contents (TOC)]]
Deletions:
Additions:
~-[[WikkaFilters Wikka Exporting/Importing]], [[WikkaToPdf PDF-Export]]
**see also:**
>>{{feedback}}
**see also:**
>>{{feedback}}
Deletions:
~-[[WikkaToPdf PDF-Export]]
>>
{{feedback}}
Additions:
~&See allso WikkaLogicalDataModel --JavaWoman
Additions:
~&Apparently Google uses **URLs** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our URLs inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). The only case I could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so Google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell Google to **not** follow the links on that page, Google can find orphan pages as well. So I don't really see how this could actually help, given the "lack of structure" of a wiki. --JavaWoman
Deletions:
Additions:
See [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --NilsLindenberg
~-&Apparently Google uses **URLs** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our URLs inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). The only case I could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so Google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell Google to **not** follow the links on that page, Google can find orphan pages as well. So I don't really see how this could actually help, given the "lack of structure" of a wiki. --JavaWoman
~-&Apparently Google uses **URLs** to deduce the structure of your site in order to crawl it more efficiently (if it uses the information at all, which is not guaranteed); but our URLs inherently do not map to any structure (that's because a wiki essentially is a network, not a hierarchy). The only case I could see where it might possibly help is with orphan pages - in other words pages that are not linked to from any other page - so Google can find them; but then again, if you have a link to to an orphan pages page somewhere and you don't tell Google to **not** follow the links on that page, Google can find orphan pages as well. So I don't really see how this could actually help, given the "lack of structure" of a wiki. --JavaWoman
Deletions:
Additions:
===Google Sitemap===
See [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --NilsLindenberg
See [[https://www.google.com/webmasters/sitemaps/docs/en/about.html here]] pushing the sturcture and changes of wikka to google could be an interesting (optional) feature. --NilsLindenberg
Additions:
//copied from a comment from AttachmentInfo --NilsLindenberg//
Deletions:
Additions:
===versioning of attachments===
//copied from a comment from FileActionInfo --NilsLindenberg//
Does Wikka support versioning of attachments?
IMHO a good idea. --Nils
~&See the first item on WikkaOptimization, too --NilsLindenberg
//copied from a comment from FileActionInfo --NilsLindenberg//
Does Wikka support versioning of attachments?
IMHO a good idea. --Nils
~&See the first item on WikkaOptimization, too --NilsLindenberg
Additions:
CategoryDevelopmentSuggestions
Deletions:
Revision [8520]
Edited on 2005-05-27 19:20:02 by JavaWoman [removing link to AdvancedFormatter; adding links to AdvancedFormOpen and GeneratingUniqueId]Additions:
~&An implementation for this is now coded and tested (and will soon be added as a beta feature on this site). See AdvancedFormOpen and GenerateUniqueId for the code --JavaWoman
Deletions:
Additions:
1) Find in ##wikka.php## (Around 33%)
Deletions:
Additions:
===Making PageIndex go faster===
By default PageIndex uses $this->""LoadAllPages""() which reads your **whole site** into one array. If you would use a new function like $this->""LoadAllPagesInfo""() you will get the same info but without the 'body' content. This should speed up PageIndex a bit on larger sites...
1) Find in ##wikka.php## (around 33%)
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
And replace it with:
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }
function LoadAllPagesInfo() { return $this->LoadAll("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
1) Find in ##actions/pageindex.php## (top)
%%(php)if ($pages = $this->LoadAllPages())%%
And replace it with:
%%(php)if ($pages = $this->LoadAllPagesInfo())%%
1) Same trick as in (2) can be done in ##actions/mypages.php##...
-- OnegWR
By default PageIndex uses $this->""LoadAllPages""() which reads your **whole site** into one array. If you would use a new function like $this->""LoadAllPagesInfo""() you will get the same info but without the 'body' content. This should speed up PageIndex a bit on larger sites...
1) Find in ##wikka.php## (around 33%)
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
And replace it with:
%%(php) function LoadAllPages() { return $this->LoadAll("select * from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }
function LoadAllPagesInfo() { return $this->LoadAll("select id,tag,time,owner,user,latest,note from ".$this->config["table_prefix"]."pages where latest = 'Y' order by tag"); }%%
1) Find in ##actions/pageindex.php## (top)
%%(php)if ($pages = $this->LoadAllPages())%%
And replace it with:
%%(php)if ($pages = $this->LoadAllPagesInfo())%%
1) Same trick as in (2) can be done in ##actions/mypages.php##...
-- OnegWR
Additions:
<<See: AdvancedFormatter<<::c::
Deletions:
Additions:
<<See: AdvancedFortmatter<<::c::
Revision [8437]
Edited on 2005-05-24 17:53:01 by OnegWR [proposed AddLinkAction as fix for "Easy way of adding links"]Additions:
-- 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
~& 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
Deletions:
Additions:
~-[[WikkaWorkarounds Workarounds for uncommon problems]]
Deletions:
Revision [8417]
Edited on 2005-05-24 11:46:23 by NilsLindenberg [copied stuff to DocumentationDiscussion]Additions:
copied to DocumentationDiscussion. --NilsLindenberg
Deletions:
~&You can add usernames to the admin-list, if you don't want to share the admin-account. Specify multiple wiki names separated by commas e.g: JsnX, HendrikMans, CoolJoeAdmin in the wikka.config.php in "admin-users" (see ConfigurationOptions). Admins can see, edit and delete any page, even if they are set to private.
Searching for "Admin Features" yeilds over 100 entries. There's nothing in CategoryDocumentation detailing admin features, and the page WikkaFeatures mentions several admin features that have neither further explanation nor links.
~&Will be changed, but not today :)
On top of all this, searching ACL reveals **one page** that just mentions ACL more in passing. The page with Category instructions is also a little under informed. You'd think that after following 2 step instructions that it'd work.
~&I think you mean ACLInfo and WikiCategory? If you have questions about a documentation-page, please leave a comment about that on the page. We can only make it better if we know what is not understandable. Remember that this is a wiki :)
This page is another example. I started reading it the other night looking for something specific but by the time i finished reading it, i had about 6 different things i felt like commenting on. It's so long tho that i felt my comments would be missed so i didn't bother. Rather than piled on one after the other, after a certain age, each of these subjects should be broken off to their own page in a CategorySuggestionBox and listed here. (I mean this is a wiki and space isn't necessarily at a premium) This would make it easier to find and contribute to a specific topic. If a search produces this page as a result, the initial impression is that the search was really messed up hitting "suggestionbox" with my search terms.
Anyway... the suggestion? Organizing documentation should be THE priority. This site looks quite nice. It's a shining example of how wikka works when beat into perfect shape. But the site I installed looked and acted nothing like this...
~&Yes, we can and should organize the documentation better (and some other parts of this wiki). We will move it to a new subdomain (see DocumentationLanguageLinking) and after that we can bring it in better shape. But don't forget that this is a wiki and you have the right to participate :) --NilsLindenberg
~~&Does this mean that if I go ahead and make a "Category Suggestion Box" and split this pages into seperate doco's that it won't step on people's toes? I think this would be good and don't mind doing that bit of work - but don't want to annoy too many people [espec. seeing as I am quite the newbie here...] -- KiltanneN
~~~&I say; simply start and wait for the reactions. Thats how I do it, most of the time ;) --NilsLindenberg
Revision [8323]
Edited on 2005-05-19 21:09:31 by c83-251-117-195.bredband.comhem.se [copied stuff to DocumentationDiscussion]Additions:
backlinks.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;
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;
Additions:
=====Suggestion Box=====
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
~-SuggestionsArchive for resolved suggestions
**Issues often asked for**
~-[[CategorySystemOverhaul Categories]]
~-[[DateAndTimeFormat Date/Time]]
~-[[WikkaFilters Wikka Exporting/Importing]]
~-[[WikkaInternationalization Internationalization/Localisation]]
~-[[WikkaOptimization Optimization]]
~-[[WikkaToPdf PDF-Export]]
~-[[SectionEditing Section Editing]]
~-[[WikkaSpamFighting Spam (and related issues)]]
~-[[TableofcontentsAction Table of content (TOC)]]
~-[[WikkaTables Tables]]
~-[[WikkaFolksonomy (Technorati) tags & related]]
~-TemplateSystem
~-UserMap
~-[[WikkaWorkarounds Workarounds for specific platforms]]
===Generate ID in forms; allow class===
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made it into a semi-spec.//
Every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
In addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). So the ##""FormOpen()""## method should also:
--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");
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-adress 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
===Single-click restore of previous versions===
//copied from WikkaBugs - this is a suggestion, not a bug --NilsLindenberg//
Single-click restore of previous versions (without copying/pasting). -Sam
~& ''Yes, this will be implemented at some point.'' - JsnX
~~&I should point out that there is an alternative to copying/pasting.
~~~& Go to the revisions page.
~~~& Click the date and time link that you would like to revert back to.
~~~& Click the 'Re-edit this old revision' button.
~~~& Click the 'Store' button.
In any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. While our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own Wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
The only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. There are two problems with this:
~1)Users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)Code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
Copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. If any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of Wikka). That leaves us with finding an escape method that's easy for users to implement.
There are two requirements for an "escaped" ""%%"" then:
~1)Easy to remember and apply by end users
~1)Not (not likely) part of the syntax of any language
One option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. A good candidate might be **DOUBLE_PERCENT** - it's easy enough to remember and easy to implement:
The formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to GeSHI for rendering; the grab code handler could just as easily replace it before making the code block available for download.
Thoughts anyone?
--JavaWoman
~&It's a good idea, but: You are sure DOUBLE_PERCENT is no reserved word in a language? Or unlikely to comme up in a code? --NilsLindenberg
~~&Try googling for 'DOUBLE_PERCENT': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). It's certainly not a reserved word in any of the languages GeSHi currently has support for, going by the language files it comes with. There's no way to be 100% certain but it seems to be a pretty safe bet. --JavaWoman
===Preview===
A doubleclick on a page in the preview should lead to "re-edit" of the text. --NilsLindenberg
~& Good point, agreed -- DarTar
Another point: The access-key for "re-edit" is alt+p at the moment. Wouldn't alt+e be more logic? --NilsLindenberg
===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
===Color Formatting===
The current color formatting isn't very wiki like. Altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
this regex syntax is lifted from a ""UseMod"" Wiki patch.
%%s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
I am by NO means a regex expert, but it seems that this should do the deal... I'm just not sure where it would go. By using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--MonstoBrukes
~&Please take a look at WikkaExtensibleMarkup --NilsLindenberg
~~&I looked at it. what point specifically did you intend i take from it?
~~~& JavaWoman had a proposal about a color-markup there. I think its the better place for the discussion. The recognition of markup is done in the formatter (formatters/wakka.php). I am no expert for regexps too, but wouldn't the first or catch too much? --NilsLindenberg
===Integration into existing site===
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
===Documentation===
Documentation on the site here seems . . . fragmented I think is the best word. Admin features are the example i'll use cuz it was my big hurdle. At this point I've only been able to find that the account created at install is THE admin, and as site owner i should give access to that account to the people that i want to admin the site. Is there more to it than this?
~&You can add usernames to the admin-list, if you don't want to share the admin-account. Specify multiple wiki names separated by commas e.g: JsnX, HendrikMans, CoolJoeAdmin in the wikka.config.php in "admin-users" (see ConfigurationOptions). Admins can see, edit and delete any page, even if they are set to private.
Searching for "Admin Features" yeilds over 100 entries. There's nothing in CategoryDocumentation detailing admin features, and the page WikkaFeatures mentions several admin features that have neither further explanation nor links.
~&Will be changed, but not today :)
On top of all this, searching ACL reveals **one page** that just mentions ACL more in passing. The page with Category instructions is also a little under informed. You'd think that after following 2 step instructions that it'd work.
~&I think you mean ACLInfo and WikiCategory? If you have questions about a documentation-page, please leave a comment about that on the page. We can only make it better if we know what is not understandable. Remember that this is a wiki :)
This page is another example. I started reading it the other night looking for something specific but by the time i finished reading it, i had about 6 different things i felt like commenting on. It's so long tho that i felt my comments would be missed so i didn't bother. Rather than piled on one after the other, after a certain age, each of these subjects should be broken off to their own page in a CategorySuggestionBox and listed here. (I mean this is a wiki and space isn't necessarily at a premium) This would make it easier to find and contribute to a specific topic. If a search produces this page as a result, the initial impression is that the search was really messed up hitting "suggestionbox" with my search terms.
Anyway... the suggestion? Organizing documentation should be THE priority. This site looks quite nice. It's a shining example of how wikka works when beat into perfect shape. But the site I installed looked and acted nothing like this...
~&Yes, we can and should organize the documentation better (and some other parts of this wiki). We will move it to a new subdomain (see DocumentationLanguageLinking) and after that we can bring it in better shape. But don't forget that this is a wiki and you have the right to participate :) --NilsLindenberg
~~&Does this mean that if I go ahead and make a "Category Suggestion Box" and split this pages into seperate doco's that it won't step on people's toes? I think this would be good and don't mind doing that bit of work - but don't want to annoy too many people [espec. seeing as I am quite the newbie here...] -- KiltanneN
~~~&I say; simply start and wait for the reactions. Thats how I do it, most of the time ;) --NilsLindenberg
===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:
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
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
===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
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
~~& 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
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
===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"))
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
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
include ('Wakka.class.php');
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
===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):
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
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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:
~&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
Is there a way to include a target in a link, so that the Link opens in a new window?
--GregorLindner
===Signature===
//(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)//
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
=== 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
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-- KarmaTester (2005-01-26 06:52:07)
=== Image dimensions ===
The [[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
===Clearing ACLs===
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
function ExistsEmail($email)
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
return ($count > 0) ? TRUE : FALSE;
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
=== RSS options ===
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
=== 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
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
=== 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!";
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
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
===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
===Local links===
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--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...
- 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''
===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
===Online editing of mindmaps would be great===
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
===How to format code to get two % characters without space together?===
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
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:
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?:
else if ($thing == ""¥¥")
$timestamp = $wakka->GetPageTime(); //hopefully this function returns the right format?
return (++$trigger_deleted % 2 ? "<DEL datetime=\"$timestamp\">" : "</DEL>");
--NilsLindenberg
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
===Language support===
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
=== 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
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
~& this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
=== 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
The edit page handler seems to convert spaces to tabs throughout the entire document, including Code blocks.
**From edit.php**
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
===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
CategoryWikka
CategoryDevelopment
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
~-SuggestionsArchive for resolved suggestions
**Issues often asked for**
~-[[CategorySystemOverhaul Categories]]
~-[[DateAndTimeFormat Date/Time]]
~-[[WikkaFilters Wikka Exporting/Importing]]
~-[[WikkaInternationalization Internationalization/Localisation]]
~-[[WikkaOptimization Optimization]]
~-[[WikkaToPdf PDF-Export]]
~-[[SectionEditing Section Editing]]
~-[[WikkaSpamFighting Spam (and related issues)]]
~-[[TableofcontentsAction Table of content (TOC)]]
~-[[WikkaTables Tables]]
~-[[WikkaFolksonomy (Technorati) tags & related]]
~-TemplateSystem
~-UserMap
~-[[WikkaWorkarounds Workarounds for specific platforms]]
===Generate ID in forms; allow class===
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made it into a semi-spec.//
Every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
In addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). So the ##""FormOpen()""## method should also:
--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");
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-adress 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
===Single-click restore of previous versions===
//copied from WikkaBugs - this is a suggestion, not a bug --NilsLindenberg//
Single-click restore of previous versions (without copying/pasting). -Sam
~& ''Yes, this will be implemented at some point.'' - JsnX
~~&I should point out that there is an alternative to copying/pasting.
~~~& Go to the revisions page.
~~~& Click the date and time link that you would like to revert back to.
~~~& Click the 'Re-edit this old revision' button.
~~~& Click the 'Store' button.
In any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. While our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own Wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
The only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. There are two problems with this:
~1)Users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)Code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
Copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. If any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of Wikka). That leaves us with finding an escape method that's easy for users to implement.
There are two requirements for an "escaped" ""%%"" then:
~1)Easy to remember and apply by end users
~1)Not (not likely) part of the syntax of any language
One option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. A good candidate might be **DOUBLE_PERCENT** - it's easy enough to remember and easy to implement:
The formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to GeSHI for rendering; the grab code handler could just as easily replace it before making the code block available for download.
Thoughts anyone?
--JavaWoman
~&It's a good idea, but: You are sure DOUBLE_PERCENT is no reserved word in a language? Or unlikely to comme up in a code? --NilsLindenberg
~~&Try googling for 'DOUBLE_PERCENT': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). It's certainly not a reserved word in any of the languages GeSHi currently has support for, going by the language files it comes with. There's no way to be 100% certain but it seems to be a pretty safe bet. --JavaWoman
===Preview===
A doubleclick on a page in the preview should lead to "re-edit" of the text. --NilsLindenberg
~& Good point, agreed -- DarTar
Another point: The access-key for "re-edit" is alt+p at the moment. Wouldn't alt+e be more logic? --NilsLindenberg
===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
===Color Formatting===
The current color formatting isn't very wiki like. Altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
this regex syntax is lifted from a ""UseMod"" Wiki patch.
%%s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
I am by NO means a regex expert, but it seems that this should do the deal... I'm just not sure where it would go. By using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--MonstoBrukes
~&Please take a look at WikkaExtensibleMarkup --NilsLindenberg
~~&I looked at it. what point specifically did you intend i take from it?
~~~& JavaWoman had a proposal about a color-markup there. I think its the better place for the discussion. The recognition of markup is done in the formatter (formatters/wakka.php). I am no expert for regexps too, but wouldn't the first or catch too much? --NilsLindenberg
===Integration into existing site===
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
===Documentation===
Documentation on the site here seems . . . fragmented I think is the best word. Admin features are the example i'll use cuz it was my big hurdle. At this point I've only been able to find that the account created at install is THE admin, and as site owner i should give access to that account to the people that i want to admin the site. Is there more to it than this?
~&You can add usernames to the admin-list, if you don't want to share the admin-account. Specify multiple wiki names separated by commas e.g: JsnX, HendrikMans, CoolJoeAdmin in the wikka.config.php in "admin-users" (see ConfigurationOptions). Admins can see, edit and delete any page, even if they are set to private.
Searching for "Admin Features" yeilds over 100 entries. There's nothing in CategoryDocumentation detailing admin features, and the page WikkaFeatures mentions several admin features that have neither further explanation nor links.
~&Will be changed, but not today :)
On top of all this, searching ACL reveals **one page** that just mentions ACL more in passing. The page with Category instructions is also a little under informed. You'd think that after following 2 step instructions that it'd work.
~&I think you mean ACLInfo and WikiCategory? If you have questions about a documentation-page, please leave a comment about that on the page. We can only make it better if we know what is not understandable. Remember that this is a wiki :)
This page is another example. I started reading it the other night looking for something specific but by the time i finished reading it, i had about 6 different things i felt like commenting on. It's so long tho that i felt my comments would be missed so i didn't bother. Rather than piled on one after the other, after a certain age, each of these subjects should be broken off to their own page in a CategorySuggestionBox and listed here. (I mean this is a wiki and space isn't necessarily at a premium) This would make it easier to find and contribute to a specific topic. If a search produces this page as a result, the initial impression is that the search was really messed up hitting "suggestionbox" with my search terms.
Anyway... the suggestion? Organizing documentation should be THE priority. This site looks quite nice. It's a shining example of how wikka works when beat into perfect shape. But the site I installed looked and acted nothing like this...
~&Yes, we can and should organize the documentation better (and some other parts of this wiki). We will move it to a new subdomain (see DocumentationLanguageLinking) and after that we can bring it in better shape. But don't forget that this is a wiki and you have the right to participate :) --NilsLindenberg
~~&Does this mean that if I go ahead and make a "Category Suggestion Box" and split this pages into seperate doco's that it won't step on people's toes? I think this would be good and don't mind doing that bit of work - but don't want to annoy too many people [espec. seeing as I am quite the newbie here...] -- KiltanneN
~~~&I say; simply start and wait for the reactions. Thats how I do it, most of the time ;) --NilsLindenberg
===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:
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
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
===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
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
~~& 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
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
===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"))
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
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
include ('Wakka.class.php');
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
===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):
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
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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:
~&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
Is there a way to include a target in a link, so that the Link opens in a new window?
--GregorLindner
===Signature===
//(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)//
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
=== 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
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-- KarmaTester (2005-01-26 06:52:07)
=== Image dimensions ===
The [[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
===Clearing ACLs===
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
function ExistsEmail($email)
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
return ($count > 0) ? TRUE : FALSE;
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
=== RSS options ===
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
=== 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
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
=== 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!";
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
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
===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
===Local links===
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--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...
- 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''
===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
===Online editing of mindmaps would be great===
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
===How to format code to get two % characters without space together?===
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
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:
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?:
else if ($thing == ""¥¥")
$timestamp = $wakka->GetPageTime(); //hopefully this function returns the right format?
return (++$trigger_deleted % 2 ? "<DEL datetime=\"$timestamp\">" : "</DEL>");
--NilsLindenberg
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
===Language support===
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
=== 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
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
~& this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
=== 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
The edit page handler seems to convert spaces to tabs throughout the entire document, including Code blocks.
**From edit.php**
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
===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
CategoryWikka
CategoryDevelopment
Deletions:
feedback is welcomed and appreciated. use the form or edit this page.
**please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== bugs vs. feature suggestions ===
please post issues/bugs to the appropriate page:
~-general bugs/issues: wikkabugs
~-css layout issues: wikkacss
~-suggestionsarchive for resolved suggestions
**issues often asked for**
~-[[categorysystemoverhaul categories]]
~-[[dateandtimeformat date/time]]
~-[[wikkafilters wikka exporting/importing]]
~-[[wikkainternationalization internationalization/localisation]]
~-[[wikkaoptimization optimization]]
~-[[wikkatopdf pdf-export]]
~-[[sectionediting section editing]]
~-[[wikkaspamfighting spam (and related issues)]]
~-[[tableofcontentsaction table of content (toc)]]
~-[[wikkatables tables]]
~-[[wikkafolksonomy (technorati) tags & related]]
~-templatesystem
~-usermap
~-[[wikkaworkarounds workarounds for specific platforms]]
===generate id in forms; allow class===
//i know we've dicussed this multiple times but could not find an actual suggestion; i've made it into a semi-spec.//
every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and javascript, if desired). we have a ##""formopen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""formclose())""## - but this method does not generate an id nor accept a parameter to create one. it should be able to do both:
in addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). so the ##""formopen()""## method should also:
--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");
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-adress 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
===single-click restore of previous versions===
//copied from wikkabugs - this is a suggestion, not a bug --nilslindenberg//
single-click restore of previous versions (without copying/pasting). -sam
~& ''yes, this will be implemented at some point.'' - jsnx
~~&i should point out that there is an alternative to copying/pasting.
~~~& go to the revisions page.
~~~& click the date and time link that you would like to revert back to.
~~~& click the 're-edit this old revision' button.
~~~& click the 'store' button.
in any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. while our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
the only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. there are two problems with this:
~1)users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. if any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of wikka). that leaves us with finding an escape method that's easy for users to implement.
there are two requirements for an "escaped" ""%%"" then:
~1)easy to remember and apply by end users
~1)not (not likely) part of the syntax of any language
one option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. a good candidate might be **double_percent** - it's easy enough to remember and easy to implement:
the formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to geshi for rendering; the grab code handler could just as easily replace it before making the code block available for download.
thoughts anyone?
--javawoman
~&it's a good idea, but: you are sure double_percent is no reserved word in a language? or unlikely to comme up in a code? --nilslindenberg
~~&try googling for 'double_percent': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). it's certainly not a reserved word in any of the languages geshi currently has support for, going by the language files it comes with. there's no way to be 100% certain but it seems to be a pretty safe bet. --javawoman
===preview===
a doubleclick on a page in the preview should lead to "re-edit" of the text. --nilslindenberg
~& good point, agreed -- dartar
another point: the access-key for "re-edit" is alt+p at the moment. wouldn't alt+e be more logic? --nilslindenberg
===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
===color formatting===
the current color formatting isn't very wiki like. altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
this regex syntax is lifted from a ""usemod"" wiki patch.
%%s/\^([a-za-z]{1,}|#[0-9a-fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
i am by no means a regex expert, but it seems that this should do the deal... i'm just not sure where it would go. by using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--monstobrukes
~&please take a look at wikkaextensiblemarkup --nilslindenberg
~~&i looked at it. what point specifically did you intend i take from it?
~~~& javawoman had a proposal about a color-markup there. i think its the better place for the discussion. the recognition of markup is done in the formatter (formatters/wakka.php). i am no expert for regexps too, but wouldn't the first or catch too much? --nilslindenberg
===integration into existing site===
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
===documentation===
documentation on the site here seems . . . fragmented i think is the best word. admin features are the example i'll use cuz it was my big hurdle. at this point i've only been able to find that the account created at install is the admin, and as site owner i should give access to that account to the people that i want to admin the site. is there more to it than this?
~&you can add usernames to the admin-list, if you don't want to share the admin-account. specify multiple wiki names separated by commas e.g: jsnx, hendrikmans, cooljoeadmin in the wikka.config.php in "admin-users" (see configurationoptions). admins can see, edit and delete any page, even if they are set to private.
searching for "admin features" yeilds over 100 entries. there's nothing in categorydocumentation detailing admin features, and the page wikkafeatures mentions several admin features that have neither further explanation nor links.
~&will be changed, but not today :)
on top of all this, searching acl reveals **one page** that just mentions acl more in passing. the page with category instructions is also a little under informed. you'd think that after following 2 step instructions that it'd work.
~&i think you mean aclinfo and wikicategory? if you have questions about a documentation-page, please leave a comment about that on the page. we can only make it better if we know what is not understandable. remember that this is a wiki :)
this page is another example. i started reading it the other night looking for something specific but by the time i finished reading it, i had about 6 different things i felt like commenting on. it's so long tho that i felt my comments would be missed so i didn't bother. rather than piled on one after the other, after a certain age, each of these subjects should be broken off to their own page in a categorysuggestionbox and listed here. (i mean this is a wiki and space isn't necessarily at a premium) this would make it easier to find and contribute to a specific topic. if a search produces this page as a result, the initial impression is that the search was really messed up hitting "suggestionbox" with my search terms.
anyway... the suggestion? organizing documentation should be the priority. this site looks quite nice. it's a shining example of how wikka works when beat into perfect shape. but the site i installed looked and acted nothing like this...
~&yes, we can and should organize the documentation better (and some other parts of this wiki). we will move it to a new subdomain (see documentationlanguagelinking) and after that we can bring it in better shape. but don't forget that this is a wiki and you have the right to participate :) --nilslindenberg
~~&does this mean that if i go ahead and make a "category suggestion box" and split this pages into seperate doco's that it won't step on people's toes? i think this would be good and don't mind doing that bit of work - but don't want to annoy too many people [espec. seeing as i am quite the newbie here...] -- kiltannen
~~~&i say; simply start and wait for the reactions. thats how i do it, most of the time ;) --nilslindenberg
===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:
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
===sending 403 headers===
(related to the //search engine results inflation// item below)
for pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //you aren't allowed to read this page// message - a http header like the following:
%%(php) header('http/1.0 403 forbidden');%%
-- dartar
~& oh, and maybe 404 headers for missing pages (which would help prevent se from spidering links to non existing pages)? -- dartar
===numbers as page names?===
i'm curious about the wikka convention that numbers cannot be page names. i'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature i'd definitely suggest.
btw, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
thx, robertdaeley
~& agreed, we should drop this restriction. numbers in page names might also be useful to use wikka as a [[wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[socialsoftware social software]] community. robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: jwcalendarwithpagecreation -- dartar
===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
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
~~& 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
==wikka markup inside tables==
- i think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - richardterry
~&richard, thanks for the feedback. it is on my agenda to look at another solution for tables. my plan is to allow straight html table syntax after running it through the "safehtml" checker. but i need to check that there are no security risks with this first. also, i'll take a peak at your suggestion too. -- jsnx
~&check out my proposal for an extended tableaction which does provide this. (tableaction is intended as a preliminary solution until we have table markup.) --javawoman
===robot friendly pages===
right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. it'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --barkerjr
~&ah, maybe this is why a now non-existent page that i deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --gmbowen
~&see robotfriendly. --dotmg
=== //kant-en-klaar// code blocks ===
a micro-idea before going to bed. we all know it's a bad idea to copy code blocks from the formatted version of a page.
if i want to test some freshly posted code, here's what i have to do:
~1) scan the page for the chunk of code i want to save (this can be pretty difficult on long source pages with no syntax highlighting);
wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
see grabcodehandler for a first proposal -- dartar
===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"))
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
(the following was copied from a comment on modrewrite -- javawoman)
//hi, i discovered that the default .htaccess included did not work for my setup up. i needed to include ""rewritebase"" /directory/ as well since wikka is installed in a subdirectory. i hope this helps anyone having trouble getting wikka to work.
the installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""rewritebase"" statement to take care of this. --javawoman
===separation of wakka class from wikka.php===
i use wikka as wiki engine of [[http://diantn.free.fr my page]].
imo, the wikka.php file is too big to be one single file. i suggest that we separate the wakka class into new file, say wakka.class.php
and then in the wikka.php, e.g at line where the wakka class previously located, simply we put:
include ('wakka.class.php');
-- din
~&din, this is a //very// good idea. i fact, the idea had crossed my mind already, but thanks for the reminder. :) indeed, a class belongs in a file of its own. --javawoman
~~&maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --nilslindenberg
~~~&with my current proposed structure on wikkacodestructure, it would go into the library folder; classes that are shared, into library/common. i prefer a //functional// separation rather than one based on coding format. --javawoman
===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):
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
===save pages to pdf format===
(copied from wikkadevelopment --nils)
page output to an adobe pdf file using fpdf.
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:
~&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
is there a way to include a target in a link, so that the link opens in a new window?
--gregorlindner
===signature===
//(copied from wikkafaq, but perhaps better at wantedformatters? --nilslindenberg)//
does wikka support automatic user signatures in pages (not comments)? i need some code so that users don't need to enter their username and time/date when they are working on a page in threadmode. i've searched in the docs, but i could not find anything about this, any ideas?
-- jeroenjansen (2005-01-28 11:35:43)
~& jeroen, there is a hack for automatically adding a user's signature in wakkawiki posted by nickk on his [[http://wakkawiki.de/nickk homepage]]. it should be easy to adapt to wikka. -- dartar
~~& dartar, just saw your reply. thanks for the hint! --jeroenjansen
=== 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
=== create rewrite rules on install ===
~//copied from comment on wikkainstallation --javawoman//
since i installed wikka in a subdirectory under the domain root i needed to add the following to the .htaccess file just under """rewriteengine on""":
""rewritebase"" /subdirectory/
devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-- karmatester (2005-01-26 06:52:07)
=== image dimensions ===
the [[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
~~~¬ed. 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
===clearing acls===
there should be a button on the acl page to "reset acls to default". what this would do is delete the record for the current page from the acls table. there is a distinction between setting the acls to the sites default values and not having acls defined for a page. if the acls are set and the default values get changed, the page will remain at the set values. however, if no acls are defined, the page will always use the default values.
to help show the distinction, there should be a visual indicator on the acl handler page which states whether the page has acls defined or is using the site's default values. basically, just check for a record in the acls table for the current page, and display a message accordingly. -- jsnx
== user registration control ==
it would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (or at least the configurable option to check for only one email/one account.)
it should also then be easier (i would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful aclswithusergroups hack that christian created to make a list of banned users by username. yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --movielady
~&you know how many testusers my wikka already has? *g* this should do the job (this time no config option, sorry jw :)
function existsemail($email)
$query = "select count(email)
from ".$this->config['table_prefix']."users
where email='".mysql_real_escape_string($email)."'";
if ($r = $this->query($query))
return ($count > 0) ? true : false;
~&place this function in wikka.php right after function userwantscomments(). and change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "password too short.";
else if (strlen($password) < 5) $error = "password too short.";
else if ($this->existsemail($email)) $error = "you already have a username.";
~&--nilslindenberg
~~& lol i can imagine. thanks so much for this - i'll try it out this evening. --movielady
~& speaking of registration control, note to self: make a configuration option to turn off new account registrations. some sites might be private and not want people registering. admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- jsnx
~~& (you saw userregistration by nils? i think it, or something like it, should be standard. mike)
~~~& doh! i somehow missed that. that's pretty much what i had in mind. nice job, nils! :) -- jsnx
~~~~&thank you. about your admin-adding-user case: that's an addition to useradmin, not for usersettings. --nilslindenberg
~~~&there's also code around that uses gd & that could be built onto nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. ultimately, as the bots become more sophisticated i think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what i mean (i like the simplicity of the first version in the second example). -- gmbowen
~~~~&yes, "captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). add a sound equivalent? well, there are people who are deaf **and** blind. are we going to deny them access to our wikis? i'm not in favor of making wikka **in**accessible when we should be working towards making it **more** accessible. --javawoman.
=== rss options ===
it would be wonderful to be able to choose what kind of rss feed is created for a page. for example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --movielady
=== 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
~¬ed - good suggestion. --javawoman
=== language file ===
i would be nice to see all phrases put into a single file. this would allow to translate the wiki in a few hours without changes every single file.
~&look at dotmgs approach at wikkainternationalization. but at least it should work for languages in the range of the "normal" (ascii?) code. if you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --nilslindenberg
~~&the most flexible and powerful way to support i18n is still gettext which is supported by php. if we go in that direction (likely), manually creating a "language file" is needless work since gettext does all that automatically for you. and it supports options for handling plurals and such which simple string-to-string language files cannot handle. the problem is that code needs to be written in a way to properly be able to use gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any html markup (actually this is true for simple laguage files as well). currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --javawoman
=== 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!";
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
===finally using cvs?===
i apologize since this idea has been suggested before, and i believe the developers are working to implement it already. however, with the beta of 1.1.6.0 released, i think it would be a good time now to start using cvs. this allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. in addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
also, i am willing to help with the cvs migration process if needed and help anyone who is interested in learning how to use cvs.
-- mikexstudios
~&there is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. just has to be updated --nilslindenberg
~~&actually, nils, we need a lot more than "just updating" the cvs at sourceforge. we need to integrate cvs in our development process - and develop a process for doing so. that requires a bit of planning... :) and while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with cvs specifically, so a bit of study will be required before we can start planning. help with learning how to use cvs //well// from someone who has experience with it would certainly be welcome, mike! thanks for the offer. --javawoman ''(reading manuals....)''
~~~& the "just was meant as an addition to existing ("of course" would have been better, though :). i just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case mike does not no. it is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --nilslindenberg
~~~~& hi nils. actually, i did find wikka's cvs repository at sf weeks ago, but i forgot to mention it in my above post. javawoman pretty much echoed my thoughts. we need to actively use cvs/update it constantly as changes are made. i run a project called [[http://xcomic.sourceforge.net xcomic]] that uses sourceforge's cvs a lot, so i have some experience with that. in addition, i recently set something up for my project that i think will be pretty cool if wikka decides to really use cvs: a commit mailing list. anytime someone makes a change to the cvs (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). in any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --mikexstudios
~~~~~&mike, i for one would welcome your insights in using cvs. both dartar and i have some ideas about how we want it set up - but no experience in doing so (in cvs). may i suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? for this type of thing i think that would be the best medium to discuss thoughs and methods. i like the idea of a commit mailing list. --javawoman
===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
===local links===
it would be nice if a link to the same host as the wikka install was not flagged as 'external'. i've added a 'hack' to my personal page: kickthedonkey. works fine here.
--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...
- 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''
===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
===online editing of mindmaps would be great===
(copied from sourceforge.net --nilslindenberg)
it would be great, if users should work together on mindmaps.
maybe by downloading/ open with freemind and then having a possiblity to save changes in freemind directly back to the online mindmap.
===how to format code to get two % characters without space together?===
i want to produce a code sample page in wikka with dos batch code. the code syntax requires two percent characters together to markup a variable. example: % %variable% % (without the spaces). wikka always tries to format the text as code, even if i format the dos code inside a code block, even if i %% marked it as code with two percent characters like this here%%
is there a solution? i could not find a literal entity for "percent"
''you could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. see: %%some text with %% embedded in it%%
but it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (and how do you markup wiki markup as **code**?) -- javawoman''
how about the € (euro) symbol? or is it to new? --nilslindenberg
''the main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. and it might occur in code as well (imagine a sample conversion routine). wiki markup should be easy to type. so we need a symbol (or sumbol combination, maybe), that's:
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of apl!)
the **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). maybe we should do a search (google?) to check whether **!!** or a combo is actually an operator in any language.
-- javawoman''
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:
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?:
else if ($thing == ""¹¹")
$timestamp = $wakka->getpagetime(); //hopefully this function returns the right format?
return (++$trigger_deleted % 2 ? "<del datetime=\"$timestamp\">" : "</del>");
--nilslindenberg
working on a test installation, i found the user setting "show comments by default" did not work. testing it here, i found it doesn't work here, either.
haven't dug in the code yet to find where this should happen (but will).
i'm quite happy with wikka's capabilities out of the box - good starting point! :) i'll likely stay with it - but i'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
great work! javawoman
it does work.... just not as might be expected. comment preference is stored for each page as you browse the wiki. so, if you browse a few pages with comments not showing, it remembers this. then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
try this:
- browse to usersettings and check off "show comments by default" and click "update settings".
- now **close all browser windows**
- open back up your browser and go to the same pages......
- comments are now showing by default, right?
- jsnx
right. i see it does work. ;) somewhat, um, counterintuitive, though. so i guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). that would, i think, be more in line with expected behavior. possible? (i haven't looked at that area of the code yet.) --javawoman.
===language support===
i was searching almost whole site to check what kind of languages are supported by this wiki. i was unsuccessful. is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
thanks mdd
=== 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
== question: note? ==
it is me again! what is the function of the "please add a note on your edit" - field? again and again: keep on the good work.
-- skywalk
~& this note is shown in some lists like the recentchanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --dreckfehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --georgepetsagourakis
=== 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
the edit page handler seems to convert spaces to tabs throughout the entire document, including code blocks.
**from edit.php**
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
===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
categorywikka
categorydevelopment
Deletions:
Additions:
[[abc]] abc
=====suggestion box=====
feedback is welcomed and appreciated. use the form or edit this page.
**please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== bugs vs. feature suggestions ===
please post issues/bugs to the appropriate page:
~-general bugs/issues: wikkabugs
~-css layout issues: wikkacss
~-suggestionsarchive for resolved suggestions
**issues often asked for**
~-[[categorysystemoverhaul categories]]
~-[[dateandtimeformat date/time]]
~-[[wikkafilters wikka exporting/importing]]
~-[[wikkainternationalization internationalization/localisation]]
~-[[wikkaoptimization optimization]]
~-[[wikkatopdf pdf-export]]
~-[[sectionediting section editing]]
~-[[wikkaspamfighting spam (and related issues)]]
~-[[tableofcontentsaction table of content (toc)]]
~-[[wikkatables tables]]
~-[[wikkafolksonomy (technorati) tags & related]]
~-templatesystem
~-usermap
~-[[wikkaworkarounds workarounds for specific platforms]]
===generate id in forms; allow class===
//i know we've dicussed this multiple times but could not find an actual suggestion; i've made it into a semi-spec.//
every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and javascript, if desired). we have a ##""formopen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""formclose())""## - but this method does not generate an id nor accept a parameter to create one. it should be able to do both:
in addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). so the ##""formopen()""## method should also:
--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");
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-adress 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
===single-click restore of previous versions===
//copied from wikkabugs - this is a suggestion, not a bug --nilslindenberg//
single-click restore of previous versions (without copying/pasting). -sam
~& ''yes, this will be implemented at some point.'' - jsnx
~~&i should point out that there is an alternative to copying/pasting.
~~~& go to the revisions page.
~~~& click the date and time link that you would like to revert back to.
~~~& click the 're-edit this old revision' button.
~~~& click the 'store' button.
in any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. while our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
the only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. there are two problems with this:
~1)users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. if any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of wikka). that leaves us with finding an escape method that's easy for users to implement.
there are two requirements for an "escaped" ""%%"" then:
~1)easy to remember and apply by end users
~1)not (not likely) part of the syntax of any language
one option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. a good candidate might be **double_percent** - it's easy enough to remember and easy to implement:
the formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to geshi for rendering; the grab code handler could just as easily replace it before making the code block available for download.
thoughts anyone?
--javawoman
~&it's a good idea, but: you are sure double_percent is no reserved word in a language? or unlikely to comme up in a code? --nilslindenberg
~~&try googling for 'double_percent': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). it's certainly not a reserved word in any of the languages geshi currently has support for, going by the language files it comes with. there's no way to be 100% certain but it seems to be a pretty safe bet. --javawoman
===preview===
a doubleclick on a page in the preview should lead to "re-edit" of the text. --nilslindenberg
~& good point, agreed -- dartar
another point: the access-key for "re-edit" is alt+p at the moment. wouldn't alt+e be more logic? --nilslindenberg
===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
===color formatting===
the current color formatting isn't very wiki like. altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
this regex syntax is lifted from a ""usemod"" wiki patch.
%%s/\^([a-za-z]{1,}|#[0-9a-fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
i am by no means a regex expert, but it seems that this should do the deal... i'm just not sure where it would go. by using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--monstobrukes
~&please take a look at wikkaextensiblemarkup --nilslindenberg
~~&i looked at it. what point specifically did you intend i take from it?
~~~& javawoman had a proposal about a color-markup there. i think its the better place for the discussion. the recognition of markup is done in the formatter (formatters/wakka.php). i am no expert for regexps too, but wouldn't the first or catch too much? --nilslindenberg
===integration into existing site===
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
===documentation===
documentation on the site here seems . . . fragmented i think is the best word. admin features are the example i'll use cuz it was my big hurdle. at this point i've only been able to find that the account created at install is the admin, and as site owner i should give access to that account to the people that i want to admin the site. is there more to it than this?
~&you can add usernames to the admin-list, if you don't want to share the admin-account. specify multiple wiki names separated by commas e.g: jsnx, hendrikmans, cooljoeadmin in the wikka.config.php in "admin-users" (see configurationoptions). admins can see, edit and delete any page, even if they are set to private.
searching for "admin features" yeilds over 100 entries. there's nothing in categorydocumentation detailing admin features, and the page wikkafeatures mentions several admin features that have neither further explanation nor links.
~&will be changed, but not today :)
on top of all this, searching acl reveals **one page** that just mentions acl more in passing. the page with category instructions is also a little under informed. you'd think that after following 2 step instructions that it'd work.
~&i think you mean aclinfo and wikicategory? if you have questions about a documentation-page, please leave a comment about that on the page. we can only make it better if we know what is not understandable. remember that this is a wiki :)
this page is another example. i started reading it the other night looking for something specific but by the time i finished reading it, i had about 6 different things i felt like commenting on. it's so long tho that i felt my comments would be missed so i didn't bother. rather than piled on one after the other, after a certain age, each of these subjects should be broken off to their own page in a categorysuggestionbox and listed here. (i mean this is a wiki and space isn't necessarily at a premium) this would make it easier to find and contribute to a specific topic. if a search produces this page as a result, the initial impression is that the search was really messed up hitting "suggestionbox" with my search terms.
anyway... the suggestion? organizing documentation should be the priority. this site looks quite nice. it's a shining example of how wikka works when beat into perfect shape. but the site i installed looked and acted nothing like this...
~&yes, we can and should organize the documentation better (and some other parts of this wiki). we will move it to a new subdomain (see documentationlanguagelinking) and after that we can bring it in better shape. but don't forget that this is a wiki and you have the right to participate :) --nilslindenberg
~~&does this mean that if i go ahead and make a "category suggestion box" and split this pages into seperate doco's that it won't step on people's toes? i think this would be good and don't mind doing that bit of work - but don't want to annoy too many people [espec. seeing as i am quite the newbie here...] -- kiltannen
~~~&i say; simply start and wait for the reactions. thats how i do it, most of the time ;) --nilslindenberg
===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:
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
===sending 403 headers===
(related to the //search engine results inflation// item below)
for pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //you aren't allowed to read this page// message - a http header like the following:
%%(php) header('http/1.0 403 forbidden');%%
-- dartar
~& oh, and maybe 404 headers for missing pages (which would help prevent se from spidering links to non existing pages)? -- dartar
===numbers as page names?===
i'm curious about the wikka convention that numbers cannot be page names. i'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature i'd definitely suggest.
btw, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
thx, robertdaeley
~& agreed, we should drop this restriction. numbers in page names might also be useful to use wikka as a [[wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[socialsoftware social software]] community. robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: jwcalendarwithpagecreation -- dartar
===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
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
~~& 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
==wikka markup inside tables==
- i think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - richardterry
~&richard, thanks for the feedback. it is on my agenda to look at another solution for tables. my plan is to allow straight html table syntax after running it through the "safehtml" checker. but i need to check that there are no security risks with this first. also, i'll take a peak at your suggestion too. -- jsnx
~&check out my proposal for an extended tableaction which does provide this. (tableaction is intended as a preliminary solution until we have table markup.) --javawoman
===robot friendly pages===
right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. it'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --barkerjr
~&ah, maybe this is why a now non-existent page that i deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --gmbowen
~&see robotfriendly. --dotmg
=== //kant-en-klaar// code blocks ===
a micro-idea before going to bed. we all know it's a bad idea to copy code blocks from the formatted version of a page.
if i want to test some freshly posted code, here's what i have to do:
~1) scan the page for the chunk of code i want to save (this can be pretty difficult on long source pages with no syntax highlighting);
wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
see grabcodehandler for a first proposal -- dartar
===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"))
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
(the following was copied from a comment on modrewrite -- javawoman)
//hi, i discovered that the default .htaccess included did not work for my setup up. i needed to include ""rewritebase"" /directory/ as well since wikka is installed in a subdirectory. i hope this helps anyone having trouble getting wikka to work.
the installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""rewritebase"" statement to take care of this. --javawoman
===separation of wakka class from wikka.php===
i use wikka as wiki engine of [[http://diantn.free.fr my page]].
imo, the wikka.php file is too big to be one single file. i suggest that we separate the wakka class into new file, say wakka.class.php
and then in the wikka.php, e.g at line where the wakka class previously located, simply we put:
include ('wakka.class.php');
-- din
~&din, this is a //very// good idea. i fact, the idea had crossed my mind already, but thanks for the reminder. :) indeed, a class belongs in a file of its own. --javawoman
~~&maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --nilslindenberg
~~~&with my current proposed structure on wikkacodestructure, it would go into the library folder; classes that are shared, into library/common. i prefer a //functional// separation rather than one based on coding format. --javawoman
===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):
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
===save pages to pdf format===
(copied from wikkadevelopment --nils)
page output to an adobe pdf file using fpdf.
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:
~&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
is there a way to include a target in a link, so that the link opens in a new window?
--gregorlindner
===signature===
//(copied from wikkafaq, but perhaps better at wantedformatters? --nilslindenberg)//
does wikka support automatic user signatures in pages (not comments)? i need some code so that users don't need to enter their username and time/date when they are working on a page in threadmode. i've searched in the docs, but i could not find anything about this, any ideas?
-- jeroenjansen (2005-01-28 11:35:43)
~& jeroen, there is a hack for automatically adding a user's signature in wakkawiki posted by nickk on his [[http://wakkawiki.de/nickk homepage]]. it should be easy to adapt to wikka. -- dartar
~~& dartar, just saw your reply. thanks for the hint! --jeroenjansen
=== 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
=== create rewrite rules on install ===
~//copied from comment on wikkainstallation --javawoman//
since i installed wikka in a subdirectory under the domain root i needed to add the following to the .htaccess file just under """rewriteengine on""":
""rewritebase"" /subdirectory/
devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-- karmatester (2005-01-26 06:52:07)
=== image dimensions ===
the [[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
~~~¬ed. 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
===clearing acls===
there should be a button on the acl page to "reset acls to default". what this would do is delete the record for the current page from the acls table. there is a distinction between setting the acls to the sites default values and not having acls defined for a page. if the acls are set and the default values get changed, the page will remain at the set values. however, if no acls are defined, the page will always use the default values.
to help show the distinction, there should be a visual indicator on the acl handler page which states whether the page has acls defined or is using the site's default values. basically, just check for a record in the acls table for the current page, and display a message accordingly. -- jsnx
== user registration control ==
it would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (or at least the configurable option to check for only one email/one account.)
it should also then be easier (i would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful aclswithusergroups hack that christian created to make a list of banned users by username. yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --movielady
~&you know how many testusers my wikka already has? *g* this should do the job (this time no config option, sorry jw :)
function existsemail($email)
$query = "select count(email)
from ".$this->config['table_prefix']."users
where email='".mysql_real_escape_string($email)."'";
if ($r = $this->query($query))
return ($count > 0) ? true : false;
~&place this function in wikka.php right after function userwantscomments(). and change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "password too short.";
else if (strlen($password) < 5) $error = "password too short.";
else if ($this->existsemail($email)) $error = "you already have a username.";
~&--nilslindenberg
~~& lol i can imagine. thanks so much for this - i'll try it out this evening. --movielady
~& speaking of registration control, note to self: make a configuration option to turn off new account registrations. some sites might be private and not want people registering. admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- jsnx
~~& (you saw userregistration by nils? i think it, or something like it, should be standard. mike)
~~~& doh! i somehow missed that. that's pretty much what i had in mind. nice job, nils! :) -- jsnx
~~~~&thank you. about your admin-adding-user case: that's an addition to useradmin, not for usersettings. --nilslindenberg
~~~&there's also code around that uses gd & that could be built onto nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. ultimately, as the bots become more sophisticated i think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what i mean (i like the simplicity of the first version in the second example). -- gmbowen
~~~~&yes, "captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). add a sound equivalent? well, there are people who are deaf **and** blind. are we going to deny them access to our wikis? i'm not in favor of making wikka **in**accessible when we should be working towards making it **more** accessible. --javawoman.
=== rss options ===
it would be wonderful to be able to choose what kind of rss feed is created for a page. for example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --movielady
=== 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
~¬ed - good suggestion. --javawoman
=== language file ===
i would be nice to see all phrases put into a single file. this would allow to translate the wiki in a few hours without changes every single file.
~&look at dotmgs approach at wikkainternationalization. but at least it should work for languages in the range of the "normal" (ascii?) code. if you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --nilslindenberg
~~&the most flexible and powerful way to support i18n is still gettext which is supported by php. if we go in that direction (likely), manually creating a "language file" is needless work since gettext does all that automatically for you. and it supports options for handling plurals and such which simple string-to-string language files cannot handle. the problem is that code needs to be written in a way to properly be able to use gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any html markup (actually this is true for simple laguage files as well). currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --javawoman
=== 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!";
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
===finally using cvs?===
i apologize since this idea has been suggested before, and i believe the developers are working to implement it already. however, with the beta of 1.1.6.0 released, i think it would be a good time now to start using cvs. this allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. in addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
also, i am willing to help with the cvs migration process if needed and help anyone who is interested in learning how to use cvs.
-- mikexstudios
~&there is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. just has to be updated --nilslindenberg
~~&actually, nils, we need a lot more than "just updating" the cvs at sourceforge. we need to integrate cvs in our development process - and develop a process for doing so. that requires a bit of planning... :) and while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with cvs specifically, so a bit of study will be required before we can start planning. help with learning how to use cvs //well// from someone who has experience with it would certainly be welcome, mike! thanks for the offer. --javawoman ''(reading manuals....)''
~~~& the "just was meant as an addition to existing ("of course" would have been better, though :). i just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case mike does not no. it is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --nilslindenberg
~~~~& hi nils. actually, i did find wikka's cvs repository at sf weeks ago, but i forgot to mention it in my above post. javawoman pretty much echoed my thoughts. we need to actively use cvs/update it constantly as changes are made. i run a project called [[http://xcomic.sourceforge.net xcomic]] that uses sourceforge's cvs a lot, so i have some experience with that. in addition, i recently set something up for my project that i think will be pretty cool if wikka decides to really use cvs: a commit mailing list. anytime someone makes a change to the cvs (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). in any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --mikexstudios
~~~~~&mike, i for one would welcome your insights in using cvs. both dartar and i have some ideas about how we want it set up - but no experience in doing so (in cvs). may i suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? for this type of thing i think that would be the best medium to discuss thoughs and methods. i like the idea of a commit mailing list. --javawoman
===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
===local links===
it would be nice if a link to the same host as the wikka install was not flagged as 'external'. i've added a 'hack' to my personal page: kickthedonkey. works fine here.
--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...
- 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''
===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
===online editing of mindmaps would be great===
(copied from sourceforge.net --nilslindenberg)
it would be great, if users should work together on mindmaps.
maybe by downloading/ open with freemind and then having a possiblity to save changes in freemind directly back to the online mindmap.
===how to format code to get two % characters without space together?===
i want to produce a code sample page in wikka with dos batch code. the code syntax requires two percent characters together to markup a variable. example: % %variable% % (without the spaces). wikka always tries to format the text as code, even if i format the dos code inside a code block, even if i %% marked it as code with two percent characters like this here%%
is there a solution? i could not find a literal entity for "percent"
''you could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. see: %%some text with %% embedded in it%%
but it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (and how do you markup wiki markup as **code**?) -- javawoman''
how about the € (euro) symbol? or is it to new? --nilslindenberg
''the main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. and it might occur in code as well (imagine a sample conversion routine). wiki markup should be easy to type. so we need a symbol (or sumbol combination, maybe), that's:
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of apl!)
the **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). maybe we should do a search (google?) to check whether **!!** or a combo is actually an operator in any language.
-- javawoman''
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:
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?:
else if ($thing == ""¹¹")
$timestamp = $wakka->getpagetime(); //hopefully this function returns the right format?
return (++$trigger_deleted % 2 ? "<del datetime=\"$timestamp\">" : "</del>");
--nilslindenberg
working on a test installation, i found the user setting "show comments by default" did not work. testing it here, i found it doesn't work here, either.
haven't dug in the code yet to find where this should happen (but will).
i'm quite happy with wikka's capabilities out of the box - good starting point! :) i'll likely stay with it - but i'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
great work! javawoman
it does work.... just not as might be expected. comment preference is stored for each page as you browse the wiki. so, if you browse a few pages with comments not showing, it remembers this. then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
try this:
- browse to usersettings and check off "show comments by default" and click "update settings".
- now **close all browser windows**
- open back up your browser and go to the same pages......
- comments are now showing by default, right?
- jsnx
right. i see it does work. ;) somewhat, um, counterintuitive, though. so i guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). that would, i think, be more in line with expected behavior. possible? (i haven't looked at that area of the code yet.) --javawoman.
===language support===
i was searching almost whole site to check what kind of languages are supported by this wiki. i was unsuccessful. is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
thanks mdd
=== 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
== question: note? ==
it is me again! what is the function of the "please add a note on your edit" - field? again and again: keep on the good work.
-- skywalk
~& this note is shown in some lists like the recentchanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --dreckfehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --georgepetsagourakis
=== 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
the edit page handler seems to convert spaces to tabs throughout the entire document, including code blocks.
**from edit.php**
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
===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
categorywikka
categorydevelopment
=====suggestion box=====
feedback is welcomed and appreciated. use the form or edit this page.
**please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== bugs vs. feature suggestions ===
please post issues/bugs to the appropriate page:
~-general bugs/issues: wikkabugs
~-css layout issues: wikkacss
~-suggestionsarchive for resolved suggestions
**issues often asked for**
~-[[categorysystemoverhaul categories]]
~-[[dateandtimeformat date/time]]
~-[[wikkafilters wikka exporting/importing]]
~-[[wikkainternationalization internationalization/localisation]]
~-[[wikkaoptimization optimization]]
~-[[wikkatopdf pdf-export]]
~-[[sectionediting section editing]]
~-[[wikkaspamfighting spam (and related issues)]]
~-[[tableofcontentsaction table of content (toc)]]
~-[[wikkatables tables]]
~-[[wikkafolksonomy (technorati) tags & related]]
~-templatesystem
~-usermap
~-[[wikkaworkarounds workarounds for specific platforms]]
===generate id in forms; allow class===
//i know we've dicussed this multiple times but could not find an actual suggestion; i've made it into a semi-spec.//
every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and javascript, if desired). we have a ##""formopen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""formclose())""## - but this method does not generate an id nor accept a parameter to create one. it should be able to do both:
in addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). so the ##""formopen()""## method should also:
--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");
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-adress 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
===single-click restore of previous versions===
//copied from wikkabugs - this is a suggestion, not a bug --nilslindenberg//
single-click restore of previous versions (without copying/pasting). -sam
~& ''yes, this will be implemented at some point.'' - jsnx
~~&i should point out that there is an alternative to copying/pasting.
~~~& go to the revisions page.
~~~& click the date and time link that you would like to revert back to.
~~~& click the 're-edit this old revision' button.
~~~& click the 'store' button.
in any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. while our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
the only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. there are two problems with this:
~1)users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. if any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of wikka). that leaves us with finding an escape method that's easy for users to implement.
there are two requirements for an "escaped" ""%%"" then:
~1)easy to remember and apply by end users
~1)not (not likely) part of the syntax of any language
one option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. a good candidate might be **double_percent** - it's easy enough to remember and easy to implement:
the formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to geshi for rendering; the grab code handler could just as easily replace it before making the code block available for download.
thoughts anyone?
--javawoman
~&it's a good idea, but: you are sure double_percent is no reserved word in a language? or unlikely to comme up in a code? --nilslindenberg
~~&try googling for 'double_percent': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). it's certainly not a reserved word in any of the languages geshi currently has support for, going by the language files it comes with. there's no way to be 100% certain but it seems to be a pretty safe bet. --javawoman
===preview===
a doubleclick on a page in the preview should lead to "re-edit" of the text. --nilslindenberg
~& good point, agreed -- dartar
another point: the access-key for "re-edit" is alt+p at the moment. wouldn't alt+e be more logic? --nilslindenberg
===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
===color formatting===
the current color formatting isn't very wiki like. altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
this regex syntax is lifted from a ""usemod"" wiki patch.
%%s/\^([a-za-z]{1,}|#[0-9a-fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
i am by no means a regex expert, but it seems that this should do the deal... i'm just not sure where it would go. by using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--monstobrukes
~&please take a look at wikkaextensiblemarkup --nilslindenberg
~~&i looked at it. what point specifically did you intend i take from it?
~~~& javawoman had a proposal about a color-markup there. i think its the better place for the discussion. the recognition of markup is done in the formatter (formatters/wakka.php). i am no expert for regexps too, but wouldn't the first or catch too much? --nilslindenberg
===integration into existing site===
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
===documentation===
documentation on the site here seems . . . fragmented i think is the best word. admin features are the example i'll use cuz it was my big hurdle. at this point i've only been able to find that the account created at install is the admin, and as site owner i should give access to that account to the people that i want to admin the site. is there more to it than this?
~&you can add usernames to the admin-list, if you don't want to share the admin-account. specify multiple wiki names separated by commas e.g: jsnx, hendrikmans, cooljoeadmin in the wikka.config.php in "admin-users" (see configurationoptions). admins can see, edit and delete any page, even if they are set to private.
searching for "admin features" yeilds over 100 entries. there's nothing in categorydocumentation detailing admin features, and the page wikkafeatures mentions several admin features that have neither further explanation nor links.
~&will be changed, but not today :)
on top of all this, searching acl reveals **one page** that just mentions acl more in passing. the page with category instructions is also a little under informed. you'd think that after following 2 step instructions that it'd work.
~&i think you mean aclinfo and wikicategory? if you have questions about a documentation-page, please leave a comment about that on the page. we can only make it better if we know what is not understandable. remember that this is a wiki :)
this page is another example. i started reading it the other night looking for something specific but by the time i finished reading it, i had about 6 different things i felt like commenting on. it's so long tho that i felt my comments would be missed so i didn't bother. rather than piled on one after the other, after a certain age, each of these subjects should be broken off to their own page in a categorysuggestionbox and listed here. (i mean this is a wiki and space isn't necessarily at a premium) this would make it easier to find and contribute to a specific topic. if a search produces this page as a result, the initial impression is that the search was really messed up hitting "suggestionbox" with my search terms.
anyway... the suggestion? organizing documentation should be the priority. this site looks quite nice. it's a shining example of how wikka works when beat into perfect shape. but the site i installed looked and acted nothing like this...
~&yes, we can and should organize the documentation better (and some other parts of this wiki). we will move it to a new subdomain (see documentationlanguagelinking) and after that we can bring it in better shape. but don't forget that this is a wiki and you have the right to participate :) --nilslindenberg
~~&does this mean that if i go ahead and make a "category suggestion box" and split this pages into seperate doco's that it won't step on people's toes? i think this would be good and don't mind doing that bit of work - but don't want to annoy too many people [espec. seeing as i am quite the newbie here...] -- kiltannen
~~~&i say; simply start and wait for the reactions. thats how i do it, most of the time ;) --nilslindenberg
===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:
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
===sending 403 headers===
(related to the //search engine results inflation// item below)
for pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //you aren't allowed to read this page// message - a http header like the following:
%%(php) header('http/1.0 403 forbidden');%%
-- dartar
~& oh, and maybe 404 headers for missing pages (which would help prevent se from spidering links to non existing pages)? -- dartar
===numbers as page names?===
i'm curious about the wikka convention that numbers cannot be page names. i'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature i'd definitely suggest.
btw, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
thx, robertdaeley
~& agreed, we should drop this restriction. numbers in page names might also be useful to use wikka as a [[wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[socialsoftware social software]] community. robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: jwcalendarwithpagecreation -- dartar
===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
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
~~& 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
==wikka markup inside tables==
- i think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - richardterry
~&richard, thanks for the feedback. it is on my agenda to look at another solution for tables. my plan is to allow straight html table syntax after running it through the "safehtml" checker. but i need to check that there are no security risks with this first. also, i'll take a peak at your suggestion too. -- jsnx
~&check out my proposal for an extended tableaction which does provide this. (tableaction is intended as a preliminary solution until we have table markup.) --javawoman
===robot friendly pages===
right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. it'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --barkerjr
~&ah, maybe this is why a now non-existent page that i deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --gmbowen
~&see robotfriendly. --dotmg
=== //kant-en-klaar// code blocks ===
a micro-idea before going to bed. we all know it's a bad idea to copy code blocks from the formatted version of a page.
if i want to test some freshly posted code, here's what i have to do:
~1) scan the page for the chunk of code i want to save (this can be pretty difficult on long source pages with no syntax highlighting);
wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
see grabcodehandler for a first proposal -- dartar
===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"))
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
(the following was copied from a comment on modrewrite -- javawoman)
//hi, i discovered that the default .htaccess included did not work for my setup up. i needed to include ""rewritebase"" /directory/ as well since wikka is installed in a subdirectory. i hope this helps anyone having trouble getting wikka to work.
the installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""rewritebase"" statement to take care of this. --javawoman
===separation of wakka class from wikka.php===
i use wikka as wiki engine of [[http://diantn.free.fr my page]].
imo, the wikka.php file is too big to be one single file. i suggest that we separate the wakka class into new file, say wakka.class.php
and then in the wikka.php, e.g at line where the wakka class previously located, simply we put:
include ('wakka.class.php');
-- din
~&din, this is a //very// good idea. i fact, the idea had crossed my mind already, but thanks for the reminder. :) indeed, a class belongs in a file of its own. --javawoman
~~&maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --nilslindenberg
~~~&with my current proposed structure on wikkacodestructure, it would go into the library folder; classes that are shared, into library/common. i prefer a //functional// separation rather than one based on coding format. --javawoman
===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):
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
===save pages to pdf format===
(copied from wikkadevelopment --nils)
page output to an adobe pdf file using fpdf.
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:
~&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
is there a way to include a target in a link, so that the link opens in a new window?
--gregorlindner
===signature===
//(copied from wikkafaq, but perhaps better at wantedformatters? --nilslindenberg)//
does wikka support automatic user signatures in pages (not comments)? i need some code so that users don't need to enter their username and time/date when they are working on a page in threadmode. i've searched in the docs, but i could not find anything about this, any ideas?
-- jeroenjansen (2005-01-28 11:35:43)
~& jeroen, there is a hack for automatically adding a user's signature in wakkawiki posted by nickk on his [[http://wakkawiki.de/nickk homepage]]. it should be easy to adapt to wikka. -- dartar
~~& dartar, just saw your reply. thanks for the hint! --jeroenjansen
=== 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
=== create rewrite rules on install ===
~//copied from comment on wikkainstallation --javawoman//
since i installed wikka in a subdirectory under the domain root i needed to add the following to the .htaccess file just under """rewriteengine on""":
""rewritebase"" /subdirectory/
devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-- karmatester (2005-01-26 06:52:07)
=== image dimensions ===
the [[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
~~~¬ed. 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
===clearing acls===
there should be a button on the acl page to "reset acls to default". what this would do is delete the record for the current page from the acls table. there is a distinction between setting the acls to the sites default values and not having acls defined for a page. if the acls are set and the default values get changed, the page will remain at the set values. however, if no acls are defined, the page will always use the default values.
to help show the distinction, there should be a visual indicator on the acl handler page which states whether the page has acls defined or is using the site's default values. basically, just check for a record in the acls table for the current page, and display a message accordingly. -- jsnx
== user registration control ==
it would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (or at least the configurable option to check for only one email/one account.)
it should also then be easier (i would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful aclswithusergroups hack that christian created to make a list of banned users by username. yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --movielady
~&you know how many testusers my wikka already has? *g* this should do the job (this time no config option, sorry jw :)
function existsemail($email)
$query = "select count(email)
from ".$this->config['table_prefix']."users
where email='".mysql_real_escape_string($email)."'";
if ($r = $this->query($query))
return ($count > 0) ? true : false;
~&place this function in wikka.php right after function userwantscomments(). and change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "password too short.";
else if (strlen($password) < 5) $error = "password too short.";
else if ($this->existsemail($email)) $error = "you already have a username.";
~&--nilslindenberg
~~& lol i can imagine. thanks so much for this - i'll try it out this evening. --movielady
~& speaking of registration control, note to self: make a configuration option to turn off new account registrations. some sites might be private and not want people registering. admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- jsnx
~~& (you saw userregistration by nils? i think it, or something like it, should be standard. mike)
~~~& doh! i somehow missed that. that's pretty much what i had in mind. nice job, nils! :) -- jsnx
~~~~&thank you. about your admin-adding-user case: that's an addition to useradmin, not for usersettings. --nilslindenberg
~~~&there's also code around that uses gd & that could be built onto nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. ultimately, as the bots become more sophisticated i think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what i mean (i like the simplicity of the first version in the second example). -- gmbowen
~~~~&yes, "captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). add a sound equivalent? well, there are people who are deaf **and** blind. are we going to deny them access to our wikis? i'm not in favor of making wikka **in**accessible when we should be working towards making it **more** accessible. --javawoman.
=== rss options ===
it would be wonderful to be able to choose what kind of rss feed is created for a page. for example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --movielady
=== 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
~¬ed - good suggestion. --javawoman
=== language file ===
i would be nice to see all phrases put into a single file. this would allow to translate the wiki in a few hours without changes every single file.
~&look at dotmgs approach at wikkainternationalization. but at least it should work for languages in the range of the "normal" (ascii?) code. if you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --nilslindenberg
~~&the most flexible and powerful way to support i18n is still gettext which is supported by php. if we go in that direction (likely), manually creating a "language file" is needless work since gettext does all that automatically for you. and it supports options for handling plurals and such which simple string-to-string language files cannot handle. the problem is that code needs to be written in a way to properly be able to use gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any html markup (actually this is true for simple laguage files as well). currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --javawoman
=== 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!";
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
===finally using cvs?===
i apologize since this idea has been suggested before, and i believe the developers are working to implement it already. however, with the beta of 1.1.6.0 released, i think it would be a good time now to start using cvs. this allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. in addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
also, i am willing to help with the cvs migration process if needed and help anyone who is interested in learning how to use cvs.
-- mikexstudios
~&there is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. just has to be updated --nilslindenberg
~~&actually, nils, we need a lot more than "just updating" the cvs at sourceforge. we need to integrate cvs in our development process - and develop a process for doing so. that requires a bit of planning... :) and while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with cvs specifically, so a bit of study will be required before we can start planning. help with learning how to use cvs //well// from someone who has experience with it would certainly be welcome, mike! thanks for the offer. --javawoman ''(reading manuals....)''
~~~& the "just was meant as an addition to existing ("of course" would have been better, though :). i just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case mike does not no. it is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --nilslindenberg
~~~~& hi nils. actually, i did find wikka's cvs repository at sf weeks ago, but i forgot to mention it in my above post. javawoman pretty much echoed my thoughts. we need to actively use cvs/update it constantly as changes are made. i run a project called [[http://xcomic.sourceforge.net xcomic]] that uses sourceforge's cvs a lot, so i have some experience with that. in addition, i recently set something up for my project that i think will be pretty cool if wikka decides to really use cvs: a commit mailing list. anytime someone makes a change to the cvs (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). in any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --mikexstudios
~~~~~&mike, i for one would welcome your insights in using cvs. both dartar and i have some ideas about how we want it set up - but no experience in doing so (in cvs). may i suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? for this type of thing i think that would be the best medium to discuss thoughs and methods. i like the idea of a commit mailing list. --javawoman
===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
===local links===
it would be nice if a link to the same host as the wikka install was not flagged as 'external'. i've added a 'hack' to my personal page: kickthedonkey. works fine here.
--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...
- 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''
===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
===online editing of mindmaps would be great===
(copied from sourceforge.net --nilslindenberg)
it would be great, if users should work together on mindmaps.
maybe by downloading/ open with freemind and then having a possiblity to save changes in freemind directly back to the online mindmap.
===how to format code to get two % characters without space together?===
i want to produce a code sample page in wikka with dos batch code. the code syntax requires two percent characters together to markup a variable. example: % %variable% % (without the spaces). wikka always tries to format the text as code, even if i format the dos code inside a code block, even if i %% marked it as code with two percent characters like this here%%
is there a solution? i could not find a literal entity for "percent"
''you could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. see: %%some text with %% embedded in it%%
but it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (and how do you markup wiki markup as **code**?) -- javawoman''
how about the € (euro) symbol? or is it to new? --nilslindenberg
''the main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. and it might occur in code as well (imagine a sample conversion routine). wiki markup should be easy to type. so we need a symbol (or sumbol combination, maybe), that's:
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of apl!)
the **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). maybe we should do a search (google?) to check whether **!!** or a combo is actually an operator in any language.
-- javawoman''
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:
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?:
else if ($thing == ""¹¹")
$timestamp = $wakka->getpagetime(); //hopefully this function returns the right format?
return (++$trigger_deleted % 2 ? "<del datetime=\"$timestamp\">" : "</del>");
--nilslindenberg
working on a test installation, i found the user setting "show comments by default" did not work. testing it here, i found it doesn't work here, either.
haven't dug in the code yet to find where this should happen (but will).
i'm quite happy with wikka's capabilities out of the box - good starting point! :) i'll likely stay with it - but i'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
great work! javawoman
it does work.... just not as might be expected. comment preference is stored for each page as you browse the wiki. so, if you browse a few pages with comments not showing, it remembers this. then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
try this:
- browse to usersettings and check off "show comments by default" and click "update settings".
- now **close all browser windows**
- open back up your browser and go to the same pages......
- comments are now showing by default, right?
- jsnx
right. i see it does work. ;) somewhat, um, counterintuitive, though. so i guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). that would, i think, be more in line with expected behavior. possible? (i haven't looked at that area of the code yet.) --javawoman.
===language support===
i was searching almost whole site to check what kind of languages are supported by this wiki. i was unsuccessful. is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
thanks mdd
=== 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
== question: note? ==
it is me again! what is the function of the "please add a note on your edit" - field? again and again: keep on the good work.
-- skywalk
~& this note is shown in some lists like the recentchanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --dreckfehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --georgepetsagourakis
=== 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
the edit page handler seems to convert spaces to tabs throughout the entire document, including code blocks.
**from edit.php**
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
===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
categorywikka
categorydevelopment
Deletions:
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
~-SuggestionsArchive for resolved suggestions
**Issues often asked for**
~-[[CategorySystemOverhaul Categories]]
~-[[DateAndTimeFormat Date/Time]]
~-[[WikkaFilters Wikka Exporting/Importing]]
~-[[WikkaInternationalization Internationalization/Localisation]]
~-[[WikkaOptimization Optimization]]
~-[[WikkaToPdf PDF-Export]]
~-[[SectionEditing Section Editing]]
~-[[WikkaSpamFighting Spam (and related issues)]]
~-[[TableofcontentsAction Table of content (TOC)]]
~-[[WikkaTables Tables]]
~-[[WikkaFolksonomy (Technorati) tags & related]]
~-TemplateSystem
~-UserMap
~-[[WikkaWorkarounds Workarounds for specific platforms]]
===Generate ID in forms; allow class===
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made it into a semi-spec.//
Every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
In addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). So the ##""FormOpen()""## method should also:
--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");
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-adress 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
===Single-click restore of previous versions===
//copied from WikkaBugs - this is a suggestion, not a bug --NilsLindenberg//
Single-click restore of previous versions (without copying/pasting). -Sam
~& ''Yes, this will be implemented at some point.'' - JsnX
~~&I should point out that there is an alternative to copying/pasting.
~~~& Go to the revisions page.
~~~& Click the date and time link that you would like to revert back to.
~~~& Click the 'Re-edit this old revision' button.
~~~& Click the 'Store' button.
In any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. While our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own Wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
The only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. There are two problems with this:
~1)Users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)Code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
Copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. If any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of Wikka). That leaves us with finding an escape method that's easy for users to implement.
There are two requirements for an "escaped" ""%%"" then:
~1)Easy to remember and apply by end users
~1)Not (not likely) part of the syntax of any language
One option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. A good candidate might be **DOUBLE_PERCENT** - it's easy enough to remember and easy to implement:
The formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to GeSHI for rendering; the grab code handler could just as easily replace it before making the code block available for download.
Thoughts anyone?
--JavaWoman
~&It's a good idea, but: You are sure DOUBLE_PERCENT is no reserved word in a language? Or unlikely to comme up in a code? --NilsLindenberg
~~&Try googling for 'DOUBLE_PERCENT': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). It's certainly not a reserved word in any of the languages GeSHi currently has support for, going by the language files it comes with. There's no way to be 100% certain but it seems to be a pretty safe bet. --JavaWoman
===Preview===
A doubleclick on a page in the preview should lead to "re-edit" of the text. --NilsLindenberg
~& Good point, agreed -- DarTar
Another point: The access-key for "re-edit" is alt+p at the moment. Wouldn't alt+e be more logic? --NilsLindenberg
===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
===Color Formatting===
The current color formatting isn't very wiki like. Altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
this regex syntax is lifted from a ""UseMod"" Wiki patch.
%%s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
I am by NO means a regex expert, but it seems that this should do the deal... I'm just not sure where it would go. By using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--MonstoBrukes
~&Please take a look at WikkaExtensibleMarkup --NilsLindenberg
~~&I looked at it. what point specifically did you intend i take from it?
~~~& JavaWoman had a proposal about a color-markup there. I think its the better place for the discussion. The recognition of markup is done in the formatter (formatters/wakka.php). I am no expert for regexps too, but wouldn't the first or catch too much? --NilsLindenberg
===Integration into existing site===
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
===Documentation===
Documentation on the site here seems . . . fragmented I think is the best word. Admin features are the example i'll use cuz it was my big hurdle. At this point I've only been able to find that the account created at install is THE admin, and as site owner i should give access to that account to the people that i want to admin the site. Is there more to it than this?
~&You can add usernames to the admin-list, if you don't want to share the admin-account. Specify multiple wiki names separated by commas e.g: JsnX, HendrikMans, CoolJoeAdmin in the wikka.config.php in "admin-users" (see ConfigurationOptions). Admins can see, edit and delete any page, even if they are set to private.
Searching for "Admin Features" yeilds over 100 entries. There's nothing in CategoryDocumentation detailing admin features, and the page WikkaFeatures mentions several admin features that have neither further explanation nor links.
~&Will be changed, but not today :)
On top of all this, searching ACL reveals **one page** that just mentions ACL more in passing. The page with Category instructions is also a little under informed. You'd think that after following 2 step instructions that it'd work.
~&I think you mean ACLInfo and WikiCategory? If you have questions about a documentation-page, please leave a comment about that on the page. We can only make it better if we know what is not understandable. Remember that this is a wiki :)
This page is another example. I started reading it the other night looking for something specific but by the time i finished reading it, i had about 6 different things i felt like commenting on. It's so long tho that i felt my comments would be missed so i didn't bother. Rather than piled on one after the other, after a certain age, each of these subjects should be broken off to their own page in a CategorySuggestionBox and listed here. (I mean this is a wiki and space isn't necessarily at a premium) This would make it easier to find and contribute to a specific topic. If a search produces this page as a result, the initial impression is that the search was really messed up hitting "suggestionbox" with my search terms.
Anyway... the suggestion? Organizing documentation should be THE priority. This site looks quite nice. It's a shining example of how wikka works when beat into perfect shape. But the site I installed looked and acted nothing like this...
~&Yes, we can and should organize the documentation better (and some other parts of this wiki). We will move it to a new subdomain (see DocumentationLanguageLinking) and after that we can bring it in better shape. But don't forget that this is a wiki and you have the right to participate :) --NilsLindenberg
~~&Does this mean that if I go ahead and make a "Category Suggestion Box" and split this pages into seperate doco's that it won't step on people's toes? I think this would be good and don't mind doing that bit of work - but don't want to annoy too many people [espec. seeing as I am quite the newbie here...] -- KiltanneN
~~~&I say; simply start and wait for the reactions. Thats how I do it, most of the time ;) --NilsLindenberg
===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:
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
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
===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
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
~~& 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
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
===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"))
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
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
include ('Wakka.class.php');
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
===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):
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
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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:
~&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
Is there a way to include a target in a link, so that the Link opens in a new window?
--GregorLindner
===Signature===
//(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)//
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
=== 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
=== Create rewrite rules on install ===
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-- KarmaTester (2005-01-26 06:52:07)
=== Image dimensions ===
The [[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
===Clearing ACLs===
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
function ExistsEmail($email)
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
return ($count > 0) ? TRUE : FALSE;
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
=== RSS options ===
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
=== 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
=== Language file ===
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
=== 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!";
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
===Finally using CVS?===
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
===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
===Local links===
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--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...
- 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''
===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
===Online editing of mindmaps would be great===
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
===How to format code to get two % characters without space together?===
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
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:
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?:
else if ($thing == ""¥¥")
$timestamp = $wakka->GetPageTime(); //hopefully this function returns the right format?
return (++$trigger_deleted % 2 ? "<DEL datetime=\"$timestamp\">" : "</DEL>");
--NilsLindenberg
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
===Language support===
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
=== 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
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
~& this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
=== 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
The edit page handler seems to convert spaces to tabs throughout the entire document, including Code blocks.
**From edit.php**
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
===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
CategoryWikka
CategoryDevelopment
Revision [8240]
Edited on 2005-05-17 09:25:09 by JavaWoman [extending Form ID suggestion with class]Additions:
===Generate ID in forms; allow class===
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made it into a semi-spec.//
Every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
In addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). So the ##""FormOpen()""## method should also:
~-accept an //optional// parameter specifying a class and - if specified - use this to generate a class attribute (and no class attribute if not specified).
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made it into a semi-spec.//
Every form really should have an ##**id**## (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
In addition, some forms really need to have a ##**class**## attribute (as well); the button-form for the grabcode handler is a good example: if you have a number of forms on a page that all should have the **same** styling, a ##**class**## would provide the 'hook' rather than the ##**id**## (which should still be there). So the ##""FormOpen()""## method should also:
~-accept an //optional// parameter specifying a class and - if specified - use this to generate a class attribute (and no class attribute if not specified).
Deletions:
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made uit into a semi-spec.//
Every form really should have an id (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
Additions:
===Generate ID in forms===
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made uit into a semi-spec.//
Every form really should have an id (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
~-accept an //optional// parameter specifying an id and - if specified - use this to generate an id attribute
~-if the parameter is not specified, generate one using some algorithm to ensure it will be unique on the page (possibly using all provided parameters to create a hash, supplemented with a sequence number); only problem is this id might change when adding / inserting another form into a page but that could be worked around by actually specifying an id.
//I know we've dicussed this multiple times but could not find an actual suggestion; I've made uit into a semi-spec.//
Every form really should have an id (attribute) to provide a 'hook' for styling (and JavaScript, if desired). We have a ##""FormOpen()""## method in the core that should be used to generate the opening ##form## tag (and its counterpart ##""FormClose())""## - but this method does not generate an ID nor accept a parameter to create one. It should be able to do both:
~-accept an //optional// parameter specifying an id and - if specified - use this to generate an id attribute
~-if the parameter is not specified, generate one using some algorithm to ensure it will be unique on the page (possibly using all provided parameters to create a hash, supplemented with a sequence number); only problem is this id might change when adding / inserting another form into a page but that could be worked around by actually specifying an id.
Additions:
~&See also WikkaWithphpBB --JavaWoman
Additions:
~~~& 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
Additions:
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
Deletions:
Additions:
===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).
+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):
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
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).
+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):
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Additions:
~& 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
~~& 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
Deletions:
~~& ''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
Additions:
~~&Try googling for 'DOUBLE_PERCENT': **this** page comes up on top, with 8 others referring to the name being used (in lowercase) in two programs, as (part of) function names (i.e., not as reserved words). It's certainly not a reserved word in any of the languages GeSHi currently has support for, going by the language files it comes with. There's no way to be 100% certain but it seems to be a pretty safe bet. --JavaWoman
Revision [7734]
Edited on 2005-04-29 18:01:24 by NilsLindenberg [copied two suggestions from WikkaBugs]Additions:
===Storing the IP-adress 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
===Single-click restore of previous versions===
//copied from WikkaBugs - this is a suggestion, not a bug --NilsLindenberg//
Single-click restore of previous versions (without copying/pasting). -Sam
~& ''Yes, this will be implemented at some point.'' - JsnX
~~&I should point out that there is an alternative to copying/pasting.
~~~& Go to the revisions page.
~~~& Click the date and time link that you would like to revert back to.
~~~& Click the 'Re-edit this old revision' button.
~~~& Click the 'Store' button.
//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
===Single-click restore of previous versions===
//copied from WikkaBugs - this is a suggestion, not a bug --NilsLindenberg//
Single-click restore of previous versions (without copying/pasting). -Sam
~& ''Yes, this will be implemented at some point.'' - JsnX
~~&I should point out that there is an alternative to copying/pasting.
~~~& Go to the revisions page.
~~~& Click the date and time link that you would like to revert back to.
~~~& Click the 'Re-edit this old revision' button.
~~~& Click the 'Store' button.
Revision [7732]
Edited on 2005-04-29 17:50:27 by NilsLindenberg [another preview suggestion + reply to jw]Additions:
~&It's a good idea, but: You are sure DOUBLE_PERCENT is no reserved word in a language? Or unlikely to comme up in a code? --NilsLindenberg
Another point: The access-key for "re-edit" is alt+p at the moment. Wouldn't alt+e be more logic? --NilsLindenberg
Another point: The access-key for "re-edit" is alt+p at the moment. Wouldn't alt+e be more logic? --NilsLindenberg
Additions:
~&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
Deletions:
-- KiltanneN
Additions:
~~&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
Revision [7690]
Edited on 2005-04-28 19:44:55 by JavaWoman [missing sig added; item moved to archive]Additions:
--JavaWoman
=== DB Export ===
=== DB Export ===
Deletions:
I didn't know where to put this, so here goes.
I've been adapting a script that uses GD to make an image of some text using a specified font. I'll post it at FontActionInfo
BTW - The work you've done - especially with CSS styling - is very, very good. Keep it up ;-)
~&We have a nice page called CodeContributions and the "Category User Contributions" (without the space) -- NilsLindenberg
== DB Export ==
Revision [7688]
Edited on 2005-04-28 19:40:32 by JavaWoman [some items still under discussion moved back here from archive]Additions:
===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
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
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
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
Additions:
%%(apache)RewriteCond %{REQUEST_URI} !=/favicon.ico
~&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
~&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
Deletions:
Revision [7644]
Edited on 2005-04-26 14:44:30 by JavaWoman [possible workaround for ""%%"" in code blocks]Additions:
===""%%"" in code blocks: a possible workaround===
In any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. While our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own Wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
The only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. There are two problems with this:
~1)Users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)Code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
Copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. If any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of Wikka). That leaves us with finding an escape method that's easy for users to implement.
There are two requirements for an "escaped" ""%%"" then:
~1)Easy to remember and apply by end users
~1)Not (not likely) part of the syntax of any language
One option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. A good candidate might be **DOUBLE_PERCENT** - it's easy enough to remember and easy to implement:
The formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to GeSHI for rendering; the grab code handler could just as easily replace it before making the code block available for download.
Thoughts anyone?
In any wiki displaying code which //contains// that wiki's markup to indicate a code block will be a problem. While our "code" markup with a double percent is not likely to be a part of the syntax of any popular language other than our own Wikka markup (though it likely is part of the syntax of //some// language) it could still easily occur in some code comment and thus throw the formatter off.
The only //generic// solution is to somehow "escape" ""%%"" in a code block so it isn't seen by the formatter as the end of the block. There are two problems with this:
~1)Users must remember to "escape" the ""%%"" (although not doing that will be easily visible as a problem in rendering code)
~1)Code with "escaped" ""%%"" can no longer be copied from the page source as is, while copying from the rendered code already has the disadvantage of losing some of the formatting (e.g, tabs being replaced by spaces)
Copying of code has been made a lot easier on this site with the "grab code" handler (//still a beta feature//. If any method of escaping ""%%"" in code is used, and the grab code handler could "unescape" before delivering the code, the second problem would be basically solved (provided we actually distribute the handler with a coming version of Wikka). That leaves us with finding an escape method that's easy for users to implement.
There are two requirements for an "escaped" ""%%"" then:
~1)Easy to remember and apply by end users
~1)Not (not likely) part of the syntax of any language
One option that came up during a #wikka conversation was to just replace ""%%"" in code with a keyword. A good candidate might be **DOUBLE_PERCENT** - it's easy enough to remember and easy to implement:
The formatter could detect this very simply and replace it by ""%%"" before feeding the content of a code block to GeSHI for rendering; the grab code handler could just as easily replace it before making the code block available for download.
Thoughts anyone?
Additions:
~& Good point, agreed -- DarTar
Revision [7585]
Edited on 2005-04-25 20:05:27 by NilsLindenberg [often asked issues to the top, suggestion, deleted now unnecessary text about fpdf]Additions:
**Issues often asked for**
~-[[CategorySystemOverhaul Categories]]
~-[[DateAndTimeFormat Date/Time]]
~-[[WikkaFilters Wikka Exporting/Importing]]
~-[[WikkaInternationalization Internationalization/Localisation]]
~-[[WikkaOptimization Optimization]]
~-[[WikkaToPdf PDF-Export]]
~-[[SectionEditing Section Editing]]
~-[[WikkaSpamFighting Spam (and related issues)]]
~-[[TableofcontentsAction Table of content (TOC)]]
~-[[WikkaTables Tables]]
~-[[WikkaFolksonomy (Technorati) tags & related]]
~-UserMap
~-[[WikkaWorkarounds Workarounds for specific platforms]]
>>
{{feedback}}
::c::
===Preview===
A doubleclick on a page in the preview should lead to "re-edit" of the text. --NilsLindenberg
~-[[CategorySystemOverhaul Categories]]
~-[[DateAndTimeFormat Date/Time]]
~-[[WikkaFilters Wikka Exporting/Importing]]
~-[[WikkaInternationalization Internationalization/Localisation]]
~-[[WikkaOptimization Optimization]]
~-[[WikkaToPdf PDF-Export]]
~-[[SectionEditing Section Editing]]
~-[[WikkaSpamFighting Spam (and related issues)]]
~-[[TableofcontentsAction Table of content (TOC)]]
~-[[WikkaTables Tables]]
~-[[WikkaFolksonomy (Technorati) tags & related]]
~-UserMap
~-[[WikkaWorkarounds Workarounds for specific platforms]]
>>
{{feedback}}
::c::
===Preview===
A doubleclick on a page in the preview should lead to "re-edit" of the text. --NilsLindenberg
Deletions:
~-WikkaSpamFighting for spam-related issues
~-WikkaWorkarounds for specific platforms
~-WikkaOptimization
>>{{feedback}}::c::
===Using FPDF with Wikka===
Not so much a suggestion, more a request although it may be useful to others.
I have been using FPDF from [[http://www.fpdf.org FPDF ]] to export content from a database to pdf files.
I would like to extend my usage of FPDF to wikka by adding a hyperlink to the top of my wikka pages which would allow me to post the page tag or page id to the FPDF script for exporting the content into a pdf file.
The link would be in the form similar to
http://www.mysite.com/script.php?id=
Can anyone tell me how I can extract the page tag or page id from the wikka_pages table in order to do this.
====Moved Discussions====
~- Date- and Time-format: DateAndTimeFormat
~- For the discussion on tables in Wikka, take a look at WikkaTables.
~~&See also TableAction for a preliminary solution. --JavaWoman
~- Category Support: moved to CategorySystemOverhaul
~- Wikka Exporting/Importing: Just added a few thoughts [[WikkaFilters here]] -- DarTar
~- Give control over HTML (using a templating system): Moved to TemplateSystem --NilsLindenberg
~- Editable header/footer: Moved to TemplateSystem --JavaWoman
~- I have copied the proposal for a user map form Category Users to UserMap. --NilsLindenberg
~- TOC/ Table of content: see TableofcontentsAction.
~- Spam-issues: moved to WikkaSpamFighting
~- Support for (Technorati) tags: See WikkaFolksonomy for more details
~- [[SectionEditing Section Editing]] --NilsLindenberg
Additions:
~~&Does this mean that if I go ahead and make a "Category Suggestion Box" and split this pages into seperate doco's that it won't step on people's toes? I think this would be good and don't mind doing that bit of work - but don't want to annoy too many people [espec. seeing as I am quite the newbie here...] -- KiltanneN
~~~&I say; simply start and wait for the reactions. Thats how I do it, most of the time ;) --NilsLindenberg
~~~&I say; simply start and wait for the reactions. Thats how I do it, most of the time ;) --NilsLindenberg
Deletions:
~~~&I say; simply start and wait for the reactions. Thats how I do it, ost of the time ;) --NilsLindenberg
Additions:
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.
~- [[SectionEditing Section Editing]] --NilsLindenberg
~- [[SectionEditing Section Editing]] --NilsLindenberg
Deletions:
Instead of a full blown section editing implementation why not just implement a tag like '<WikiPage>' which inserts the contents of WikiPage (no comments) at the markers location. <WikiPage x> would insert the first x lines of the WikiPage into the current page. And/or <WikiPage Header> would pull just the section of the page which is demarked by Header and EOP or next header. Such sections can be inserted in a special color/block/font/whatever and automatically link back to the original page for editing. The goal is to provide better editing granularity and readability on pages which have lots of information density. Could also be used to mimic blog functionality. -KarmaTester
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.
===Section Editing ===
- http://c2.com/cgi/wiki?SectionEditing
- It makes allows you to flow and edit much quicker.
- Each topic should have a corresponding edit button. This allows your to edit each section with out breaking your flow.
- http://www.splitbrain.org/dokuwiki/wiki:section_editing
Revision [7556]
Edited on 2005-04-24 18:43:01 by NilsLindenberg [reply to KiltanneN+ phpmyedit-discussion copied]Additions:
~~~&I say; simply start and wait for the reactions. Thats how I do it, ost of the time ;) --NilsLindenberg
Deletions:
I've set up a demo of [[http://www.jsnx.com/wikka-dev/SuggestionBox phpMyEdit running within Wikka]]. This would be useful for anyone wanting to directly interact with MySQL tables from a Wikka page. -- JsnX
~&I assume this is meant for admins only but ... Could you add some explanation? I looked but don't have a clue how to use it. What are the radio buttons for, for instance? What's the "V" button at the top? The UI is very confusing. --JavaWoman
~~& Jsnx, that's interesting. I think the idea is worth consideration. I have used phpMyEdit as an interface to allow my users to store their profiles in the DB when I still was a MySQL newbie :) and it's true that it allows a number of tricky things (especially cross-reference between tables). So I think a plugin for integrating phpMyEdit within Wikka pages might be a nice extension. You probably know though that all the interface options can only be set by editing the source, or were you thinking of allowing some kind of admin access to the interface options? And be honest, are you thinking of phpMyEdit as a sort of replacement for my baby admin actions, aren't you?! In a sense this might be interesting, but it would really be unnecessary compared to what we can do by creating direct calls to the DB using core functions. Why heavily tweak an external script to do something wikka-like if we can already use something that only needs core functions? --- Moreover, when you perform operations on pages (like 'add', 'copy' or 'delete') you generally want to do something more complicated than just modify single records of the page table. Using phpMyEdit as a sort of proxy for a page admin action can lead to major inconsistencies in the page structure. --- And, JW, the "v" button is for filtering the table ;-) -- DarTar
~~~&DarTar, that's silly. The admin actions that you have developed are looking fantastic! I was never thinking of using phpMyEdit to replace your actions. I'm using phpMyEdit to interface with non-Wikka tables; I like to see the data shown from Wikka, and I also like being able to use Wikka formatting within the data. It might help if I gave an example of how I use phpMyEdit. [... I'll write an example later on ...] -- JsnX
~~~&Filtering? Well first it's not obvious, nor explained; but I just went back and tried pressing the "v" button - and I get three other mystifying buttons in return. Frankly, I don't want to use something as badly-designed as this. Shudder. DarTar, your Admin functions may need some refinement, but mystifying they are not. Let's stick with those, and build on them. Sorry, JsnX, but this doesn't get my vote. --JavaWoman
~~~~&Thanks for the comments. I expected there would be some reservations about including this in Wikka. I too have some reservations about phpMyEdit. However, with that said, I also find it to be a **very useful** tool which I will continue to use. It doesn't matter to me whether phpMyEdit is ever an official Wikka component because using it requires zero modifications to the Wikka code -- there will be no ongoing maintenance when upgrading to new Wikka versions. It's not my intention to support this, but if someone wants to use it, I'm happy to make my modified phpMyEdit version available. I'm proposing this as an official "unofficial Wikka add-on". :) -- JsnX
~&I am interested by the idea to interact with MySQL tables from a Wikka page. Would you please share the updated phpMyEdit code? --ChristianBarthelemy
~~&Yes, I plan to play around with it for a few more days, then I'll upload the code and some instructions. -- JsnX
~~~&Hi Jason, I am still interested to know more about this... --ChristianBarthelemy
~~~~&Check it out, PhpMyEdit. -- JsnX
~&Well, Jason, I do think it would help I you would explain what you are using this **for** (especially if not for Wikka administration); I'd also like to know then why you chose phpMyEdit and not another browser-based client - and why a browser-based client in the first place. I've only ever tried phpMyAdmin and found it lacking because it tends (tended) to work on single tables only. I quickly switched to "real" clients that are more powerful and allow me to build queries involving several tables if needed, so consistency can be maintained. I have a bunch of handy tools (for Windows), all free: for design, administration and maintenance. And though I do have phpMyAdmin available, I don't intend to use it. --JavaWoman
~~&My bet is that Jason's using it to fix the pages where I've (inadertently) submitted double percent signs as part of submitted code so that the history feature works properly. {grin} --GmBowen
~~~&LOL! But - "inadvertently"? Using double percent signs should be possible in code - and if not, that's a bug in Wikka, not your fault! (Not that I have a solution for that yet, though I have been thinking about that problem.) --JavaWoman
Revision [7249]
Edited on 2005-04-13 19:11:04 by JavaWoman [more consistent layout for better "scannability"]Additions:
===Font action===
//(copied from WikkaDevelopment --Nils)//
//(copied from WikkaDevelopment --Nils)//
//(copied from WikkaDevelopment --NilsLindenberg)//
===Signature===
//(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)//
=== Easy way of adding links ===
=== Create rewrite rules on install ===
=== Image dimensions ===
===Clearing ACLs===
=== RSS options ===
=== Embed a blurb from a news page into another page? ===
===Logging-out===
=== Backlinks ===
=== Language file ===
=== User names ===
===Finally using CVS?===
===List of special actions?===
===Allow spaces in pagetitle===
===User-defined formatting rules===
===Local links===
===Section Editing ===
===Compatibility & Installer===
===Handling the config===
===Markup for code not to be shown===
===Online editing of mindmaps would be great===
===How to format code to get two % characters without space together?===
===markup of diff pages===
===showing comments===
===Language support===
=== Problem: Scrolling in the search - field ===
=== Problem: Five Line Breaks ===
===Code block formatting===
===Various suggestions===
===Installation problem - UTF-8?===
===Add page link & other suggestions===
===Using FPDF with Wikka===
//(copied from WikkaDevelopment --Nils)//
//(copied from WikkaDevelopment --Nils)//
//(copied from WikkaDevelopment --NilsLindenberg)//
===Signature===
//(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)//
=== Easy way of adding links ===
=== Create rewrite rules on install ===
=== Image dimensions ===
===Clearing ACLs===
=== RSS options ===
=== Embed a blurb from a news page into another page? ===
===Logging-out===
=== Backlinks ===
=== Language file ===
=== User names ===
===Finally using CVS?===
===List of special actions?===
===Allow spaces in pagetitle===
===User-defined formatting rules===
===Local links===
===Section Editing ===
===Compatibility & Installer===
===Handling the config===
===Markup for code not to be shown===
===Online editing of mindmaps would be great===
===How to format code to get two % characters without space together?===
===markup of diff pages===
===showing comments===
===Language support===
=== Problem: Scrolling in the search - field ===
=== Problem: Five Line Breaks ===
===Code block formatting===
===Various suggestions===
===Installation problem - UTF-8?===
===Add page link & other suggestions===
===Using FPDF with Wikka===
Deletions:
(copied from WikkaDevelopment --NilsLindenberg)
==Signature==
(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)
== Easy way of adding links ==
== Create rewrite rules on install ==
== Image dimensions ==
==Clearing ACLs==
== RSS options ==
== Embed a blurb from a news page into another page? ==
==Logging-out==
== Backlinks ==
== Language file ==
== User names ==
==Finally using CVS?==
==List of special actions?==
==Allow spaces in pagetitle==
==User-defined formatting rules==
==Local links==
==Section Editing ==
==Compatibility & Installer==
==Handling the config==
==Markup for code not to be shown==
==Online editing of mindmaps would be great==
==how to format code to get two % characters without space together?==
==markup of diff pages==
==showing comments==
==Language support==
== Problem: Scrolling in the search - field ==
== Problem: Five Line Breaks ==
==Code block formatting==
==Various suggestions==
==Installation problem - UTF-8?==
==Add page link & other suggestions==
==Using FPDF with Wikka==
Additions:
~-TemplateSystem
~- Give control over HTML (using a templating system): Moved to TemplateSystem --NilsLindenberg
~- Editable header/footer: Moved to TemplateSystem --JavaWoman
~- Give control over HTML (using a templating system): Moved to TemplateSystem --NilsLindenberg
~- Editable header/footer: Moved to TemplateSystem --JavaWoman
Deletions:
//(moved to TemplateSystem --JavaWoman)//
~- using a templating system: Moved to TemplateSystem --NilsLindenberg
Additions:
//(moved to TemplateSystem --JavaWoman)//
Deletions:
Some of it has to be done in the actions files, and the menuitems in the config file. This means I can't safely allow users to edit them.
What I would like, is a system that allows easy creation of non-default headers/footers (so you can get a different menu in different parts of the site).
--OnkelJonas
~&You may find the following pages interesting: UserMenus, WikkaMenus. --NilsLindenberg
Additions:
~-SuggestionsArchive for resolved suggestions
Additions:
~& this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
~- TOC/ Table of content: see TableofcontentsAction.
~- Spam-issues: moved to WikkaSpamFighting
~- Support for (Technorati) tags: See WikkaFolksonomy for more details
~~&maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
~- TOC/ Table of content: see TableofcontentsAction.
~- Spam-issues: moved to WikkaSpamFighting
~- Support for (Technorati) tags: See WikkaFolksonomy for more details
Deletions:
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
===Support for (Technorati) tags===
I think it might be interesting to provide Wikka support for (Technorati) "**tags**". "Tags" in this context are simple keywords that help identify and categorize web content, in particular blog posts. Such keywords coupled with a ping system can be used by remote servers to retrieve fresh content for specific topics. See for instance how technorati.com aggregates fresh information about [[http://www.technorati.com/tag/wiki wikis]] from a number of sources.
[[http://www.technorati.com/help/tags.html More information on Technorati tags]]
~&Seems like we need to update our RSS (feed) implementation first... --JavaWoman
See WikkaFolksonomy for more details
==Stopping Spammers getting Google Juice==
//(moved to WikkaSpamFighting)//
this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
Revision [7239]
Edited on 2005-04-13 18:01:12 by NilsLindenberg [resolved suggestions moved, new entry "moved discussions" for disc. which are on extra-pages]Additions:
====Moved Discussions====
~- Date- and Time-format: DateAndTimeFormat
~- For the discussion on tables in Wikka, take a look at WikkaTables.
~~&See also TableAction for a preliminary solution. --JavaWoman
~- Category Support: moved to CategorySystemOverhaul
~- Wikka Exporting/Importing: Just added a few thoughts [[WikkaFilters here]] -- DarTar
~- using a templating system: Moved to TemplateSystem --NilsLindenberg
~- I have copied the proposal for a user map form Category Users to UserMap. --NilsLindenberg
~- Date- and Time-format: DateAndTimeFormat
~- For the discussion on tables in Wikka, take a look at WikkaTables.
~~&See also TableAction for a preliminary solution. --JavaWoman
~- Category Support: moved to CategorySystemOverhaul
~- Wikka Exporting/Importing: Just added a few thoughts [[WikkaFilters here]] -- DarTar
~- using a templating system: Moved to TemplateSystem --NilsLindenberg
~- I have copied the proposal for a user map form Category Users to UserMap. --NilsLindenberg
Deletions:
Hi folks,
trying to figure out how to change the date format displayed in Page History and Revisions to something more functional than the "Romance Daylight Time" I get in my wikka installation. Could someone point me in the right direction please? Thanks for a really good wiki btw!
--EgilHelland
In handlers/page/revisions.php replace
$output .= "<td> <a href=\"".$this->Href("show","","time=").urlencode($page["time"])."\">".$page["time"]."</a></td>";
with something like
$output .= "<td> <a href=\"".$this->Href("show","","time=").urlencode($page["time"])."\">".date("l dS of F Y h:i:s A",strtotime($page["time"]))."</a></td>";
in handlers/page/history.php replace
$output .= "<strong>Edited on <a href=\"".$this->Href("", "", "time=".urlencode($pageA["time"]))."\">".$pageA["time"]."</a> by ".$EditedByUser."</strong> <span style=\"color:#888;font-size:smaller;\">".$note."</span><br />\n";
with something like
$output .= "<strong>Edited on <a href=\"".$this->Href("", "", "time=".urlencode($pageA["time"]))."\">".date("l dS of F Y h:i:s A",strtotime($pageA["time"]))."</a> by ".$EditedByUser."</strong> <span style=\"color:#888;font-size:smaller;\">".$note."</span><br />\n";
See [[http://www.php.net/manual/en/function.date.php php documentation]] for details on the date() function.
I think it would be nice to add a function for this to the wikka-class and call it everywhere, where times are printed out - would make such things a bit easier (especially if there would be a ""$DefaultTimeFormat"" in the config-array).
--TimoK
~&Related to this topic: UserSettingsPanel --NilsLindenberg
~~&As I've mentioned before, what I think we really need is a setting in the configuration for date (and time) format which should then be used everywhere - we're really inconsistent now with every bit of code doing its own date/time formatting. The default for the configuration should then be the standard ISO format since it's non-ambiguous. --JavaWoman
===User map===
I have copied the proposal for a user map form Category Users to UserMap. --NilsLindenberg
==Give control over HTML (using a templating system)==
It would be nice to see a template engine in Wikka to give the users the full control over the HTML source. Smarty is always a good choice.
~& I would love to see Wikka adopt some type of template system. I think that its is sorely needed. Changing the look of Wikka requires tedious editing of php files, and alot of the time it is non-obvious where you need to go to edit such files. Another alternative to [[http://smarty.php.net Smarty]] could be [[http://wiki.ciaweb.net/yawiki/index.php?area=Savant Savant]]. --KickTheDonkey
~~&While I use and like Smarty very much (and it's quite fast), it's rather "heavy" for Wikka, I think. I just had a look at Savant2 which I hadn't heard of before. It looks like a good fit, is lightweight and easy to use. A templating system like this would also provide much more flexibility for Wikka admins to have control over page structure and layout. I'll want to play with it some (in combination with Wikka), but my first impression based on documentation and code is very favorable. More when I've had a chance to exercise it. --JavaWoman
~~~&I'm sorry JW, but what do you mean by Smarty being rather "heavy" for Wikka? Resource-wise? Hard to use / implement? Difficult for the end user? -- FernandoBorcel
~~~~&Fernando, I mean it's "heavy" in two respects, actualy: 1) in terms of code size (currently Smarty is 137K compared to Wikka's 524K - zipped - while for instance Savant is only 39K); 2) in terms of usability - while it's quite powerful, there is a rather steep learning curve for those who've never worked with templates; Savant is simpler and much easier to learn, and looks still quite flexible. I'm not sure about resource usage, but I suspect that in that respect it might be heavier than Savant as well. We'd like to keep Wikka easy to use both for WikiAdmins and for WikiUsers. I still have to actually try Savant with Wikka, but from what I've see so far it fits our profile better, I think. Anyway, before we go forward with something like this, more research will be needed. --JavaWoman
~~~~~&I would propose using a 'lite' templating engine such as [[http://www.phpxtemplate.org/ XTemplate]], it's a simple tag language, it keeps most of the logic in the PHP and hey, I maintain it. I use Wikka for at least 3 sites including the XTemplate site - so I'm about to help integrate and develop with Wikka. Oh and by the way, it's only 28k including the comments ;) XTemplate in combination with a DatabaseAbstraction layer such as [[http://adodb.sf.net ADODB]] would go a long way to making Wikka more maintainable than it is at present. -- JeremyCoates
==Idea for Category Support==
moved to CategorySystemOverhaul, it is the better place, thanks DarTar
--ArpY
~& ArpY, take a look at CategorySystemOverhaul for an open discussion on how to improve the category system -- DarTar
==Standard date and time format==
Although I'm all for using the ISO date/time format as we see in the timestamp of the footer of every page, I note that several other parts of Wikka use different date/time formats. I'd like to see an approach where this is standardized.
Proposal:
~-Define date-time format (or separately date and time, as well as a way to combine them) in the configuration; use the ISO format as a default (in the initial configuration, as well as when no format is defined in the config).
~-Use this format wherever date and/or time are formatted.
~-Make using the configured formats a requirement for every Wikka extension (that displays date/time information) to be included with the distribution.
I realize that in principle it's possible to pick up formats from a locale but for a Wikka targeted at an international audience this may not be the best approach, and for a Wikka with a "local" audience it may not be either if it's hosted on a (public) server outside that country - hence the idea to define a format in the configuration.
--JavaWoman
~''Agreed -- DarTar''
==Tables ==
For the discussion on tables in Wikka, take a look at WikkaTables.
~&See also TableAction for a preliminary solution. --JavaWoman
==Wikka Exporting/Importing ==
Just added a few thoughts [[WikkaFilters here]]
-- DarTar
====Resolved Suggestions====
== Question: PHP 4.3 and "mysql_escape_string()"? ==
For the Wikka Wakka Wiki 1.1.4.0 you need at least PHP 4.3 because the "mysql_real_escape_string()" in wakka.php is only available in PHP 4.3. A lot of hoster just offering PHP 4.1 or 4.2. Then you have to replace "mysql_real_escape_string()" with "mysql_escape_string()". What was the reason for the replacement in the new release? Again: Keep on the good work.
~&The reason is that ##mysql_real_escape_string()## is more secure than ##mysql_escape_string()## so we want to take advantage of that; but as implemented this left users of older versions of PHP in the cold. A workaround for this will be in version 1.1.6.0 (see above) - now avaliable as a [[HomePage public beta]]. --JavaWoman
== Typo correction in embedded Wiki Edit 2 ==
For the new (1.1.6.0) release, line 645 of wikiedit2/wikiedit2.js should be fixed to say:
%% s += " Ctrl+Shift+Minus - Horizontal line\n";%%
not "horisontal." I've already fixed it in my local copy, but no sense in perpetuating errors. :) --MovieLady
~&Thanks to eagle-eyed JsnX it's //aready// fixed in 1.1.6.0 beta4 :) but thanks for the note! --JavaWoman
~~& Marvelous, thanks! :) --MovieLady
==Compatibility with PHP 4.1.x==
with Debian GNU/Linux 3.0 (woody) are installed PHP 4.1.2 and this version don't support "mysql_real_escape_string" function.
temporary fix on wikka.php head:
if ( ! function_exists("mysql_real_escape_string") )
function mysql_real_escape_string($string)
return mysql_escape_string($string);
~&This will be in version 1.1.6.0 - now avaliable as a [[HomePage public beta]]. --JavaWoman
==Don't let old pages get indexed==
==User page==
If someone registers as a new user and chooses a Wikiname, his wikinamepage is empty. I think it would be nice, if the page whould be created from the wiki, containing a text with perhaps a welcome, some (Wiki)rules and usefull pages (this text should be stored somewhere so that it could be customized from the WikiAdmin). The page should automatically belong to the category user. Regards, NilsLindenberg
==Non-breaking space in forced links==
Sometimes a forced link has a phrase as link description with spaces for readability but where these spaces should **not** cause wrapping in the middle of the string - in other words, the spaces really should be non-breaking spaces. Unfortunately, specifying ## ## will (unlike here) result in the entity becoming visible as an entity instead of as the character it encodes.
It should be possible to either specify ## ## where needed and have it result in the actual character (i.e., keep the actual entity rather than "escaping" it), or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
//**Note:** Actually, with the 1.1.6.0 beta version running on this site, this demonstrates how the new htmlspecialchars_unicode() function is indeed buggy - as I pointed out on WikkaDevelopment. The solution is presented [[WikkaDevelopment there]] now (look for **htmlspecialchars_unicode()**).//
--JavaWoman
==User Control==
Is there an easy way to not allow registration? I would like to have it so that I can control the registration process, not let just anyone sign-up.
--BooYa
... (Nils proposing a solution)
A nice contribution Nils. If you want to go further with fiddling with the code for registration, I've thought it would be useful if there was a feature that required a password from an administrator to be able to register so that if you were going to register you put in your user info (as now) and a password you've obtained from the admin that allows you to register....for instance, in this way a teacher could set up a wikki with registration "on" and send a note to all of the parents with the registration password so that they could register....outsiders couldn't register, only those with the registration key. Possibly a quite useful feature to many potential user groups. -- GmBowen
~Look at UserRegistration for the first version, or [[http://www.niehle.info/UserSettings try it]] --NilsLindenberg
==Cookies and logging out==
This issue issue moved to StayingLoggedIn!
==Page viewed counter==
It occurs to me that some kind of "counter" for how many times the wikipage has been viewed might be a useful "action" for somebody to be able to use...this way a page author would know how often somebody has gone to the page & this might help focus development (especially for those keeners that have multiple pages/projects). [and I agree with the contributor below....Wikkawiki is great software]
''I completed altering a script and modifying the wikka code for this.....go to GmBowenCounter for the php script and the necessary alterations'' --GmBowen
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
==Mod rewrite and a problem==
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough?
''Good catch. Adding the end slash should be fine. It will be added by default in the next Wikka release. -- Jsnx''
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. -- JockeAndersson
''Jocke, in the style sheet [wikka.css by default], add "text-decoration: none;" to the smallprint style. Or am I not understanding the problem? -- JsnX''
~~~.smallprint a {
~~~color: #987;
~~~text-decoration: none;
~~~}
It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
The reason the above addition to smallprint doesn't work is that the links are visited meaning the pseudo-class a:visited must be defined as well with "text-decoration: none" in it. There is no definition for a:visited in the css by default. Perhaps this should be added to Wikka's code? -- JockeAndersson
Sure, I'll add it. Just curious though, what web browser are you using? Internet Explorer does not show underlined links as you have described...at least not for me. -- JsnX
I'm currently using Mozilla Firefox, but I'm testing pages in IE as well. The underlines were only visible in Firefox. IE is usually the one to screw up page rendering, not being fully standards-compliant and all. Oh, and the code could use an a:active definition as well. Be sure to define them in correct order though: a visited hover active. W3C were specific about that for some reason. -- JockeAndersson
Thanks for the tip. By the way, your site looks awesome. -- JsnX
You really think so? Thanks!! :) Much of the general layout comes from A List Apart's site, but adapted to my needs. I've had a site running for a while but can't find the time to update it properly. I believe Wikka will change all that and am seriously thinking of replacing my ordinary site with a Wikka wiki. The forum will still be phpbb, but the site itself could really benefit from the pros of Wikka. I second [[MarkHissinkMuller MarkHissinkMullers]] suggestions for improvement. Especially the possibility to manage ACLs based on user groups as well as individual users, would be great. -- JockeAndersson
~& I tried to do something like this at ACLsWithUserGroups.
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action (LOL) if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}""). -- Mike Bowen
Additions:
===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
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
Revision [7228]
Edited on 2005-04-13 16:08:19 by DarTar [Replying to old question on page titles and SEO]Additions:
See WikkaFolksonomy for more details
~& 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
~& 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
Revision [7226]
Edited on 2005-04-13 15:40:20 by JeremyCoates [Added comment re templating and database abstraction]Additions:
~~~~~&I would propose using a 'lite' templating engine such as [[http://www.phpxtemplate.org/ XTemplate]], it's a simple tag language, it keeps most of the logic in the PHP and hey, I maintain it. I use Wikka for at least 3 sites including the XTemplate site - so I'm about to help integrate and develop with Wikka. Oh and by the way, it's only 28k including the comments ;) XTemplate in combination with a DatabaseAbstraction layer such as [[http://adodb.sf.net ADODB]] would go a long way to making Wikka more maintainable than it is at present. -- JeremyCoates
Additions:
~~~& JavaWoman had a proposal about a color-markup there. I think its the better place for the discussion. The recognition of markup is done in the formatter (formatters/wakka.php). I am no expert for regexps too, but wouldn't the first or catch too much? --NilsLindenberg
Additions:
~~&Does this mean that if I go ahead and make a "Category Suggestion Box" and split this pages into seperate doco's that it won't step on people's toes? I think this would be good and don't mind doing that bit of work - but don't want to annoy too many people [espec. seeing as I am quite the newbie here...]
Additions:
~&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
-- KiltanneN
Additions:
~~&I looked at it. what point specifically did you intend i take from it?
Additions:
~&You may find the following pages interesting: UserMenus, WikkaMenus. --NilsLindenberg
~&We have a nice page called CodeContributions and the "Category User Contributions" (without the space) -- NilsLindenberg
~&We have a nice page called CodeContributions and the "Category User Contributions" (without the space) -- NilsLindenberg
Deletions:
Additions:
==Font action==
I didn't know where to put this, so here goes.
I've been adapting a script that uses GD to make an image of some text using a specified font. I'll post it at FontActionInfo
I didn't know where to put this, so here goes.
I've been adapting a script that uses GD to make an image of some text using a specified font. I'll post it at FontActionInfo
Additions:
===Editable header/footer===
It is quite cumbersome to edit the header and footer at the moment.
Some of it has to be done in the actions files, and the menuitems in the config file. This means I can't safely allow users to edit them.
What I would like, is a system that allows easy creation of non-default headers/footers (so you can get a different menu in different parts of the site).
--OnkelJonas
BTW - The work you've done - especially with CSS styling - is very, very good. Keep it up ;-)
It is quite cumbersome to edit the header and footer at the moment.
Some of it has to be done in the actions files, and the menuitems in the config file. This means I can't safely allow users to edit them.
What I would like, is a system that allows easy creation of non-default headers/footers (so you can get a different menu in different parts of the site).
--OnkelJonas
BTW - The work you've done - especially with CSS styling - is very, very good. Keep it up ;-)
Additions:
~~&As I've mentioned before, what I think we really need is a setting in the configuration for date (and time) format which should then be used everywhere - we're really inconsistent now with every bit of code doing its own date/time formatting. The default for the configuration should then be the standard ISO format since it's non-ambiguous. --JavaWoman
Deletions:
Additions:
~~&As I've mentioned vbefore, what I thnik we really need is a setting in the configuration for date (and time) format which should then be used everywhere - we're really inconsistent now with every bit of code dong its own date/time formatting. The default for the configuration should then be the standard ISO format since it's non-ambiguous. --JavaWoman
Revision [7033]
Edited on 2005-03-31 12:11:50 by NilsLindenberg [reply to Date formatting/ colour formatting]Additions:
~&Please take a look at WikkaExtensibleMarkup --NilsLindenberg
~&Related to this topic: UserSettingsPanel --NilsLindenberg
~&Related to this topic: UserSettingsPanel --NilsLindenberg
Additions:
In handlers/page/revisions.php replace
$output .= "<td> <a href=\"".$this->Href("show","","time=").urlencode($page["time"])."\">".$page["time"]."</a></td>";
with something like
$output .= "<td> <a href=\"".$this->Href("show","","time=").urlencode($page["time"])."\">".date("l dS of F Y h:i:s A",strtotime($page["time"]))."</a></td>";
in handlers/page/history.php replace
$output .= "<strong>Edited on <a href=\"".$this->Href("", "", "time=".urlencode($pageA["time"]))."\">".$pageA["time"]."</a> by ".$EditedByUser."</strong> <span style=\"color:#888;font-size:smaller;\">".$note."</span><br />\n";
with something like
$output .= "<strong>Edited on <a href=\"".$this->Href("", "", "time=".urlencode($pageA["time"]))."\">".date("l dS of F Y h:i:s A",strtotime($pageA["time"]))."</a> by ".$EditedByUser."</strong> <span style=\"color:#888;font-size:smaller;\">".$note."</span><br />\n";
See [[http://www.php.net/manual/en/function.date.php php documentation]] for details on the date() function.
I think it would be nice to add a function for this to the wikka-class and call it everywhere, where times are printed out - would make such things a bit easier (especially if there would be a ""$DefaultTimeFormat"" in the config-array).
--TimoK
$output .= "<td> <a href=\"".$this->Href("show","","time=").urlencode($page["time"])."\">".$page["time"]."</a></td>";
with something like
$output .= "<td> <a href=\"".$this->Href("show","","time=").urlencode($page["time"])."\">".date("l dS of F Y h:i:s A",strtotime($page["time"]))."</a></td>";
in handlers/page/history.php replace
$output .= "<strong>Edited on <a href=\"".$this->Href("", "", "time=".urlencode($pageA["time"]))."\">".$pageA["time"]."</a> by ".$EditedByUser."</strong> <span style=\"color:#888;font-size:smaller;\">".$note."</span><br />\n";
with something like
$output .= "<strong>Edited on <a href=\"".$this->Href("", "", "time=".urlencode($pageA["time"]))."\">".date("l dS of F Y h:i:s A",strtotime($pageA["time"]))."</a> by ".$EditedByUser."</strong> <span style=\"color:#888;font-size:smaller;\">".$note."</span><br />\n";
See [[http://www.php.net/manual/en/function.date.php php documentation]] for details on the date() function.
I think it would be nice to add a function for this to the wikka-class and call it everywhere, where times are printed out - would make such things a bit easier (especially if there would be a ""$DefaultTimeFormat"" in the config-array).
--TimoK
Revision [7025]
Edited on 2005-03-31 01:30:38 by MonstoBrukes [Answer to EgilHelland (timestamp formats)]Additions:
===Color Formatting===
The current color formatting isn't very wiki like. Altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
%%^<color> text^%%
this regex syntax is lifted from a ""UseMod"" Wiki patch.
%%s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
I am by NO means a regex expert, but it seems that this should do the deal... I'm just not sure where it would go. By using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--MonstoBrukes
The current color formatting isn't very wiki like. Altho i can see how ""{{}}"" fits with wikka formatting style, text color is something i see myself using more often than tables. so here's the suggestion...
%%^<color> text^%%
this regex syntax is lifted from a ""UseMod"" Wiki patch.
%%s/\^([a-zA-Z]{1,}|#[0-9A-Fa-f]{6}) (.*?)\^/<span style="color:$1;">$2<\/span>/%%
I am by NO means a regex expert, but it seems that this should do the deal... I'm just not sure where it would go. By using style here, you can use ''#0000ff'', ''#00f'', as well as just ''blue'' or any other html defined color name.
--MonstoBrukes
Revision [7004]
Edited on 2005-03-30 09:15:40 by EgilHelland [Answer to EgilHelland (timestamp formats)]Additions:
===Date formatting===
Hi folks,
trying to figure out how to change the date format displayed in Page History and Revisions to something more functional than the "Romance Daylight Time" I get in my wikka installation. Could someone point me in the right direction please? Thanks for a really good wiki btw!
--EgilHelland
Hi folks,
trying to figure out how to change the date format displayed in Page History and Revisions to something more functional than the "Romance Daylight Time" I get in my wikka installation. Could someone point me in the right direction please? Thanks for a really good wiki btw!
--EgilHelland
Deletions:
I made that huge so that maybe it would annoy someone into helping.
Received an error msg that was particularly perplexing. Since i wasn't sure where exactly to try and get help for it, i thought i'd post here tho i know it's off topic. **NonObjectMemberFunction**
PS if there is a better place to have posted this, i'd be happy to know what page that is.
Additions:
Received an error msg that was particularly perplexing. Since i wasn't sure where exactly to try and get help for it, i thought i'd post here tho i know it's off topic. **NonObjectMemberFunction**
PS if there is a better place to have posted this, i'd be happy to know what page that is.
PS if there is a better place to have posted this, i'd be happy to know what page that is.
Deletions:
Additions:
======HELP PLEASE======
I made that huge so that maybe it would annoy someone into helping.
I made that huge so that maybe it would annoy someone into helping.
Additions:
~~~~&Check it out, PhpMyEdit. -- JsnX
Additions:
Received an error msg today that was particularly perplexing. Since i wasn't sure where exactly to try and get help for it, i thought i'd post here tho i know it's off topic. **NonObjectMemberFunction**
Additions:
~&You can add usernames to the admin-list, if you don't want to share the admin-account. Specify multiple wiki names separated by commas e.g: JsnX, HendrikMans, CoolJoeAdmin in the wikka.config.php in "admin-users" (see ConfigurationOptions). Admins can see, edit and delete any page, even if they are set to private.
Searching for "Admin Features" yeilds over 100 entries. There's nothing in CategoryDocumentation detailing admin features, and the page WikkaFeatures mentions several admin features that have neither further explanation nor links.
~&Will be changed, but not today :)
On top of all this, searching ACL reveals **one page** that just mentions ACL more in passing. The page with Category instructions is also a little under informed. You'd think that after following 2 step instructions that it'd work.
~&I think you mean ACLInfo and WikiCategory? If you have questions about a documentation-page, please leave a comment about that on the page. We can only make it better if we know what is not understandable. Remember that this is a wiki :)
~&Yes, we can and should organize the documentation better (and some other parts of this wiki). We will move it to a new subdomain (see DocumentationLanguageLinking) and after that we can bring it in better shape. But don't forget that this is a wiki and you have the right to participate :) --NilsLindenberg
Searching for "Admin Features" yeilds over 100 entries. There's nothing in CategoryDocumentation detailing admin features, and the page WikkaFeatures mentions several admin features that have neither further explanation nor links.
~&Will be changed, but not today :)
On top of all this, searching ACL reveals **one page** that just mentions ACL more in passing. The page with Category instructions is also a little under informed. You'd think that after following 2 step instructions that it'd work.
~&I think you mean ACLInfo and WikiCategory? If you have questions about a documentation-page, please leave a comment about that on the page. We can only make it better if we know what is not understandable. Remember that this is a wiki :)
~&Yes, we can and should organize the documentation better (and some other parts of this wiki). We will move it to a new subdomain (see DocumentationLanguageLinking) and after that we can bring it in better shape. But don't forget that this is a wiki and you have the right to participate :) --NilsLindenberg
Deletions:
Additions:
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
This page is another example. I started reading it the other night looking for something specific but by the time i finished reading it, i had about 6 different things i felt like commenting on. It's so long tho that i felt my comments would be missed so i didn't bother. Rather than piled on one after the other, after a certain age, each of these subjects should be broken off to their own page in a CategorySuggestionBox and listed here. (I mean this is a wiki and space isn't necessarily at a premium) This would make it easier to find and contribute to a specific topic. If a search produces this page as a result, the initial impression is that the search was really messed up hitting "suggestionbox" with my search terms.
Anyway... the suggestion? Organizing documentation should be THE priority. This site looks quite nice. It's a shining example of how wikka works when beat into perfect shape. But the site I installed looked and acted nothing like this...
-- MonstoBrukes
This page is another example. I started reading it the other night looking for something specific but by the time i finished reading it, i had about 6 different things i felt like commenting on. It's so long tho that i felt my comments would be missed so i didn't bother. Rather than piled on one after the other, after a certain age, each of these subjects should be broken off to their own page in a CategorySuggestionBox and listed here. (I mean this is a wiki and space isn't necessarily at a premium) This would make it easier to find and contribute to a specific topic. If a search produces this page as a result, the initial impression is that the search was really messed up hitting "suggestionbox" with my search terms.
Anyway... the suggestion? Organizing documentation should be THE priority. This site looks quite nice. It's a shining example of how wikka works when beat into perfect shape. But the site I installed looked and acted nothing like this...
Deletions:
The suggestion? Organizing documentation should be THE priority. This site looks quite nice. It's a shining example of how wikka works when beat into perfect shape. But the installed site looks and acts nothing like it...
Additions:
===Documentation===
Documentation on the site here seems . . . fragmented I think is the best word. Admin features are the example i'll use cuz it was my big hurdle. At this point I've only been able to find that the account created at install is THE admin, and as site owner i should give access to that account to the people that i want to admin the site. Is there more to it than this?
Searching for "Admin Features" yeilds over 100 entries. There's nothing in CategoryDocumentation detailing admin features, and the page WikkaFeatures mentions several admin features that have neither further explanation nor links. On top of all this, searching ACL reveals **one page** that just mentions ACL more in passing. The page with Category instructions is also a little under informed. You'd think that after following 2 step instructions that it'd work.
The suggestion? Organizing documentation should be THE priority. This site looks quite nice. It's a shining example of how wikka works when beat into perfect shape. But the installed site looks and acts nothing like it...
Documentation on the site here seems . . . fragmented I think is the best word. Admin features are the example i'll use cuz it was my big hurdle. At this point I've only been able to find that the account created at install is THE admin, and as site owner i should give access to that account to the people that i want to admin the site. Is there more to it than this?
Searching for "Admin Features" yeilds over 100 entries. There's nothing in CategoryDocumentation detailing admin features, and the page WikkaFeatures mentions several admin features that have neither further explanation nor links. On top of all this, searching ACL reveals **one page** that just mentions ACL more in passing. The page with Category instructions is also a little under informed. You'd think that after following 2 step instructions that it'd work.
The suggestion? Organizing documentation should be THE priority. This site looks quite nice. It's a shining example of how wikka works when beat into perfect shape. But the installed site looks and acts nothing like it...
Additions:
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
Deletions:
Additions:
===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.
==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.
Additions:
=====Suggestion Box=====
{{lastedit show="3"}}
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
**See also:**
~-WikkaSpamFighting for spam-related issues
~-WikkaWorkarounds for specific platforms
~-WikkaOptimization
>>{{feedback}}::c::
===User map===
I have copied the proposal for a user map form Category Users to UserMap. --NilsLindenberg
===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
----
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
%% 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
----
===Section Editing Redux===
Instead of a full blown section editing implementation why not just implement a tag like '<WikiPage>' which inserts the contents of WikiPage (no comments) at the markers location. <WikiPage x> would insert the first x lines of the WikiPage into the current page. And/or <WikiPage Header> would pull just the section of the page which is demarked by Header and EOP or next header. Such sections can be inserted in a special color/block/font/whatever and automatically link back to the original page for editing. The goal is to provide better editing granularity and readability on pages which have lots of information density. Could also be used to mimic blog functionality. -KarmaTester
----
===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
~~& 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
----
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
----
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) open a ##/raw## version of the page;
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
~1) open a text editor;
~1) copy the code block;
~1) paste it in the text editor;
~1) save the file.
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
%%
include ('Wakka.class.php');
%%
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
----
===phpMyEdit in Wikka===
I've set up a demo of [[http://www.jsnx.com/wikka-dev/SuggestionBox phpMyEdit running within Wikka]]. This would be useful for anyone wanting to directly interact with MySQL tables from a Wikka page. -- JsnX
~&I assume this is meant for admins only but ... Could you add some explanation? I looked but don't have a clue how to use it. What are the radio buttons for, for instance? What's the "V" button at the top? The UI is very confusing. --JavaWoman
~~& Jsnx, that's interesting. I think the idea is worth consideration. I have used phpMyEdit as an interface to allow my users to store their profiles in the DB when I still was a MySQL newbie :) and it's true that it allows a number of tricky things (especially cross-reference between tables). So I think a plugin for integrating phpMyEdit within Wikka pages might be a nice extension. You probably know though that all the interface options can only be set by editing the source, or were you thinking of allowing some kind of admin access to the interface options? And be honest, are you thinking of phpMyEdit as a sort of replacement for my baby admin actions, aren't you?! In a sense this might be interesting, but it would really be unnecessary compared to what we can do by creating direct calls to the DB using core functions. Why heavily tweak an external script to do something wikka-like if we can already use something that only needs core functions? --- Moreover, when you perform operations on pages (like 'add', 'copy' or 'delete') you generally want to do something more complicated than just modify single records of the page table. Using phpMyEdit as a sort of proxy for a page admin action can lead to major inconsistencies in the page structure. --- And, JW, the "v" button is for filtering the table ;-) -- DarTar
~~~&DarTar, that's silly. The admin actions that you have developed are looking fantastic! I was never thinking of using phpMyEdit to replace your actions. I'm using phpMyEdit to interface with non-Wikka tables; I like to see the data shown from Wikka, and I also like being able to use Wikka formatting within the data. It might help if I gave an example of how I use phpMyEdit. [... I'll write an example later on ...] -- JsnX
~~~&Filtering? Well first it's not obvious, nor explained; but I just went back and tried pressing the "v" button - and I get three other mystifying buttons in return. Frankly, I don't want to use something as badly-designed as this. Shudder. DarTar, your Admin functions may need some refinement, but mystifying they are not. Let's stick with those, and build on them. Sorry, JsnX, but this doesn't get my vote. --JavaWoman
~~~~&Thanks for the comments. I expected there would be some reservations about including this in Wikka. I too have some reservations about phpMyEdit. However, with that said, I also find it to be a **very useful** tool which I will continue to use. It doesn't matter to me whether phpMyEdit is ever an official Wikka component because using it requires zero modifications to the Wikka code -- there will be no ongoing maintenance when upgrading to new Wikka versions. It's not my intention to support this, but if someone wants to use it, I'm happy to make my modified phpMyEdit version available. I'm proposing this as an official "unofficial Wikka add-on". :) -- JsnX
~&I am interested by the idea to interact with MySQL tables from a Wikka page. Would you please share the updated phpMyEdit code? --ChristianBarthelemy
~~&Yes, I plan to play around with it for a few more days, then I'll upload the code and some instructions. -- JsnX
~~~&Hi Jason, I am still interested to know more about this... --ChristianBarthelemy
~&Well, Jason, I do think it would help I you would explain what you are using this **for** (especially if not for Wikka administration); I'd also like to know then why you chose phpMyEdit and not another browser-based client - and why a browser-based client in the first place. I've only ever tried phpMyAdmin and found it lacking because it tends (tended) to work on single tables only. I quickly switched to "real" clients that are more powerful and allow me to build queries involving several tables if needed, so consistency can be maintained. I have a bunch of handy tools (for Windows), all free: for design, administration and maintenance. And though I do have phpMyAdmin available, I don't intend to use it. --JavaWoman
~~&My bet is that Jason's using it to fix the pages where I've (inadertently) submitted double percent signs as part of submitted code so that the history feature works properly. {grin} --GmBowen
~~~&LOL! But - "inadvertently"? Using double percent signs should be possible in code - and if not, that's a bug in Wikka, not your fault! (Not that I have a solution for that yet, though I have been thinking about that problem.) --JavaWoman
----
===Support for (Technorati) tags===
I think it might be interesting to provide Wikka support for (Technorati) "**tags**". "Tags" in this context are simple keywords that help identify and categorize web content, in particular blog posts. Such keywords coupled with a ping system can be used by remote servers to retrieve fresh content for specific topics. See for instance how technorati.com aggregates fresh information about [[http://www.technorati.com/tag/wiki wikis]] from a number of sources.
[[http://www.technorati.com/help/tags.html More information on Technorati tags]]
~&Seems like we need to update our RSS (feed) implementation first... --JavaWoman
----
===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
----
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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?
--GregorLindner
----
==Signature==
(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
----
== 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
----
== Create rewrite rules on install ==
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
== Image dimensions ==
The [[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
----
==Clearing ACLs==
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
----
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
== RSS options ==
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
----
== 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
----
== Language file ==
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
== 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
----
==Finally using CVS?==
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
==Stopping Spammers getting Google Juice==
//(moved to WikkaSpamFighting)//
----
==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
----
==Give control over HTML (using a templating system)==
It would be nice to see a template engine in Wikka to give the users the full control over the HTML source. Smarty is always a good choice.
~& I would love to see Wikka adopt some type of template system. I think that its is sorely needed. Changing the look of Wikka requires tedious editing of php files, and alot of the time it is non-obvious where you need to go to edit such files. Another alternative to [[http://smarty.php.net Smarty]] could be [[http://wiki.ciaweb.net/yawiki/index.php?area=Savant Savant]]. --KickTheDonkey
~~&While I use and like Smarty very much (and it's quite fast), it's rather "heavy" for Wikka, I think. I just had a look at Savant2 which I hadn't heard of before. It looks like a good fit, is lightweight and easy to use. A templating system like this would also provide much more flexibility for Wikka admins to have control over page structure and layout. I'll want to play with it some (in combination with Wikka), but my first impression based on documentation and code is very favorable. More when I've had a chance to exercise it. --JavaWoman
~~~&I'm sorry JW, but what do you mean by Smarty being rather "heavy" for Wikka? Resource-wise? Hard to use / implement? Difficult for the end user? -- FernandoBorcel
~~~~&Fernando, I mean it's "heavy" in two respects, actualy: 1) in terms of code size (currently Smarty is 137K compared to Wikka's 524K - zipped - while for instance Savant is only 39K); 2) in terms of usability - while it's quite powerful, there is a rather steep learning curve for those who've never worked with templates; Savant is simpler and much easier to learn, and looks still quite flexible. I'm not sure about resource usage, but I suspect that in that respect it might be heavier than Savant as well. We'd like to keep Wikka easy to use both for WikiAdmins and for WikiUsers. I still have to actually try Savant with Wikka, but from what I've see so far it fits our profile better, I think. Anyway, before we go forward with something like this, more research will be needed. --JavaWoman
----
==Allow spaces in pagetitle==
Allow Spaces in the document title and replace it later with "-" to optimize it for search engines.
----
==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
----
==Local links==
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--KickTheDonkey
----
==Idea for Category Support==
moved to CategorySystemOverhaul, it is the better place, thanks DarTar
--ArpY
~& ArpY, take a look at CategorySystemOverhaul for an open discussion on how to improve the category system -- DarTar
----
==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.
----
==Section Editing ==
- http://c2.com/cgi/wiki?SectionEditing
- It makes allows you to flow and edit much quicker.
- Each topic should have a corresponding edit button. This allows your to edit each section with out breaking your flow.
- http://www.splitbrain.org/dokuwiki/wiki:section_editing
----
==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
----
==Standard date and time format==
Although I'm all for using the ISO date/time format as we see in the timestamp of the footer of every page, I note that several other parts of Wikka use different date/time formats. I'd like to see an approach where this is standardized.
Proposal:
~-Define date-time format (or separately date and time, as well as a way to combine them) in the configuration; use the ISO format as a default (in the initial configuration, as well as when no format is defined in the config).
~-Use this format wherever date and/or time are formatted.
~-Make using the configured formats a requirement for every Wikka extension (that displays date/time information) to be included with the distribution.
I realize that in principle it's possible to pick up formats from a locale but for a Wikka targeted at an international audience this may not be the best approach, and for a Wikka with a "local" audience it may not be either if it's hosted on a (public) server outside that country - hence the idea to define a format in the configuration.
--JavaWoman
~''Agreed -- DarTar''
----
==Handling the config==
I have three questions about the config. See HandlingWikkaConfig.
--NilsLindenberg
''See also WikkaSecureConfig for a possible new appraoch. --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
----
==Online editing of mindmaps would be great==
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
----
==Tables ==
For the discussion on tables in Wikka, take a look at WikkaTables.
~&See also TableAction for a preliminary solution. --JavaWoman
----
==Wikka Exporting/Importing ==
Just added a few thoughts [[WikkaFilters here]]
-- DarTar
----
==how to format code to get two % characters without space together?==
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
----
==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
----
==showing comments==
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
----
==Language support==
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
----
== 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
----
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
----
== 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
----
==Using FPDF with Wikka==
Not so much a suggestion, more a request although it may be useful to others.
I have been using FPDF from [[http://www.fpdf.org FPDF ]] to export content from a database to pdf files.
I would like to extend my usage of FPDF to wikka by adding a hyperlink to the top of my wikka pages which would allow me to post the page tag or page id to the FPDF script for exporting the content into a pdf file.
The link would be in the form similar to
http://www.mysite.com/script.php?id=
Can anyone tell me how I can extract the page tag or page id from the wikka_pages table in order to do this.
----
====Resolved Suggestions====
== Question: PHP 4.3 and "mysql_escape_string()"? ==
For the Wikka Wakka Wiki 1.1.4.0 you need at least PHP 4.3 because the "mysql_real_escape_string()" in wakka.php is only available in PHP 4.3. A lot of hoster just offering PHP 4.1 or 4.2. Then you have to replace "mysql_real_escape_string()" with "mysql_escape_string()". What was the reason for the replacement in the new release? Again: Keep on the good work.
-- SkyWalk
~&The reason is that ##mysql_real_escape_string()## is more secure than ##mysql_escape_string()## so we want to take advantage of that; but as implemented this left users of older versions of PHP in the cold. A workaround for this will be in version 1.1.6.0 (see above) - now avaliable as a [[HomePage public beta]]. --JavaWoman
----
== Typo correction in embedded Wiki Edit 2 ==
For the new (1.1.6.0) release, line 645 of wikiedit2/wikiedit2.js should be fixed to say:
%% s += " Ctrl+Shift+Minus - Horizontal line\n";%%
not "horisontal." I've already fixed it in my local copy, but no sense in perpetuating errors. :) --MovieLady
~&Thanks to eagle-eyed JsnX it's //aready// fixed in 1.1.6.0 beta4 :) but thanks for the note! --JavaWoman
~~& Marvelous, thanks! :) --MovieLady
==Compatibility with PHP 4.1.x==
with Debian GNU/Linux 3.0 (woody) are installed PHP 4.1.2 and this version don't support "mysql_real_escape_string" function.
temporary fix on wikka.php head:
%%(php)
if ( ! function_exists("mysql_real_escape_string") )
{
function mysql_real_escape_string($string)
{
return mysql_escape_string($string);
}
}%%
~&This will be in version 1.1.6.0 - now avaliable as a [[HomePage public beta]]. --JavaWoman
==Don't let old pages get indexed==
//(moved to WikkaSpamFighting)//
==User page==
If someone registers as a new user and chooses a Wikiname, his wikinamepage is empty. I think it would be nice, if the page whould be created from the wiki, containing a text with perhaps a welcome, some (Wiki)rules and usefull pages (this text should be stored somewhere so that it could be customized from the WikiAdmin). The page should automatically belong to the category user. Regards, NilsLindenberg
==Non-breaking space in forced links==
Sometimes a forced link has a phrase as link description with spaces for readability but where these spaces should **not** cause wrapping in the middle of the string - in other words, the spaces really should be non-breaking spaces. Unfortunately, specifying ## ## will (unlike here) result in the entity becoming visible as an entity instead of as the character it encodes.
It should be possible to either specify ## ## where needed and have it result in the actual character (i.e., keep the actual entity rather than "escaping" it), or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
//**Note:** Actually, with the 1.1.6.0 beta version running on this site, this demonstrates how the new htmlspecialchars_unicode() function is indeed buggy - as I pointed out on WikkaDevelopment. The solution is presented [[WikkaDevelopment there]] now (look for **htmlspecialchars_unicode()**).//
--JavaWoman
==User Control==
Is there an easy way to not allow registration? I would like to have it so that I can control the registration process, not let just anyone sign-up.
--BooYa
... (Nils proposing a solution)
A nice contribution Nils. If you want to go further with fiddling with the code for registration, I've thought it would be useful if there was a feature that required a password from an administrator to be able to register so that if you were going to register you put in your user info (as now) and a password you've obtained from the admin that allows you to register....for instance, in this way a teacher could set up a wikki with registration "on" and send a note to all of the parents with the registration password so that they could register....outsiders couldn't register, only those with the registration key. Possibly a quite useful feature to many potential user groups. -- GmBowen
~Look at UserRegistration for the first version, or [[http://www.niehle.info/UserSettings try it]] --NilsLindenberg
----
==Cookies and logging out==
This issue issue moved to StayingLoggedIn!
==Page viewed counter==
It occurs to me that some kind of "counter" for how many times the wikipage has been viewed might be a useful "action" for somebody to be able to use...this way a page author would know how often somebody has gone to the page & this might help focus development (especially for those keeners that have multiple pages/projects). [and I agree with the contributor below....Wikkawiki is great software]
''I completed altering a script and modifying the wikka code for this.....go to GmBowenCounter for the php script and the necessary alterations'' --GmBowen
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
==Mod rewrite and a problem==
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough?
''Good catch. Adding the end slash should be fine. It will be added by default in the next Wikka release. -- Jsnx''
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. -- JockeAndersson
''Jocke, in the style sheet [wikka.css by default], add "text-decoration: none;" to the smallprint style. Or am I not understanding the problem? -- JsnX''
~~~.smallprint a {
~~~color: #987;
~~~text-decoration: none;
~~~}
It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
The reason the above addition to smallprint doesn't work is that the links are visited meaning the pseudo-class a:visited must be defined as well with "text-decoration: none" in it. There is no definition for a:visited in the css by default. Perhaps this should be added to Wikka's code? -- JockeAndersson
Sure, I'll add it. Just curious though, what web browser are you using? Internet Explorer does not show underlined links as you have described...at least not for me. -- JsnX
I'm currently using Mozilla Firefox, but I'm testing pages in IE as well. The underlines were only visible in Firefox. IE is usually the one to screw up page rendering, not being fully standards-compliant and all. Oh, and the code could use an a:active definition as well. Be sure to define them in correct order though: a visited hover active. W3C were specific about that for some reason. -- JockeAndersson
Thanks for the tip. By the way, your site looks awesome. -- JsnX
You really think so? Thanks!! :) Much of the general layout comes from A List Apart's site, but adapted to my needs. I've had a site running for a while but can't find the time to update it properly. I believe Wikka will change all that and am seriously thinking of replacing my ordinary site with a Wikka wiki. The forum will still be phpbb, but the site itself could really benefit from the pros of Wikka. I second [[MarkHissinkMuller MarkHissinkMullers]] suggestions for improvement. Especially the possibility to manage ACLs based on user groups as well as individual users, would be great. -- JockeAndersson
~& I tried to do something like this at ACLsWithUserGroups.
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action (LOL) if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}""). -- Mike Bowen
----
CategoryWikka
{{lastedit show="3"}}
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
**See also:**
~-WikkaSpamFighting for spam-related issues
~-WikkaWorkarounds for specific platforms
~-WikkaOptimization
>>{{feedback}}::c::
===User map===
I have copied the proposal for a user map form Category Users to UserMap. --NilsLindenberg
===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
----
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
%% 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
----
===Section Editing Redux===
Instead of a full blown section editing implementation why not just implement a tag like '<WikiPage>' which inserts the contents of WikiPage (no comments) at the markers location. <WikiPage x> would insert the first x lines of the WikiPage into the current page. And/or <WikiPage Header> would pull just the section of the page which is demarked by Header and EOP or next header. Such sections can be inserted in a special color/block/font/whatever and automatically link back to the original page for editing. The goal is to provide better editing granularity and readability on pages which have lots of information density. Could also be used to mimic blog functionality. -KarmaTester
----
===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
~~& 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
----
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
----
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) open a ##/raw## version of the page;
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
~1) open a text editor;
~1) copy the code block;
~1) paste it in the text editor;
~1) save the file.
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
%%
include ('Wakka.class.php');
%%
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
----
===phpMyEdit in Wikka===
I've set up a demo of [[http://www.jsnx.com/wikka-dev/SuggestionBox phpMyEdit running within Wikka]]. This would be useful for anyone wanting to directly interact with MySQL tables from a Wikka page. -- JsnX
~&I assume this is meant for admins only but ... Could you add some explanation? I looked but don't have a clue how to use it. What are the radio buttons for, for instance? What's the "V" button at the top? The UI is very confusing. --JavaWoman
~~& Jsnx, that's interesting. I think the idea is worth consideration. I have used phpMyEdit as an interface to allow my users to store their profiles in the DB when I still was a MySQL newbie :) and it's true that it allows a number of tricky things (especially cross-reference between tables). So I think a plugin for integrating phpMyEdit within Wikka pages might be a nice extension. You probably know though that all the interface options can only be set by editing the source, or were you thinking of allowing some kind of admin access to the interface options? And be honest, are you thinking of phpMyEdit as a sort of replacement for my baby admin actions, aren't you?! In a sense this might be interesting, but it would really be unnecessary compared to what we can do by creating direct calls to the DB using core functions. Why heavily tweak an external script to do something wikka-like if we can already use something that only needs core functions? --- Moreover, when you perform operations on pages (like 'add', 'copy' or 'delete') you generally want to do something more complicated than just modify single records of the page table. Using phpMyEdit as a sort of proxy for a page admin action can lead to major inconsistencies in the page structure. --- And, JW, the "v" button is for filtering the table ;-) -- DarTar
~~~&DarTar, that's silly. The admin actions that you have developed are looking fantastic! I was never thinking of using phpMyEdit to replace your actions. I'm using phpMyEdit to interface with non-Wikka tables; I like to see the data shown from Wikka, and I also like being able to use Wikka formatting within the data. It might help if I gave an example of how I use phpMyEdit. [... I'll write an example later on ...] -- JsnX
~~~&Filtering? Well first it's not obvious, nor explained; but I just went back and tried pressing the "v" button - and I get three other mystifying buttons in return. Frankly, I don't want to use something as badly-designed as this. Shudder. DarTar, your Admin functions may need some refinement, but mystifying they are not. Let's stick with those, and build on them. Sorry, JsnX, but this doesn't get my vote. --JavaWoman
~~~~&Thanks for the comments. I expected there would be some reservations about including this in Wikka. I too have some reservations about phpMyEdit. However, with that said, I also find it to be a **very useful** tool which I will continue to use. It doesn't matter to me whether phpMyEdit is ever an official Wikka component because using it requires zero modifications to the Wikka code -- there will be no ongoing maintenance when upgrading to new Wikka versions. It's not my intention to support this, but if someone wants to use it, I'm happy to make my modified phpMyEdit version available. I'm proposing this as an official "unofficial Wikka add-on". :) -- JsnX
~&I am interested by the idea to interact with MySQL tables from a Wikka page. Would you please share the updated phpMyEdit code? --ChristianBarthelemy
~~&Yes, I plan to play around with it for a few more days, then I'll upload the code and some instructions. -- JsnX
~~~&Hi Jason, I am still interested to know more about this... --ChristianBarthelemy
~&Well, Jason, I do think it would help I you would explain what you are using this **for** (especially if not for Wikka administration); I'd also like to know then why you chose phpMyEdit and not another browser-based client - and why a browser-based client in the first place. I've only ever tried phpMyAdmin and found it lacking because it tends (tended) to work on single tables only. I quickly switched to "real" clients that are more powerful and allow me to build queries involving several tables if needed, so consistency can be maintained. I have a bunch of handy tools (for Windows), all free: for design, administration and maintenance. And though I do have phpMyAdmin available, I don't intend to use it. --JavaWoman
~~&My bet is that Jason's using it to fix the pages where I've (inadertently) submitted double percent signs as part of submitted code so that the history feature works properly. {grin} --GmBowen
~~~&LOL! But - "inadvertently"? Using double percent signs should be possible in code - and if not, that's a bug in Wikka, not your fault! (Not that I have a solution for that yet, though I have been thinking about that problem.) --JavaWoman
----
===Support for (Technorati) tags===
I think it might be interesting to provide Wikka support for (Technorati) "**tags**". "Tags" in this context are simple keywords that help identify and categorize web content, in particular blog posts. Such keywords coupled with a ping system can be used by remote servers to retrieve fresh content for specific topics. See for instance how technorati.com aggregates fresh information about [[http://www.technorati.com/tag/wiki wikis]] from a number of sources.
[[http://www.technorati.com/help/tags.html More information on Technorati tags]]
~&Seems like we need to update our RSS (feed) implementation first... --JavaWoman
----
===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
----
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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?
--GregorLindner
----
==Signature==
(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
----
== 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
----
== Create rewrite rules on install ==
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
== Image dimensions ==
The [[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
----
==Clearing ACLs==
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
----
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
== RSS options ==
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
----
== 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
----
== Language file ==
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
== 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
----
==Finally using CVS?==
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
==Stopping Spammers getting Google Juice==
//(moved to WikkaSpamFighting)//
----
==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
----
==Give control over HTML (using a templating system)==
It would be nice to see a template engine in Wikka to give the users the full control over the HTML source. Smarty is always a good choice.
~& I would love to see Wikka adopt some type of template system. I think that its is sorely needed. Changing the look of Wikka requires tedious editing of php files, and alot of the time it is non-obvious where you need to go to edit such files. Another alternative to [[http://smarty.php.net Smarty]] could be [[http://wiki.ciaweb.net/yawiki/index.php?area=Savant Savant]]. --KickTheDonkey
~~&While I use and like Smarty very much (and it's quite fast), it's rather "heavy" for Wikka, I think. I just had a look at Savant2 which I hadn't heard of before. It looks like a good fit, is lightweight and easy to use. A templating system like this would also provide much more flexibility for Wikka admins to have control over page structure and layout. I'll want to play with it some (in combination with Wikka), but my first impression based on documentation and code is very favorable. More when I've had a chance to exercise it. --JavaWoman
~~~&I'm sorry JW, but what do you mean by Smarty being rather "heavy" for Wikka? Resource-wise? Hard to use / implement? Difficult for the end user? -- FernandoBorcel
~~~~&Fernando, I mean it's "heavy" in two respects, actualy: 1) in terms of code size (currently Smarty is 137K compared to Wikka's 524K - zipped - while for instance Savant is only 39K); 2) in terms of usability - while it's quite powerful, there is a rather steep learning curve for those who've never worked with templates; Savant is simpler and much easier to learn, and looks still quite flexible. I'm not sure about resource usage, but I suspect that in that respect it might be heavier than Savant as well. We'd like to keep Wikka easy to use both for WikiAdmins and for WikiUsers. I still have to actually try Savant with Wikka, but from what I've see so far it fits our profile better, I think. Anyway, before we go forward with something like this, more research will be needed. --JavaWoman
----
==Allow spaces in pagetitle==
Allow Spaces in the document title and replace it later with "-" to optimize it for search engines.
----
==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
----
==Local links==
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--KickTheDonkey
----
==Idea for Category Support==
moved to CategorySystemOverhaul, it is the better place, thanks DarTar
--ArpY
~& ArpY, take a look at CategorySystemOverhaul for an open discussion on how to improve the category system -- DarTar
----
==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.
----
==Section Editing ==
- http://c2.com/cgi/wiki?SectionEditing
- It makes allows you to flow and edit much quicker.
- Each topic should have a corresponding edit button. This allows your to edit each section with out breaking your flow.
- http://www.splitbrain.org/dokuwiki/wiki:section_editing
----
==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
----
==Standard date and time format==
Although I'm all for using the ISO date/time format as we see in the timestamp of the footer of every page, I note that several other parts of Wikka use different date/time formats. I'd like to see an approach where this is standardized.
Proposal:
~-Define date-time format (or separately date and time, as well as a way to combine them) in the configuration; use the ISO format as a default (in the initial configuration, as well as when no format is defined in the config).
~-Use this format wherever date and/or time are formatted.
~-Make using the configured formats a requirement for every Wikka extension (that displays date/time information) to be included with the distribution.
I realize that in principle it's possible to pick up formats from a locale but for a Wikka targeted at an international audience this may not be the best approach, and for a Wikka with a "local" audience it may not be either if it's hosted on a (public) server outside that country - hence the idea to define a format in the configuration.
--JavaWoman
~''Agreed -- DarTar''
----
==Handling the config==
I have three questions about the config. See HandlingWikkaConfig.
--NilsLindenberg
''See also WikkaSecureConfig for a possible new appraoch. --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
----
==Online editing of mindmaps would be great==
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
----
==Tables ==
For the discussion on tables in Wikka, take a look at WikkaTables.
~&See also TableAction for a preliminary solution. --JavaWoman
----
==Wikka Exporting/Importing ==
Just added a few thoughts [[WikkaFilters here]]
-- DarTar
----
==how to format code to get two % characters without space together?==
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
----
==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
----
==showing comments==
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
----
==Language support==
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
----
== 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
----
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
----
== 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
----
==Using FPDF with Wikka==
Not so much a suggestion, more a request although it may be useful to others.
I have been using FPDF from [[http://www.fpdf.org FPDF ]] to export content from a database to pdf files.
I would like to extend my usage of FPDF to wikka by adding a hyperlink to the top of my wikka pages which would allow me to post the page tag or page id to the FPDF script for exporting the content into a pdf file.
The link would be in the form similar to
http://www.mysite.com/script.php?id=
Can anyone tell me how I can extract the page tag or page id from the wikka_pages table in order to do this.
----
====Resolved Suggestions====
== Question: PHP 4.3 and "mysql_escape_string()"? ==
For the Wikka Wakka Wiki 1.1.4.0 you need at least PHP 4.3 because the "mysql_real_escape_string()" in wakka.php is only available in PHP 4.3. A lot of hoster just offering PHP 4.1 or 4.2. Then you have to replace "mysql_real_escape_string()" with "mysql_escape_string()". What was the reason for the replacement in the new release? Again: Keep on the good work.
-- SkyWalk
~&The reason is that ##mysql_real_escape_string()## is more secure than ##mysql_escape_string()## so we want to take advantage of that; but as implemented this left users of older versions of PHP in the cold. A workaround for this will be in version 1.1.6.0 (see above) - now avaliable as a [[HomePage public beta]]. --JavaWoman
----
== Typo correction in embedded Wiki Edit 2 ==
For the new (1.1.6.0) release, line 645 of wikiedit2/wikiedit2.js should be fixed to say:
%% s += " Ctrl+Shift+Minus - Horizontal line\n";%%
not "horisontal." I've already fixed it in my local copy, but no sense in perpetuating errors. :) --MovieLady
~&Thanks to eagle-eyed JsnX it's //aready// fixed in 1.1.6.0 beta4 :) but thanks for the note! --JavaWoman
~~& Marvelous, thanks! :) --MovieLady
==Compatibility with PHP 4.1.x==
with Debian GNU/Linux 3.0 (woody) are installed PHP 4.1.2 and this version don't support "mysql_real_escape_string" function.
temporary fix on wikka.php head:
%%(php)
if ( ! function_exists("mysql_real_escape_string") )
{
function mysql_real_escape_string($string)
{
return mysql_escape_string($string);
}
}%%
~&This will be in version 1.1.6.0 - now avaliable as a [[HomePage public beta]]. --JavaWoman
==Don't let old pages get indexed==
//(moved to WikkaSpamFighting)//
==User page==
If someone registers as a new user and chooses a Wikiname, his wikinamepage is empty. I think it would be nice, if the page whould be created from the wiki, containing a text with perhaps a welcome, some (Wiki)rules and usefull pages (this text should be stored somewhere so that it could be customized from the WikiAdmin). The page should automatically belong to the category user. Regards, NilsLindenberg
==Non-breaking space in forced links==
Sometimes a forced link has a phrase as link description with spaces for readability but where these spaces should **not** cause wrapping in the middle of the string - in other words, the spaces really should be non-breaking spaces. Unfortunately, specifying ## ## will (unlike here) result in the entity becoming visible as an entity instead of as the character it encodes.
It should be possible to either specify ## ## where needed and have it result in the actual character (i.e., keep the actual entity rather than "escaping" it), or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
//**Note:** Actually, with the 1.1.6.0 beta version running on this site, this demonstrates how the new htmlspecialchars_unicode() function is indeed buggy - as I pointed out on WikkaDevelopment. The solution is presented [[WikkaDevelopment there]] now (look for **htmlspecialchars_unicode()**).//
--JavaWoman
==User Control==
Is there an easy way to not allow registration? I would like to have it so that I can control the registration process, not let just anyone sign-up.
--BooYa
... (Nils proposing a solution)
A nice contribution Nils. If you want to go further with fiddling with the code for registration, I've thought it would be useful if there was a feature that required a password from an administrator to be able to register so that if you were going to register you put in your user info (as now) and a password you've obtained from the admin that allows you to register....for instance, in this way a teacher could set up a wikki with registration "on" and send a note to all of the parents with the registration password so that they could register....outsiders couldn't register, only those with the registration key. Possibly a quite useful feature to many potential user groups. -- GmBowen
~Look at UserRegistration for the first version, or [[http://www.niehle.info/UserSettings try it]] --NilsLindenberg
----
==Cookies and logging out==
This issue issue moved to StayingLoggedIn!
==Page viewed counter==
It occurs to me that some kind of "counter" for how many times the wikipage has been viewed might be a useful "action" for somebody to be able to use...this way a page author would know how often somebody has gone to the page & this might help focus development (especially for those keeners that have multiple pages/projects). [and I agree with the contributor below....Wikkawiki is great software]
''I completed altering a script and modifying the wikka code for this.....go to GmBowenCounter for the php script and the necessary alterations'' --GmBowen
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
==Mod rewrite and a problem==
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough?
''Good catch. Adding the end slash should be fine. It will be added by default in the next Wikka release. -- Jsnx''
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. -- JockeAndersson
''Jocke, in the style sheet [wikka.css by default], add "text-decoration: none;" to the smallprint style. Or am I not understanding the problem? -- JsnX''
~~~.smallprint a {
~~~color: #987;
~~~text-decoration: none;
~~~}
It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
The reason the above addition to smallprint doesn't work is that the links are visited meaning the pseudo-class a:visited must be defined as well with "text-decoration: none" in it. There is no definition for a:visited in the css by default. Perhaps this should be added to Wikka's code? -- JockeAndersson
Sure, I'll add it. Just curious though, what web browser are you using? Internet Explorer does not show underlined links as you have described...at least not for me. -- JsnX
I'm currently using Mozilla Firefox, but I'm testing pages in IE as well. The underlines were only visible in Firefox. IE is usually the one to screw up page rendering, not being fully standards-compliant and all. Oh, and the code could use an a:active definition as well. Be sure to define them in correct order though: a visited hover active. W3C were specific about that for some reason. -- JockeAndersson
Thanks for the tip. By the way, your site looks awesome. -- JsnX
You really think so? Thanks!! :) Much of the general layout comes from A List Apart's site, but adapted to my needs. I've had a site running for a while but can't find the time to update it properly. I believe Wikka will change all that and am seriously thinking of replacing my ordinary site with a Wikka wiki. The forum will still be phpbb, but the site itself could really benefit from the pros of Wikka. I second [[MarkHissinkMuller MarkHissinkMullers]] suggestions for improvement. Especially the possibility to manage ACLs based on user groups as well as individual users, would be great. -- JockeAndersson
~& I tried to do something like this at ACLsWithUserGroups.
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action (LOL) if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}""). -- Mike Bowen
----
CategoryWikka
Deletions:
{{lastedit show="3"}}
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
**See also:**
~-WikkaSpamFighting for spam-related issues
~-WikkaWorkarounds for specific platforms
~-WikkaOptimization
>>{{feedback}}::c::
===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
----
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
%% 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
----
===Section Editing Redux===
Instead of a full blown section editing implementation why not just implement a tag like '<WikiPage>' which inserts the contents of WikiPage (no comments) at the markers location. <WikiPage x> would insert the first x lines of the WikiPage into the current page. And/or <WikiPage Header> would pull just the section of the page which is demarked by Header and EOP or next header. Such sections can be inserted in a special color/block/font/whatever and automatically link back to the original page for editing. The goal is to provide better editing granularity and readability on pages which have lots of information density. Could also be used to mimic blog functionality. -KarmaTester
----
===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
~~& 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
----
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
----
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) open a ##/raw## version of the page;
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
~1) open a text editor;
~1) copy the code block;
~1) paste it in the text editor;
~1) save the file.
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
%%
include ('Wakka.class.php');
%%
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
----
===phpMyEdit in Wikka===
I've set up a demo of [[http://www.jsnx.com/wikka-dev/SuggestionBox phpMyEdit running within Wikka]]. This would be useful for anyone wanting to directly interact with MySQL tables from a Wikka page. -- JsnX
~&I assume this is meant for admins only but ... Could you add some explanation? I looked but don't have a clue how to use it. What are the radio buttons for, for instance? What's the "V" button at the top? The UI is very confusing. --JavaWoman
~~& Jsnx, that's interesting. I think the idea is worth consideration. I have used phpMyEdit as an interface to allow my users to store their profiles in the DB when I still was a MySQL newbie :) and it's true that it allows a number of tricky things (especially cross-reference between tables). So I think a plugin for integrating phpMyEdit within Wikka pages might be a nice extension. You probably know though that all the interface options can only be set by editing the source, or were you thinking of allowing some kind of admin access to the interface options? And be honest, are you thinking of phpMyEdit as a sort of replacement for my baby admin actions, aren't you?! In a sense this might be interesting, but it would really be unnecessary compared to what we can do by creating direct calls to the DB using core functions. Why heavily tweak an external script to do something wikka-like if we can already use something that only needs core functions? --- Moreover, when you perform operations on pages (like 'add', 'copy' or 'delete') you generally want to do something more complicated than just modify single records of the page table. Using phpMyEdit as a sort of proxy for a page admin action can lead to major inconsistencies in the page structure. --- And, JW, the "v" button is for filtering the table ;-) -- DarTar
~~~&DarTar, that's silly. The admin actions that you have developed are looking fantastic! I was never thinking of using phpMyEdit to replace your actions. I'm using phpMyEdit to interface with non-Wikka tables; I like to see the data shown from Wikka, and I also like being able to use Wikka formatting within the data. It might help if I gave an example of how I use phpMyEdit. [... I'll write an example later on ...] -- JsnX
~~~&Filtering? Well first it's not obvious, nor explained; but I just went back and tried pressing the "v" button - and I get three other mystifying buttons in return. Frankly, I don't want to use something as badly-designed as this. Shudder. DarTar, your Admin functions may need some refinement, but mystifying they are not. Let's stick with those, and build on them. Sorry, JsnX, but this doesn't get my vote. --JavaWoman
~~~~&Thanks for the comments. I expected there would be some reservations about including this in Wikka. I too have some reservations about phpMyEdit. However, with that said, I also find it to be a **very useful** tool which I will continue to use. It doesn't matter to me whether phpMyEdit is ever an official Wikka component because using it requires zero modifications to the Wikka code -- there will be no ongoing maintenance when upgrading to new Wikka versions. It's not my intention to support this, but if someone wants to use it, I'm happy to make my modified phpMyEdit version available. I'm proposing this as an official "unofficial Wikka add-on". :) -- JsnX
~&I am interested by the idea to interact with MySQL tables from a Wikka page. Would you please share the updated phpMyEdit code? --ChristianBarthelemy
~~&Yes, I plan to play around with it for a few more days, then I'll upload the code and some instructions. -- JsnX
~~~&Hi Jason, I am still interested to know more about this... --ChristianBarthelemy
~&Well, Jason, I do think it would help I you would explain what you are using this **for** (especially if not for Wikka administration); I'd also like to know then why you chose phpMyEdit and not another browser-based client - and why a browser-based client in the first place. I've only ever tried phpMyAdmin and found it lacking because it tends (tended) to work on single tables only. I quickly switched to "real" clients that are more powerful and allow me to build queries involving several tables if needed, so consistency can be maintained. I have a bunch of handy tools (for Windows), all free: for design, administration and maintenance. And though I do have phpMyAdmin available, I don't intend to use it. --JavaWoman
~~&My bet is that Jason's using it to fix the pages where I've (inadertently) submitted double percent signs as part of submitted code so that the history feature works properly. {grin} --GmBowen
~~~&LOL! But - "inadvertently"? Using double percent signs should be possible in code - and if not, that's a bug in Wikka, not your fault! (Not that I have a solution for that yet, though I have been thinking about that problem.) --JavaWoman
----
===Support for (Technorati) tags===
I think it might be interesting to provide Wikka support for (Technorati) "**tags**". "Tags" in this context are simple keywords that help identify and categorize web content, in particular blog posts. Such keywords coupled with a ping system can be used by remote servers to retrieve fresh content for specific topics. See for instance how technorati.com aggregates fresh information about [[http://www.technorati.com/tag/wiki wikis]] from a number of sources.
[[http://www.technorati.com/help/tags.html More information on Technorati tags]]
~&Seems like we need to update our RSS (feed) implementation first... --JavaWoman
----
===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
----
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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?
--GregorLindner
----
==Signature==
(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
----
== 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
----
== Create rewrite rules on install ==
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
== Image dimensions ==
The [[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
----
==Clearing ACLs==
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
----
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
== RSS options ==
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
----
== 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
----
== Language file ==
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
== 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
----
==Finally using CVS?==
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
==Stopping Spammers getting Google Juice==
//(moved to WikkaSpamFighting)//
----
==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
----
==Give control over HTML (using a templating system)==
It would be nice to see a template engine in Wikka to give the users the full control over the HTML source. Smarty is always a good choice.
~& I would love to see Wikka adopt some type of template system. I think that its is sorely needed. Changing the look of Wikka requires tedious editing of php files, and alot of the time it is non-obvious where you need to go to edit such files. Another alternative to [[http://smarty.php.net Smarty]] could be [[http://wiki.ciaweb.net/yawiki/index.php?area=Savant Savant]]. --KickTheDonkey
~~&While I use and like Smarty very much (and it's quite fast), it's rather "heavy" for Wikka, I think. I just had a look at Savant2 which I hadn't heard of before. It looks like a good fit, is lightweight and easy to use. A templating system like this would also provide much more flexibility for Wikka admins to have control over page structure and layout. I'll want to play with it some (in combination with Wikka), but my first impression based on documentation and code is very favorable. More when I've had a chance to exercise it. --JavaWoman
~~~&I'm sorry JW, but what do you mean by Smarty being rather "heavy" for Wikka? Resource-wise? Hard to use / implement? Difficult for the end user? -- FernandoBorcel
~~~~&Fernando, I mean it's "heavy" in two respects, actualy: 1) in terms of code size (currently Smarty is 137K compared to Wikka's 524K - zipped - while for instance Savant is only 39K); 2) in terms of usability - while it's quite powerful, there is a rather steep learning curve for those who've never worked with templates; Savant is simpler and much easier to learn, and looks still quite flexible. I'm not sure about resource usage, but I suspect that in that respect it might be heavier than Savant as well. We'd like to keep Wikka easy to use both for WikiAdmins and for WikiUsers. I still have to actually try Savant with Wikka, but from what I've see so far it fits our profile better, I think. Anyway, before we go forward with something like this, more research will be needed. --JavaWoman
----
==Allow spaces in pagetitle==
Allow Spaces in the document title and replace it later with "-" to optimize it for search engines.
----
==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
----
==Local links==
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--KickTheDonkey
----
==Idea for Category Support==
moved to CategorySystemOverhaul, it is the better place, thanks DarTar
--ArpY
~& ArpY, take a look at CategorySystemOverhaul for an open discussion on how to improve the category system -- DarTar
----
==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.
----
==Section Editing ==
- http://c2.com/cgi/wiki?SectionEditing
- It makes allows you to flow and edit much quicker.
- Each topic should have a corresponding edit button. This allows your to edit each section with out breaking your flow.
- http://www.splitbrain.org/dokuwiki/wiki:section_editing
----
==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
----
==Standard date and time format==
Although I'm all for using the ISO date/time format as we see in the timestamp of the footer of every page, I note that several other parts of Wikka use different date/time formats. I'd like to see an approach where this is standardized.
Proposal:
~-Define date-time format (or separately date and time, as well as a way to combine them) in the configuration; use the ISO format as a default (in the initial configuration, as well as when no format is defined in the config).
~-Use this format wherever date and/or time are formatted.
~-Make using the configured formats a requirement for every Wikka extension (that displays date/time information) to be included with the distribution.
I realize that in principle it's possible to pick up formats from a locale but for a Wikka targeted at an international audience this may not be the best approach, and for a Wikka with a "local" audience it may not be either if it's hosted on a (public) server outside that country - hence the idea to define a format in the configuration.
--JavaWoman
~''Agreed -- DarTar''
----
==Handling the config==
I have three questions about the config. See HandlingWikkaConfig.
--NilsLindenberg
''See also WikkaSecureConfig for a possible new appraoch. --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
----
==Online editing of mindmaps would be great==
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
----
==Tables ==
For the discussion on tables in Wikka, take a look at WikkaTables.
~&See also TableAction for a preliminary solution. --JavaWoman
----
==Wikka Exporting/Importing ==
Just added a few thoughts [[WikkaFilters here]]
-- DarTar
----
==how to format code to get two % characters without space together?==
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
----
==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
----
==showing comments==
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
----
==Language support==
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
----
== 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
----
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
----
== 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
----
==Using FPDF with Wikka==
Not so much a suggestion, more a request although it may be useful to others.
I have been using FPDF from [[http://www.fpdf.org FPDF ]] to export content from a database to pdf files.
I would like to extend my usage of FPDF to wikka by adding a hyperlink to the top of my wikka pages which would allow me to post the page tag or page id to the FPDF script for exporting the content into a pdf file.
The link would be in the form similar to
http://www.mysite.com/script.php?id=
Can anyone tell me how I can extract the page tag or page id from the wikka_pages table in order to do this.
----
====Resolved Suggestions====
== Question: PHP 4.3 and "mysql_escape_string()"? ==
For the Wikka Wakka Wiki 1.1.4.0 you need at least PHP 4.3 because the "mysql_real_escape_string()" in wakka.php is only available in PHP 4.3. A lot of hoster just offering PHP 4.1 or 4.2. Then you have to replace "mysql_real_escape_string()" with "mysql_escape_string()". What was the reason for the replacement in the new release? Again: Keep on the good work.
-- SkyWalk
~&The reason is that ##mysql_real_escape_string()## is more secure than ##mysql_escape_string()## so we want to take advantage of that; but as implemented this left users of older versions of PHP in the cold. A workaround for this will be in version 1.1.6.0 (see above) - now avaliable as a [[HomePage public beta]]. --JavaWoman
----
== Typo correction in embedded Wiki Edit 2 ==
For the new (1.1.6.0) release, line 645 of wikiedit2/wikiedit2.js should be fixed to say:
%% s += " Ctrl+Shift+Minus - Horizontal line\n";%%
not "horisontal." I've already fixed it in my local copy, but no sense in perpetuating errors. :) --MovieLady
~&Thanks to eagle-eyed JsnX it's //aready// fixed in 1.1.6.0 beta4 :) but thanks for the note! --JavaWoman
~~& Marvelous, thanks! :) --MovieLady
==Compatibility with PHP 4.1.x==
with Debian GNU/Linux 3.0 (woody) are installed PHP 4.1.2 and this version don't support "mysql_real_escape_string" function.
temporary fix on wikka.php head:
%%(php)
if ( ! function_exists("mysql_real_escape_string") )
{
function mysql_real_escape_string($string)
{
return mysql_escape_string($string);
}
}%%
~&This will be in version 1.1.6.0 - now avaliable as a [[HomePage public beta]]. --JavaWoman
==Don't let old pages get indexed==
//(moved to WikkaSpamFighting)//
==User page==
If someone registers as a new user and chooses a Wikiname, his wikinamepage is empty. I think it would be nice, if the page whould be created from the wiki, containing a text with perhaps a welcome, some (Wiki)rules and usefull pages (this text should be stored somewhere so that it could be customized from the WikiAdmin). The page should automatically belong to the category user. Regards, NilsLindenberg
==Non-breaking space in forced links==
Sometimes a forced link has a phrase as link description with spaces for readability but where these spaces should **not** cause wrapping in the middle of the string - in other words, the spaces really should be non-breaking spaces. Unfortunately, specifying ## ## will (unlike here) result in the entity becoming visible as an entity instead of as the character it encodes.
It should be possible to either specify ## ## where needed and have it result in the actual character (i.e., keep the actual entity rather than "escaping" it), or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
//**Note:** Actually, with the 1.1.6.0 beta version running on this site, this demonstrates how the new htmlspecialchars_unicode() function is indeed buggy - as I pointed out on WikkaDevelopment. The solution is presented [[WikkaDevelopment there]] now (look for **htmlspecialchars_unicode()**).//
--JavaWoman
==User Control==
Is there an easy way to not allow registration? I would like to have it so that I can control the registration process, not let just anyone sign-up.
--BooYa
... (Nils proposing a solution)
A nice contribution Nils. If you want to go further with fiddling with the code for registration, I've thought it would be useful if there was a feature that required a password from an administrator to be able to register so that if you were going to register you put in your user info (as now) and a password you've obtained from the admin that allows you to register....for instance, in this way a teacher could set up a wikki with registration "on" and send a note to all of the parents with the registration password so that they could register....outsiders couldn't register, only those with the registration key. Possibly a quite useful feature to many potential user groups. -- GmBowen
~Look at UserRegistration for the first version, or [[http://www.niehle.info/UserSettings try it]] --NilsLindenberg
----
==Cookies and logging out==
This issue issue moved to StayingLoggedIn!
==Page viewed counter==
It occurs to me that some kind of "counter" for how many times the wikipage has been viewed might be a useful "action" for somebody to be able to use...this way a page author would know how often somebody has gone to the page & this might help focus development (especially for those keeners that have multiple pages/projects). [and I agree with the contributor below....Wikkawiki is great software]
''I completed altering a script and modifying the wikka code for this.....go to GmBowenCounter for the php script and the necessary alterations'' --GmBowen
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
==Mod rewrite and a problem==
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough?
''Good catch. Adding the end slash should be fine. It will be added by default in the next Wikka release. -- Jsnx''
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. -- JockeAndersson
''Jocke, in the style sheet [wikka.css by default], add "text-decoration: none;" to the smallprint style. Or am I not understanding the problem? -- JsnX''
~~~.smallprint a {
~~~color: #987;
~~~text-decoration: none;
~~~}
It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
The reason the above addition to smallprint doesn't work is that the links are visited meaning the pseudo-class a:visited must be defined as well with "text-decoration: none" in it. There is no definition for a:visited in the css by default. Perhaps this should be added to Wikka's code? -- JockeAndersson
Sure, I'll add it. Just curious though, what web browser are you using? Internet Explorer does not show underlined links as you have described...at least not for me. -- JsnX
I'm currently using Mozilla Firefox, but I'm testing pages in IE as well. The underlines were only visible in Firefox. IE is usually the one to screw up page rendering, not being fully standards-compliant and all. Oh, and the code could use an a:active definition as well. Be sure to define them in correct order though: a visited hover active. W3C were specific about that for some reason. -- JockeAndersson
Thanks for the tip. By the way, your site looks awesome. -- JsnX
You really think so? Thanks!! :) Much of the general layout comes from A List Apart's site, but adapted to my needs. I've had a site running for a while but can't find the time to update it properly. I believe Wikka will change all that and am seriously thinking of replacing my ordinary site with a Wikka wiki. The forum will still be phpbb, but the site itself could really benefit from the pros of Wikka. I second [[MarkHissinkMuller MarkHissinkMullers]] suggestions for improvement. Especially the possibility to manage ACLs based on user groups as well as individual users, would be great. -- JockeAndersson
~& I tried to do something like this at ACLsWithUserGroups.
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action (LOL) if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}""). -- Mike Bowen
----
CategoryWikka
Additions:
=====Suggestion Box=====
{{lastedit show="3"}}
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
**See also:**
~-WikkaSpamFighting for spam-related issues
~-WikkaWorkarounds for specific platforms
~-WikkaOptimization
>>{{feedback}}::c::
===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
----
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
%% 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
----
===Section Editing Redux===
Instead of a full blown section editing implementation why not just implement a tag like '<WikiPage>' which inserts the contents of WikiPage (no comments) at the markers location. <WikiPage x> would insert the first x lines of the WikiPage into the current page. And/or <WikiPage Header> would pull just the section of the page which is demarked by Header and EOP or next header. Such sections can be inserted in a special color/block/font/whatever and automatically link back to the original page for editing. The goal is to provide better editing granularity and readability on pages which have lots of information density. Could also be used to mimic blog functionality. -KarmaTester
----
===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
~~& 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
----
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
----
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) open a ##/raw## version of the page;
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
~1) open a text editor;
~1) copy the code block;
~1) paste it in the text editor;
~1) save the file.
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
%%
include ('Wakka.class.php');
%%
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
----
===phpMyEdit in Wikka===
I've set up a demo of [[http://www.jsnx.com/wikka-dev/SuggestionBox phpMyEdit running within Wikka]]. This would be useful for anyone wanting to directly interact with MySQL tables from a Wikka page. -- JsnX
~&I assume this is meant for admins only but ... Could you add some explanation? I looked but don't have a clue how to use it. What are the radio buttons for, for instance? What's the "V" button at the top? The UI is very confusing. --JavaWoman
~~& Jsnx, that's interesting. I think the idea is worth consideration. I have used phpMyEdit as an interface to allow my users to store their profiles in the DB when I still was a MySQL newbie :) and it's true that it allows a number of tricky things (especially cross-reference between tables). So I think a plugin for integrating phpMyEdit within Wikka pages might be a nice extension. You probably know though that all the interface options can only be set by editing the source, or were you thinking of allowing some kind of admin access to the interface options? And be honest, are you thinking of phpMyEdit as a sort of replacement for my baby admin actions, aren't you?! In a sense this might be interesting, but it would really be unnecessary compared to what we can do by creating direct calls to the DB using core functions. Why heavily tweak an external script to do something wikka-like if we can already use something that only needs core functions? --- Moreover, when you perform operations on pages (like 'add', 'copy' or 'delete') you generally want to do something more complicated than just modify single records of the page table. Using phpMyEdit as a sort of proxy for a page admin action can lead to major inconsistencies in the page structure. --- And, JW, the "v" button is for filtering the table ;-) -- DarTar
~~~&DarTar, that's silly. The admin actions that you have developed are looking fantastic! I was never thinking of using phpMyEdit to replace your actions. I'm using phpMyEdit to interface with non-Wikka tables; I like to see the data shown from Wikka, and I also like being able to use Wikka formatting within the data. It might help if I gave an example of how I use phpMyEdit. [... I'll write an example later on ...] -- JsnX
~~~&Filtering? Well first it's not obvious, nor explained; but I just went back and tried pressing the "v" button - and I get three other mystifying buttons in return. Frankly, I don't want to use something as badly-designed as this. Shudder. DarTar, your Admin functions may need some refinement, but mystifying they are not. Let's stick with those, and build on them. Sorry, JsnX, but this doesn't get my vote. --JavaWoman
~~~~&Thanks for the comments. I expected there would be some reservations about including this in Wikka. I too have some reservations about phpMyEdit. However, with that said, I also find it to be a **very useful** tool which I will continue to use. It doesn't matter to me whether phpMyEdit is ever an official Wikka component because using it requires zero modifications to the Wikka code -- there will be no ongoing maintenance when upgrading to new Wikka versions. It's not my intention to support this, but if someone wants to use it, I'm happy to make my modified phpMyEdit version available. I'm proposing this as an official "unofficial Wikka add-on". :) -- JsnX
~&I am interested by the idea to interact with MySQL tables from a Wikka page. Would you please share the updated phpMyEdit code? --ChristianBarthelemy
~~&Yes, I plan to play around with it for a few more days, then I'll upload the code and some instructions. -- JsnX
~~~&Hi Jason, I am still interested to know more about this... --ChristianBarthelemy
~&Well, Jason, I do think it would help I you would explain what you are using this **for** (especially if not for Wikka administration); I'd also like to know then why you chose phpMyEdit and not another browser-based client - and why a browser-based client in the first place. I've only ever tried phpMyAdmin and found it lacking because it tends (tended) to work on single tables only. I quickly switched to "real" clients that are more powerful and allow me to build queries involving several tables if needed, so consistency can be maintained. I have a bunch of handy tools (for Windows), all free: for design, administration and maintenance. And though I do have phpMyAdmin available, I don't intend to use it. --JavaWoman
~~&My bet is that Jason's using it to fix the pages where I've (inadertently) submitted double percent signs as part of submitted code so that the history feature works properly. {grin} --GmBowen
~~~&LOL! But - "inadvertently"? Using double percent signs should be possible in code - and if not, that's a bug in Wikka, not your fault! (Not that I have a solution for that yet, though I have been thinking about that problem.) --JavaWoman
----
===Support for (Technorati) tags===
I think it might be interesting to provide Wikka support for (Technorati) "**tags**". "Tags" in this context are simple keywords that help identify and categorize web content, in particular blog posts. Such keywords coupled with a ping system can be used by remote servers to retrieve fresh content for specific topics. See for instance how technorati.com aggregates fresh information about [[http://www.technorati.com/tag/wiki wikis]] from a number of sources.
[[http://www.technorati.com/help/tags.html More information on Technorati tags]]
~&Seems like we need to update our RSS (feed) implementation first... --JavaWoman
----
===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
----
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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?
--GregorLindner
----
==Signature==
(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
----
== 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
----
== Create rewrite rules on install ==
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
== Image dimensions ==
The [[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
----
==Clearing ACLs==
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
----
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
== RSS options ==
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
----
== 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
----
== Language file ==
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
== 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
----
==Finally using CVS?==
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
==Stopping Spammers getting Google Juice==
//(moved to WikkaSpamFighting)//
----
==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
----
==Give control over HTML (using a templating system)==
It would be nice to see a template engine in Wikka to give the users the full control over the HTML source. Smarty is always a good choice.
~& I would love to see Wikka adopt some type of template system. I think that its is sorely needed. Changing the look of Wikka requires tedious editing of php files, and alot of the time it is non-obvious where you need to go to edit such files. Another alternative to [[http://smarty.php.net Smarty]] could be [[http://wiki.ciaweb.net/yawiki/index.php?area=Savant Savant]]. --KickTheDonkey
~~&While I use and like Smarty very much (and it's quite fast), it's rather "heavy" for Wikka, I think. I just had a look at Savant2 which I hadn't heard of before. It looks like a good fit, is lightweight and easy to use. A templating system like this would also provide much more flexibility for Wikka admins to have control over page structure and layout. I'll want to play with it some (in combination with Wikka), but my first impression based on documentation and code is very favorable. More when I've had a chance to exercise it. --JavaWoman
~~~&I'm sorry JW, but what do you mean by Smarty being rather "heavy" for Wikka? Resource-wise? Hard to use / implement? Difficult for the end user? -- FernandoBorcel
~~~~&Fernando, I mean it's "heavy" in two respects, actualy: 1) in terms of code size (currently Smarty is 137K compared to Wikka's 524K - zipped - while for instance Savant is only 39K); 2) in terms of usability - while it's quite powerful, there is a rather steep learning curve for those who've never worked with templates; Savant is simpler and much easier to learn, and looks still quite flexible. I'm not sure about resource usage, but I suspect that in that respect it might be heavier than Savant as well. We'd like to keep Wikka easy to use both for WikiAdmins and for WikiUsers. I still have to actually try Savant with Wikka, but from what I've see so far it fits our profile better, I think. Anyway, before we go forward with something like this, more research will be needed. --JavaWoman
----
==Allow spaces in pagetitle==
Allow Spaces in the document title and replace it later with "-" to optimize it for search engines.
----
==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
----
==Local links==
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--KickTheDonkey
----
==Idea for Category Support==
moved to CategorySystemOverhaul, it is the better place, thanks DarTar
--ArpY
~& ArpY, take a look at CategorySystemOverhaul for an open discussion on how to improve the category system -- DarTar
----
==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.
----
==Section Editing ==
- http://c2.com/cgi/wiki?SectionEditing
- It makes allows you to flow and edit much quicker.
- Each topic should have a corresponding edit button. This allows your to edit each section with out breaking your flow.
- http://www.splitbrain.org/dokuwiki/wiki:section_editing
----
==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
----
==Standard date and time format==
Although I'm all for using the ISO date/time format as we see in the timestamp of the footer of every page, I note that several other parts of Wikka use different date/time formats. I'd like to see an approach where this is standardized.
Proposal:
~-Define date-time format (or separately date and time, as well as a way to combine them) in the configuration; use the ISO format as a default (in the initial configuration, as well as when no format is defined in the config).
~-Use this format wherever date and/or time are formatted.
~-Make using the configured formats a requirement for every Wikka extension (that displays date/time information) to be included with the distribution.
I realize that in principle it's possible to pick up formats from a locale but for a Wikka targeted at an international audience this may not be the best approach, and for a Wikka with a "local" audience it may not be either if it's hosted on a (public) server outside that country - hence the idea to define a format in the configuration.
--JavaWoman
~''Agreed -- DarTar''
----
==Handling the config==
I have three questions about the config. See HandlingWikkaConfig.
--NilsLindenberg
''See also WikkaSecureConfig for a possible new appraoch. --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
----
==Online editing of mindmaps would be great==
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
----
==Tables ==
For the discussion on tables in Wikka, take a look at WikkaTables.
~&See also TableAction for a preliminary solution. --JavaWoman
----
==Wikka Exporting/Importing ==
Just added a few thoughts [[WikkaFilters here]]
-- DarTar
----
==how to format code to get two % characters without space together?==
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
----
==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
----
==showing comments==
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
----
==Language support==
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
----
== 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
----
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
----
== 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
----
==Using FPDF with Wikka==
Not so much a suggestion, more a request although it may be useful to others.
I have been using FPDF from [[http://www.fpdf.org FPDF ]] to export content from a database to pdf files.
I would like to extend my usage of FPDF to wikka by adding a hyperlink to the top of my wikka pages which would allow me to post the page tag or page id to the FPDF script for exporting the content into a pdf file.
The link would be in the form similar to
http://www.mysite.com/script.php?id=
Can anyone tell me how I can extract the page tag or page id from the wikka_pages table in order to do this.
----
====Resolved Suggestions====
== Question: PHP 4.3 and "mysql_escape_string()"? ==
For the Wikka Wakka Wiki 1.1.4.0 you need at least PHP 4.3 because the "mysql_real_escape_string()" in wakka.php is only available in PHP 4.3. A lot of hoster just offering PHP 4.1 or 4.2. Then you have to replace "mysql_real_escape_string()" with "mysql_escape_string()". What was the reason for the replacement in the new release? Again: Keep on the good work.
-- SkyWalk
~&The reason is that ##mysql_real_escape_string()## is more secure than ##mysql_escape_string()## so we want to take advantage of that; but as implemented this left users of older versions of PHP in the cold. A workaround for this will be in version 1.1.6.0 (see above) - now avaliable as a [[HomePage public beta]]. --JavaWoman
----
== Typo correction in embedded Wiki Edit 2 ==
For the new (1.1.6.0) release, line 645 of wikiedit2/wikiedit2.js should be fixed to say:
%% s += " Ctrl+Shift+Minus - Horizontal line\n";%%
not "horisontal." I've already fixed it in my local copy, but no sense in perpetuating errors. :) --MovieLady
~&Thanks to eagle-eyed JsnX it's //aready// fixed in 1.1.6.0 beta4 :) but thanks for the note! --JavaWoman
~~& Marvelous, thanks! :) --MovieLady
==Compatibility with PHP 4.1.x==
with Debian GNU/Linux 3.0 (woody) are installed PHP 4.1.2 and this version don't support "mysql_real_escape_string" function.
temporary fix on wikka.php head:
%%(php)
if ( ! function_exists("mysql_real_escape_string") )
{
function mysql_real_escape_string($string)
{
return mysql_escape_string($string);
}
}%%
~&This will be in version 1.1.6.0 - now avaliable as a [[HomePage public beta]]. --JavaWoman
==Don't let old pages get indexed==
//(moved to WikkaSpamFighting)//
==User page==
If someone registers as a new user and chooses a Wikiname, his wikinamepage is empty. I think it would be nice, if the page whould be created from the wiki, containing a text with perhaps a welcome, some (Wiki)rules and usefull pages (this text should be stored somewhere so that it could be customized from the WikiAdmin). The page should automatically belong to the category user. Regards, NilsLindenberg
==Non-breaking space in forced links==
Sometimes a forced link has a phrase as link description with spaces for readability but where these spaces should **not** cause wrapping in the middle of the string - in other words, the spaces really should be non-breaking spaces. Unfortunately, specifying ## ## will (unlike here) result in the entity becoming visible as an entity instead of as the character it encodes.
It should be possible to either specify ## ## where needed and have it result in the actual character (i.e., keep the actual entity rather than "escaping" it), or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
//**Note:** Actually, with the 1.1.6.0 beta version running on this site, this demonstrates how the new htmlspecialchars_unicode() function is indeed buggy - as I pointed out on WikkaDevelopment. The solution is presented [[WikkaDevelopment there]] now (look for **htmlspecialchars_unicode()**).//
--JavaWoman
==User Control==
Is there an easy way to not allow registration? I would like to have it so that I can control the registration process, not let just anyone sign-up.
--BooYa
... (Nils proposing a solution)
A nice contribution Nils. If you want to go further with fiddling with the code for registration, I've thought it would be useful if there was a feature that required a password from an administrator to be able to register so that if you were going to register you put in your user info (as now) and a password you've obtained from the admin that allows you to register....for instance, in this way a teacher could set up a wikki with registration "on" and send a note to all of the parents with the registration password so that they could register....outsiders couldn't register, only those with the registration key. Possibly a quite useful feature to many potential user groups. -- GmBowen
~Look at UserRegistration for the first version, or [[http://www.niehle.info/UserSettings try it]] --NilsLindenberg
----
==Cookies and logging out==
This issue issue moved to StayingLoggedIn!
==Page viewed counter==
It occurs to me that some kind of "counter" for how many times the wikipage has been viewed might be a useful "action" for somebody to be able to use...this way a page author would know how often somebody has gone to the page & this might help focus development (especially for those keeners that have multiple pages/projects). [and I agree with the contributor below....Wikkawiki is great software]
''I completed altering a script and modifying the wikka code for this.....go to GmBowenCounter for the php script and the necessary alterations'' --GmBowen
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
==Mod rewrite and a problem==
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough?
''Good catch. Adding the end slash should be fine. It will be added by default in the next Wikka release. -- Jsnx''
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. -- JockeAndersson
''Jocke, in the style sheet [wikka.css by default], add "text-decoration: none;" to the smallprint style. Or am I not understanding the problem? -- JsnX''
~~~.smallprint a {
~~~color: #987;
~~~text-decoration: none;
~~~}
It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
The reason the above addition to smallprint doesn't work is that the links are visited meaning the pseudo-class a:visited must be defined as well with "text-decoration: none" in it. There is no definition for a:visited in the css by default. Perhaps this should be added to Wikka's code? -- JockeAndersson
Sure, I'll add it. Just curious though, what web browser are you using? Internet Explorer does not show underlined links as you have described...at least not for me. -- JsnX
I'm currently using Mozilla Firefox, but I'm testing pages in IE as well. The underlines were only visible in Firefox. IE is usually the one to screw up page rendering, not being fully standards-compliant and all. Oh, and the code could use an a:active definition as well. Be sure to define them in correct order though: a visited hover active. W3C were specific about that for some reason. -- JockeAndersson
Thanks for the tip. By the way, your site looks awesome. -- JsnX
You really think so? Thanks!! :) Much of the general layout comes from A List Apart's site, but adapted to my needs. I've had a site running for a while but can't find the time to update it properly. I believe Wikka will change all that and am seriously thinking of replacing my ordinary site with a Wikka wiki. The forum will still be phpbb, but the site itself could really benefit from the pros of Wikka. I second [[MarkHissinkMuller MarkHissinkMullers]] suggestions for improvement. Especially the possibility to manage ACLs based on user groups as well as individual users, would be great. -- JockeAndersson
~& I tried to do something like this at ACLsWithUserGroups.
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action (LOL) if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}""). -- Mike Bowen
----
CategoryWikka
{{lastedit show="3"}}
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
**See also:**
~-WikkaSpamFighting for spam-related issues
~-WikkaWorkarounds for specific platforms
~-WikkaOptimization
>>{{feedback}}::c::
===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
----
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
%% 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
----
===Section Editing Redux===
Instead of a full blown section editing implementation why not just implement a tag like '<WikiPage>' which inserts the contents of WikiPage (no comments) at the markers location. <WikiPage x> would insert the first x lines of the WikiPage into the current page. And/or <WikiPage Header> would pull just the section of the page which is demarked by Header and EOP or next header. Such sections can be inserted in a special color/block/font/whatever and automatically link back to the original page for editing. The goal is to provide better editing granularity and readability on pages which have lots of information density. Could also be used to mimic blog functionality. -KarmaTester
----
===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
~~& 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
----
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
----
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) open a ##/raw## version of the page;
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
~1) open a text editor;
~1) copy the code block;
~1) paste it in the text editor;
~1) save the file.
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
%%
include ('Wakka.class.php');
%%
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
----
===phpMyEdit in Wikka===
I've set up a demo of [[http://www.jsnx.com/wikka-dev/SuggestionBox phpMyEdit running within Wikka]]. This would be useful for anyone wanting to directly interact with MySQL tables from a Wikka page. -- JsnX
~&I assume this is meant for admins only but ... Could you add some explanation? I looked but don't have a clue how to use it. What are the radio buttons for, for instance? What's the "V" button at the top? The UI is very confusing. --JavaWoman
~~& Jsnx, that's interesting. I think the idea is worth consideration. I have used phpMyEdit as an interface to allow my users to store their profiles in the DB when I still was a MySQL newbie :) and it's true that it allows a number of tricky things (especially cross-reference between tables). So I think a plugin for integrating phpMyEdit within Wikka pages might be a nice extension. You probably know though that all the interface options can only be set by editing the source, or were you thinking of allowing some kind of admin access to the interface options? And be honest, are you thinking of phpMyEdit as a sort of replacement for my baby admin actions, aren't you?! In a sense this might be interesting, but it would really be unnecessary compared to what we can do by creating direct calls to the DB using core functions. Why heavily tweak an external script to do something wikka-like if we can already use something that only needs core functions? --- Moreover, when you perform operations on pages (like 'add', 'copy' or 'delete') you generally want to do something more complicated than just modify single records of the page table. Using phpMyEdit as a sort of proxy for a page admin action can lead to major inconsistencies in the page structure. --- And, JW, the "v" button is for filtering the table ;-) -- DarTar
~~~&DarTar, that's silly. The admin actions that you have developed are looking fantastic! I was never thinking of using phpMyEdit to replace your actions. I'm using phpMyEdit to interface with non-Wikka tables; I like to see the data shown from Wikka, and I also like being able to use Wikka formatting within the data. It might help if I gave an example of how I use phpMyEdit. [... I'll write an example later on ...] -- JsnX
~~~&Filtering? Well first it's not obvious, nor explained; but I just went back and tried pressing the "v" button - and I get three other mystifying buttons in return. Frankly, I don't want to use something as badly-designed as this. Shudder. DarTar, your Admin functions may need some refinement, but mystifying they are not. Let's stick with those, and build on them. Sorry, JsnX, but this doesn't get my vote. --JavaWoman
~~~~&Thanks for the comments. I expected there would be some reservations about including this in Wikka. I too have some reservations about phpMyEdit. However, with that said, I also find it to be a **very useful** tool which I will continue to use. It doesn't matter to me whether phpMyEdit is ever an official Wikka component because using it requires zero modifications to the Wikka code -- there will be no ongoing maintenance when upgrading to new Wikka versions. It's not my intention to support this, but if someone wants to use it, I'm happy to make my modified phpMyEdit version available. I'm proposing this as an official "unofficial Wikka add-on". :) -- JsnX
~&I am interested by the idea to interact with MySQL tables from a Wikka page. Would you please share the updated phpMyEdit code? --ChristianBarthelemy
~~&Yes, I plan to play around with it for a few more days, then I'll upload the code and some instructions. -- JsnX
~~~&Hi Jason, I am still interested to know more about this... --ChristianBarthelemy
~&Well, Jason, I do think it would help I you would explain what you are using this **for** (especially if not for Wikka administration); I'd also like to know then why you chose phpMyEdit and not another browser-based client - and why a browser-based client in the first place. I've only ever tried phpMyAdmin and found it lacking because it tends (tended) to work on single tables only. I quickly switched to "real" clients that are more powerful and allow me to build queries involving several tables if needed, so consistency can be maintained. I have a bunch of handy tools (for Windows), all free: for design, administration and maintenance. And though I do have phpMyAdmin available, I don't intend to use it. --JavaWoman
~~&My bet is that Jason's using it to fix the pages where I've (inadertently) submitted double percent signs as part of submitted code so that the history feature works properly. {grin} --GmBowen
~~~&LOL! But - "inadvertently"? Using double percent signs should be possible in code - and if not, that's a bug in Wikka, not your fault! (Not that I have a solution for that yet, though I have been thinking about that problem.) --JavaWoman
----
===Support for (Technorati) tags===
I think it might be interesting to provide Wikka support for (Technorati) "**tags**". "Tags" in this context are simple keywords that help identify and categorize web content, in particular blog posts. Such keywords coupled with a ping system can be used by remote servers to retrieve fresh content for specific topics. See for instance how technorati.com aggregates fresh information about [[http://www.technorati.com/tag/wiki wikis]] from a number of sources.
[[http://www.technorati.com/help/tags.html More information on Technorati tags]]
~&Seems like we need to update our RSS (feed) implementation first... --JavaWoman
----
===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
----
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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?
--GregorLindner
----
==Signature==
(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
----
== 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
----
== Create rewrite rules on install ==
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
== Image dimensions ==
The [[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
----
==Clearing ACLs==
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
----
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
== RSS options ==
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
----
== 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
----
== Language file ==
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
== 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
----
==Finally using CVS?==
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
==Stopping Spammers getting Google Juice==
//(moved to WikkaSpamFighting)//
----
==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
----
==Give control over HTML (using a templating system)==
It would be nice to see a template engine in Wikka to give the users the full control over the HTML source. Smarty is always a good choice.
~& I would love to see Wikka adopt some type of template system. I think that its is sorely needed. Changing the look of Wikka requires tedious editing of php files, and alot of the time it is non-obvious where you need to go to edit such files. Another alternative to [[http://smarty.php.net Smarty]] could be [[http://wiki.ciaweb.net/yawiki/index.php?area=Savant Savant]]. --KickTheDonkey
~~&While I use and like Smarty very much (and it's quite fast), it's rather "heavy" for Wikka, I think. I just had a look at Savant2 which I hadn't heard of before. It looks like a good fit, is lightweight and easy to use. A templating system like this would also provide much more flexibility for Wikka admins to have control over page structure and layout. I'll want to play with it some (in combination with Wikka), but my first impression based on documentation and code is very favorable. More when I've had a chance to exercise it. --JavaWoman
~~~&I'm sorry JW, but what do you mean by Smarty being rather "heavy" for Wikka? Resource-wise? Hard to use / implement? Difficult for the end user? -- FernandoBorcel
~~~~&Fernando, I mean it's "heavy" in two respects, actualy: 1) in terms of code size (currently Smarty is 137K compared to Wikka's 524K - zipped - while for instance Savant is only 39K); 2) in terms of usability - while it's quite powerful, there is a rather steep learning curve for those who've never worked with templates; Savant is simpler and much easier to learn, and looks still quite flexible. I'm not sure about resource usage, but I suspect that in that respect it might be heavier than Savant as well. We'd like to keep Wikka easy to use both for WikiAdmins and for WikiUsers. I still have to actually try Savant with Wikka, but from what I've see so far it fits our profile better, I think. Anyway, before we go forward with something like this, more research will be needed. --JavaWoman
----
==Allow spaces in pagetitle==
Allow Spaces in the document title and replace it later with "-" to optimize it for search engines.
----
==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
----
==Local links==
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--KickTheDonkey
----
==Idea for Category Support==
moved to CategorySystemOverhaul, it is the better place, thanks DarTar
--ArpY
~& ArpY, take a look at CategorySystemOverhaul for an open discussion on how to improve the category system -- DarTar
----
==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.
----
==Section Editing ==
- http://c2.com/cgi/wiki?SectionEditing
- It makes allows you to flow and edit much quicker.
- Each topic should have a corresponding edit button. This allows your to edit each section with out breaking your flow.
- http://www.splitbrain.org/dokuwiki/wiki:section_editing
----
==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
----
==Standard date and time format==
Although I'm all for using the ISO date/time format as we see in the timestamp of the footer of every page, I note that several other parts of Wikka use different date/time formats. I'd like to see an approach where this is standardized.
Proposal:
~-Define date-time format (or separately date and time, as well as a way to combine them) in the configuration; use the ISO format as a default (in the initial configuration, as well as when no format is defined in the config).
~-Use this format wherever date and/or time are formatted.
~-Make using the configured formats a requirement for every Wikka extension (that displays date/time information) to be included with the distribution.
I realize that in principle it's possible to pick up formats from a locale but for a Wikka targeted at an international audience this may not be the best approach, and for a Wikka with a "local" audience it may not be either if it's hosted on a (public) server outside that country - hence the idea to define a format in the configuration.
--JavaWoman
~''Agreed -- DarTar''
----
==Handling the config==
I have three questions about the config. See HandlingWikkaConfig.
--NilsLindenberg
''See also WikkaSecureConfig for a possible new appraoch. --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
----
==Online editing of mindmaps would be great==
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
----
==Tables ==
For the discussion on tables in Wikka, take a look at WikkaTables.
~&See also TableAction for a preliminary solution. --JavaWoman
----
==Wikka Exporting/Importing ==
Just added a few thoughts [[WikkaFilters here]]
-- DarTar
----
==how to format code to get two % characters without space together?==
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
----
==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
----
==showing comments==
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
----
==Language support==
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
----
== 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
----
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
----
== 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
----
==Using FPDF with Wikka==
Not so much a suggestion, more a request although it may be useful to others.
I have been using FPDF from [[http://www.fpdf.org FPDF ]] to export content from a database to pdf files.
I would like to extend my usage of FPDF to wikka by adding a hyperlink to the top of my wikka pages which would allow me to post the page tag or page id to the FPDF script for exporting the content into a pdf file.
The link would be in the form similar to
http://www.mysite.com/script.php?id=
Can anyone tell me how I can extract the page tag or page id from the wikka_pages table in order to do this.
----
====Resolved Suggestions====
== Question: PHP 4.3 and "mysql_escape_string()"? ==
For the Wikka Wakka Wiki 1.1.4.0 you need at least PHP 4.3 because the "mysql_real_escape_string()" in wakka.php is only available in PHP 4.3. A lot of hoster just offering PHP 4.1 or 4.2. Then you have to replace "mysql_real_escape_string()" with "mysql_escape_string()". What was the reason for the replacement in the new release? Again: Keep on the good work.
-- SkyWalk
~&The reason is that ##mysql_real_escape_string()## is more secure than ##mysql_escape_string()## so we want to take advantage of that; but as implemented this left users of older versions of PHP in the cold. A workaround for this will be in version 1.1.6.0 (see above) - now avaliable as a [[HomePage public beta]]. --JavaWoman
----
== Typo correction in embedded Wiki Edit 2 ==
For the new (1.1.6.0) release, line 645 of wikiedit2/wikiedit2.js should be fixed to say:
%% s += " Ctrl+Shift+Minus - Horizontal line\n";%%
not "horisontal." I've already fixed it in my local copy, but no sense in perpetuating errors. :) --MovieLady
~&Thanks to eagle-eyed JsnX it's //aready// fixed in 1.1.6.0 beta4 :) but thanks for the note! --JavaWoman
~~& Marvelous, thanks! :) --MovieLady
==Compatibility with PHP 4.1.x==
with Debian GNU/Linux 3.0 (woody) are installed PHP 4.1.2 and this version don't support "mysql_real_escape_string" function.
temporary fix on wikka.php head:
%%(php)
if ( ! function_exists("mysql_real_escape_string") )
{
function mysql_real_escape_string($string)
{
return mysql_escape_string($string);
}
}%%
~&This will be in version 1.1.6.0 - now avaliable as a [[HomePage public beta]]. --JavaWoman
==Don't let old pages get indexed==
//(moved to WikkaSpamFighting)//
==User page==
If someone registers as a new user and chooses a Wikiname, his wikinamepage is empty. I think it would be nice, if the page whould be created from the wiki, containing a text with perhaps a welcome, some (Wiki)rules and usefull pages (this text should be stored somewhere so that it could be customized from the WikiAdmin). The page should automatically belong to the category user. Regards, NilsLindenberg
==Non-breaking space in forced links==
Sometimes a forced link has a phrase as link description with spaces for readability but where these spaces should **not** cause wrapping in the middle of the string - in other words, the spaces really should be non-breaking spaces. Unfortunately, specifying ## ## will (unlike here) result in the entity becoming visible as an entity instead of as the character it encodes.
It should be possible to either specify ## ## where needed and have it result in the actual character (i.e., keep the actual entity rather than "escaping" it), or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
//**Note:** Actually, with the 1.1.6.0 beta version running on this site, this demonstrates how the new htmlspecialchars_unicode() function is indeed buggy - as I pointed out on WikkaDevelopment. The solution is presented [[WikkaDevelopment there]] now (look for **htmlspecialchars_unicode()**).//
--JavaWoman
==User Control==
Is there an easy way to not allow registration? I would like to have it so that I can control the registration process, not let just anyone sign-up.
--BooYa
... (Nils proposing a solution)
A nice contribution Nils. If you want to go further with fiddling with the code for registration, I've thought it would be useful if there was a feature that required a password from an administrator to be able to register so that if you were going to register you put in your user info (as now) and a password you've obtained from the admin that allows you to register....for instance, in this way a teacher could set up a wikki with registration "on" and send a note to all of the parents with the registration password so that they could register....outsiders couldn't register, only those with the registration key. Possibly a quite useful feature to many potential user groups. -- GmBowen
~Look at UserRegistration for the first version, or [[http://www.niehle.info/UserSettings try it]] --NilsLindenberg
----
==Cookies and logging out==
This issue issue moved to StayingLoggedIn!
==Page viewed counter==
It occurs to me that some kind of "counter" for how many times the wikipage has been viewed might be a useful "action" for somebody to be able to use...this way a page author would know how often somebody has gone to the page & this might help focus development (especially for those keeners that have multiple pages/projects). [and I agree with the contributor below....Wikkawiki is great software]
''I completed altering a script and modifying the wikka code for this.....go to GmBowenCounter for the php script and the necessary alterations'' --GmBowen
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
==Mod rewrite and a problem==
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough?
''Good catch. Adding the end slash should be fine. It will be added by default in the next Wikka release. -- Jsnx''
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. -- JockeAndersson
''Jocke, in the style sheet [wikka.css by default], add "text-decoration: none;" to the smallprint style. Or am I not understanding the problem? -- JsnX''
~~~.smallprint a {
~~~color: #987;
~~~text-decoration: none;
~~~}
It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
The reason the above addition to smallprint doesn't work is that the links are visited meaning the pseudo-class a:visited must be defined as well with "text-decoration: none" in it. There is no definition for a:visited in the css by default. Perhaps this should be added to Wikka's code? -- JockeAndersson
Sure, I'll add it. Just curious though, what web browser are you using? Internet Explorer does not show underlined links as you have described...at least not for me. -- JsnX
I'm currently using Mozilla Firefox, but I'm testing pages in IE as well. The underlines were only visible in Firefox. IE is usually the one to screw up page rendering, not being fully standards-compliant and all. Oh, and the code could use an a:active definition as well. Be sure to define them in correct order though: a visited hover active. W3C were specific about that for some reason. -- JockeAndersson
Thanks for the tip. By the way, your site looks awesome. -- JsnX
You really think so? Thanks!! :) Much of the general layout comes from A List Apart's site, but adapted to my needs. I've had a site running for a while but can't find the time to update it properly. I believe Wikka will change all that and am seriously thinking of replacing my ordinary site with a Wikka wiki. The forum will still be phpbb, but the site itself could really benefit from the pros of Wikka. I second [[MarkHissinkMuller MarkHissinkMullers]] suggestions for improvement. Especially the possibility to manage ACLs based on user groups as well as individual users, would be great. -- JockeAndersson
~& I tried to do something like this at ACLsWithUserGroups.
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action (LOL) if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}""). -- Mike Bowen
----
CategoryWikka
Deletions:
{{lastedit show="3"}}
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
**See also:**
~-WikkaSpamFighting for spam-related issues
~-WikkaWorkarounds for specific platforms
~-WikkaOptimization
>>{{feedback}}::c::
===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.
----
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 403 Forbidden');%%
-- DarTar
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
----
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
----
===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
%% 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
----
===Section Editing Redux===
Instead of a full blown section editing implementation why not just implement a tag like '<WikiPage>' which inserts the contents of WikiPage (no comments) at the markers location. <WikiPage x> would insert the first x lines of the WikiPage into the current page. And/or <WikiPage Header> would pull just the section of the page which is demarked by Header and EOP or next header. Such sections can be inserted in a special color/block/font/whatever and automatically link back to the original page for editing. The goal is to provide better editing granularity and readability on pages which have lots of information density. Could also be used to mimic blog functionality. -KarmaTester
----
===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
~~& 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
----
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
~&See RobotFriendly. --DotMG
----
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) open a ##/raw## version of the page;
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
~1) open a text editor;
~1) copy the code block;
~1) paste it in the text editor;
~1) save the file.
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See GrabCodeHandler for a first proposal -- DarTar
----
===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
----
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
----
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
%%
include ('Wakka.class.php');
%%
-- DiN
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
----
===phpMyEdit in Wikka===
I've set up a demo of [[http://www.jsnx.com/wikka-dev/SuggestionBox phpMyEdit running within Wikka]]. This would be useful for anyone wanting to directly interact with MySQL tables from a Wikka page. -- JsnX
~&I assume this is meant for admins only but ... Could you add some explanation? I looked but don't have a clue how to use it. What are the radio buttons for, for instance? What's the "V" button at the top? The UI is very confusing. --JavaWoman
~~& Jsnx, that's interesting. I think the idea is worth consideration. I have used phpMyEdit as an interface to allow my users to store their profiles in the DB when I still was a MySQL newbie :) and it's true that it allows a number of tricky things (especially cross-reference between tables). So I think a plugin for integrating phpMyEdit within Wikka pages might be a nice extension. You probably know though that all the interface options can only be set by editing the source, or were you thinking of allowing some kind of admin access to the interface options? And be honest, are you thinking of phpMyEdit as a sort of replacement for my baby admin actions, aren't you?! In a sense this might be interesting, but it would really be unnecessary compared to what we can do by creating direct calls to the DB using core functions. Why heavily tweak an external script to do something wikka-like if we can already use something that only needs core functions? --- Moreover, when you perform operations on pages (like 'add', 'copy' or 'delete') you generally want to do something more complicated than just modify single records of the page table. Using phpMyEdit as a sort of proxy for a page admin action can lead to major inconsistencies in the page structure. --- And, JW, the "v" button is for filtering the table ;-) -- DarTar
~~~&DarTar, that's silly. The admin actions that you have developed are looking fantastic! I was never thinking of using phpMyEdit to replace your actions. I'm using phpMyEdit to interface with non-Wikka tables; I like to see the data shown from Wikka, and I also like being able to use Wikka formatting within the data. It might help if I gave an example of how I use phpMyEdit. [... I'll write an example later on ...] -- JsnX
~~~&Filtering? Well first it's not obvious, nor explained; but I just went back and tried pressing the "v" button - and I get three other mystifying buttons in return. Frankly, I don't want to use something as badly-designed as this. Shudder. DarTar, your Admin functions may need some refinement, but mystifying they are not. Let's stick with those, and build on them. Sorry, JsnX, but this doesn't get my vote. --JavaWoman
~~~~&Thanks for the comments. I expected there would be some reservations about including this in Wikka. I too have some reservations about phpMyEdit. However, with that said, I also find it to be a **very useful** tool which I will continue to use. It doesn't matter to me whether phpMyEdit is ever an official Wikka component because using it requires zero modifications to the Wikka code -- there will be no ongoing maintenance when upgrading to new Wikka versions. It's not my intention to support this, but if someone wants to use it, I'm happy to make my modified phpMyEdit version available. I'm proposing this as an official "unofficial Wikka add-on". :) -- JsnX
~&I am interested by the idea to interact with MySQL tables from a Wikka page. Would you please share the updated phpMyEdit code? --ChristianBarthelemy
~~&Yes, I plan to play around with it for a few more days, then I'll upload the code and some instructions. -- JsnX
~~~&Hi Jason, I am still interested to know more about this... --ChristianBarthelemy
~&Well, Jason, I do think it would help I you would explain what you are using this **for** (especially if not for Wikka administration); I'd also like to know then why you chose phpMyEdit and not another browser-based client - and why a browser-based client in the first place. I've only ever tried phpMyAdmin and found it lacking because it tends (tended) to work on single tables only. I quickly switched to "real" clients that are more powerful and allow me to build queries involving several tables if needed, so consistency can be maintained. I have a bunch of handy tools (for Windows), all free: for design, administration and maintenance. And though I do have phpMyAdmin available, I don't intend to use it. --JavaWoman
~~&My bet is that Jason's using it to fix the pages where I've (inadertently) submitted double percent signs as part of submitted code so that the history feature works properly. {grin} --GmBowen
~~~&LOL! But - "inadvertently"? Using double percent signs should be possible in code - and if not, that's a bug in Wikka, not your fault! (Not that I have a solution for that yet, though I have been thinking about that problem.) --JavaWoman
----
===Support for (Technorati) tags===
I think it might be interesting to provide Wikka support for (Technorati) "**tags**". "Tags" in this context are simple keywords that help identify and categorize web content, in particular blog posts. Such keywords coupled with a ping system can be used by remote servers to retrieve fresh content for specific topics. See for instance how technorati.com aggregates fresh information about [[http://www.technorati.com/tag/wiki wikis]] from a number of sources.
[[http://www.technorati.com/help/tags.html More information on Technorati tags]]
~&Seems like we need to update our RSS (feed) implementation first... --JavaWoman
----
===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
----
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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?
--GregorLindner
----
==Signature==
(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
----
== 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
----
== Create rewrite rules on install ==
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
== Image dimensions ==
The [[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
----
==Clearing ACLs==
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
----
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
== RSS options ==
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
----
== 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
----
== Language file ==
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
== 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
----
==Finally using CVS?==
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
==Stopping Spammers getting Google Juice==
//(moved to WikkaSpamFighting)//
----
==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
----
==Give control over HTML (using a templating system)==
It would be nice to see a template engine in Wikka to give the users the full control over the HTML source. Smarty is always a good choice.
~& I would love to see Wikka adopt some type of template system. I think that its is sorely needed. Changing the look of Wikka requires tedious editing of php files, and alot of the time it is non-obvious where you need to go to edit such files. Another alternative to [[http://smarty.php.net Smarty]] could be [[http://wiki.ciaweb.net/yawiki/index.php?area=Savant Savant]]. --KickTheDonkey
~~&While I use and like Smarty very much (and it's quite fast), it's rather "heavy" for Wikka, I think. I just had a look at Savant2 which I hadn't heard of before. It looks like a good fit, is lightweight and easy to use. A templating system like this would also provide much more flexibility for Wikka admins to have control over page structure and layout. I'll want to play with it some (in combination with Wikka), but my first impression based on documentation and code is very favorable. More when I've had a chance to exercise it. --JavaWoman
~~~&I'm sorry JW, but what do you mean by Smarty being rather "heavy" for Wikka? Resource-wise? Hard to use / implement? Difficult for the end user? -- FernandoBorcel
~~~~&Fernando, I mean it's "heavy" in two respects, actualy: 1) in terms of code size (currently Smarty is 137K compared to Wikka's 524K - zipped - while for instance Savant is only 39K); 2) in terms of usability - while it's quite powerful, there is a rather steep learning curve for those who've never worked with templates; Savant is simpler and much easier to learn, and looks still quite flexible. I'm not sure about resource usage, but I suspect that in that respect it might be heavier than Savant as well. We'd like to keep Wikka easy to use both for WikiAdmins and for WikiUsers. I still have to actually try Savant with Wikka, but from what I've see so far it fits our profile better, I think. Anyway, before we go forward with something like this, more research will be needed. --JavaWoman
----
==Allow spaces in pagetitle==
Allow Spaces in the document title and replace it later with "-" to optimize it for search engines.
----
==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
----
==Local links==
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--KickTheDonkey
----
==Idea for Category Support==
moved to CategorySystemOverhaul, it is the better place, thanks DarTar
--ArpY
~& ArpY, take a look at CategorySystemOverhaul for an open discussion on how to improve the category system -- DarTar
----
==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.
----
==Section Editing ==
- http://c2.com/cgi/wiki?SectionEditing
- It makes allows you to flow and edit much quicker.
- Each topic should have a corresponding edit button. This allows your to edit each section with out breaking your flow.
- http://www.splitbrain.org/dokuwiki/wiki:section_editing
----
==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
----
==Standard date and time format==
Although I'm all for using the ISO date/time format as we see in the timestamp of the footer of every page, I note that several other parts of Wikka use different date/time formats. I'd like to see an approach where this is standardized.
Proposal:
~-Define date-time format (or separately date and time, as well as a way to combine them) in the configuration; use the ISO format as a default (in the initial configuration, as well as when no format is defined in the config).
~-Use this format wherever date and/or time are formatted.
~-Make using the configured formats a requirement for every Wikka extension (that displays date/time information) to be included with the distribution.
I realize that in principle it's possible to pick up formats from a locale but for a Wikka targeted at an international audience this may not be the best approach, and for a Wikka with a "local" audience it may not be either if it's hosted on a (public) server outside that country - hence the idea to define a format in the configuration.
--JavaWoman
~''Agreed -- DarTar''
----
==Handling the config==
I have three questions about the config. See HandlingWikkaConfig.
--NilsLindenberg
''See also WikkaSecureConfig for a possible new appraoch. --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
----
==Online editing of mindmaps would be great==
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
----
==Tables ==
For the discussion on tables in Wikka, take a look at WikkaTables.
~&See also TableAction for a preliminary solution. --JavaWoman
----
==Wikka Exporting/Importing ==
Just added a few thoughts [[WikkaFilters here]]
-- DarTar
----
==how to format code to get two % characters without space together?==
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
----
==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
----
==showing comments==
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
----
==Language support==
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
----
== 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
----
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
----
== 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
----
==Using FPDF with Wikka==
Not so much a suggestion, more a request although it may be useful to others.
I have been using FPDF from [[http://www.fpdf.org FPDF ]] to export content from a database to pdf files.
I would like to extend my usage of FPDF to wikka by adding a hyperlink to the top of my wikka pages which would allow me to post the page tag or page id to the FPDF script for exporting the content into a pdf file.
The link would be in the form similar to
http://www.mysite.com/script.php?id=
Can anyone tell me how I can extract the page tag or page id from the wikka_pages table in order to do this.
----
====Resolved Suggestions====
== Question: PHP 4.3 and "mysql_escape_string()"? ==
For the Wikka Wakka Wiki 1.1.4.0 you need at least PHP 4.3 because the "mysql_real_escape_string()" in wakka.php is only available in PHP 4.3. A lot of hoster just offering PHP 4.1 or 4.2. Then you have to replace "mysql_real_escape_string()" with "mysql_escape_string()". What was the reason for the replacement in the new release? Again: Keep on the good work.
-- SkyWalk
~&The reason is that ##mysql_real_escape_string()## is more secure than ##mysql_escape_string()## so we want to take advantage of that; but as implemented this left users of older versions of PHP in the cold. A workaround for this will be in version 1.1.6.0 (see above) - now avaliable as a [[HomePage public beta]]. --JavaWoman
----
== Typo correction in embedded Wiki Edit 2 ==
For the new (1.1.6.0) release, line 645 of wikiedit2/wikiedit2.js should be fixed to say:
%% s += " Ctrl+Shift+Minus - Horizontal line\n";%%
not "horisontal." I've already fixed it in my local copy, but no sense in perpetuating errors. :) --MovieLady
~&Thanks to eagle-eyed JsnX it's //aready// fixed in 1.1.6.0 beta4 :) but thanks for the note! --JavaWoman
~~& Marvelous, thanks! :) --MovieLady
==Compatibility with PHP 4.1.x==
with Debian GNU/Linux 3.0 (woody) are installed PHP 4.1.2 and this version don't support "mysql_real_escape_string" function.
temporary fix on wikka.php head:
%%(php)
if ( ! function_exists("mysql_real_escape_string") )
{
function mysql_real_escape_string($string)
{
return mysql_escape_string($string);
}
}%%
~&This will be in version 1.1.6.0 - now avaliable as a [[HomePage public beta]]. --JavaWoman
==Don't let old pages get indexed==
//(moved to WikkaSpamFighting)//
==User page==
If someone registers as a new user and chooses a Wikiname, his wikinamepage is empty. I think it would be nice, if the page whould be created from the wiki, containing a text with perhaps a welcome, some (Wiki)rules and usefull pages (this text should be stored somewhere so that it could be customized from the WikiAdmin). The page should automatically belong to the category user. Regards, NilsLindenberg
==Non-breaking space in forced links==
Sometimes a forced link has a phrase as link description with spaces for readability but where these spaces should **not** cause wrapping in the middle of the string - in other words, the spaces really should be non-breaking spaces. Unfortunately, specifying ## ## will (unlike here) result in the entity becoming visible as an entity instead of as the character it encodes.
It should be possible to either specify ## ## where needed and have it result in the actual character (i.e., keep the actual entity rather than "escaping" it), or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
//**Note:** Actually, with the 1.1.6.0 beta version running on this site, this demonstrates how the new htmlspecialchars_unicode() function is indeed buggy - as I pointed out on WikkaDevelopment. The solution is presented [[WikkaDevelopment there]] now (look for **htmlspecialchars_unicode()**).//
--JavaWoman
==User Control==
Is there an easy way to not allow registration? I would like to have it so that I can control the registration process, not let just anyone sign-up.
--BooYa
... (Nils proposing a solution)
A nice contribution Nils. If you want to go further with fiddling with the code for registration, I've thought it would be useful if there was a feature that required a password from an administrator to be able to register so that if you were going to register you put in your user info (as now) and a password you've obtained from the admin that allows you to register....for instance, in this way a teacher could set up a wikki with registration "on" and send a note to all of the parents with the registration password so that they could register....outsiders couldn't register, only those with the registration key. Possibly a quite useful feature to many potential user groups. -- GmBowen
~Look at UserRegistration for the first version, or [[http://www.niehle.info/UserSettings try it]] --NilsLindenberg
----
==Cookies and logging out==
This issue issue moved to StayingLoggedIn!
==Page viewed counter==
It occurs to me that some kind of "counter" for how many times the wikipage has been viewed might be a useful "action" for somebody to be able to use...this way a page author would know how often somebody has gone to the page & this might help focus development (especially for those keeners that have multiple pages/projects). [and I agree with the contributor below....Wikkawiki is great software]
''I completed altering a script and modifying the wikka code for this.....go to GmBowenCounter for the php script and the necessary alterations'' --GmBowen
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
==Mod rewrite and a problem==
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough?
''Good catch. Adding the end slash should be fine. It will be added by default in the next Wikka release. -- Jsnx''
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. -- JockeAndersson
''Jocke, in the style sheet [wikka.css by default], add "text-decoration: none;" to the smallprint style. Or am I not understanding the problem? -- JsnX''
~~~.smallprint a {
~~~color: #987;
~~~text-decoration: none;
~~~}
It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
The reason the above addition to smallprint doesn't work is that the links are visited meaning the pseudo-class a:visited must be defined as well with "text-decoration: none" in it. There is no definition for a:visited in the css by default. Perhaps this should be added to Wikka's code? -- JockeAndersson
Sure, I'll add it. Just curious though, what web browser are you using? Internet Explorer does not show underlined links as you have described...at least not for me. -- JsnX
I'm currently using Mozilla Firefox, but I'm testing pages in IE as well. The underlines were only visible in Firefox. IE is usually the one to screw up page rendering, not being fully standards-compliant and all. Oh, and the code could use an a:active definition as well. Be sure to define them in correct order though: a visited hover active. W3C were specific about that for some reason. -- JockeAndersson
Thanks for the tip. By the way, your site looks awesome. -- JsnX
You really think so? Thanks!! :) Much of the general layout comes from A List Apart's site, but adapted to my needs. I've had a site running for a while but can't find the time to update it properly. I believe Wikka will change all that and am seriously thinking of replacing my ordinary site with a Wikka wiki. The forum will still be phpbb, but the site itself could really benefit from the pros of Wikka. I second [[MarkHissinkMuller MarkHissinkMullers]] suggestions for improvement. Especially the possibility to manage ACLs based on user groups as well as individual users, would be great. -- JockeAndersson
~& I tried to do something like this at ACLsWithUserGroups.
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action (LOL) if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}""). -- Mike Bowen
----
CategoryWikka
Additions:
~& Oh, and maybe 404 headers for missing pages (which would help prevent SE from spidering links to non existing pages)? -- DarTar
Additions:
~~~~&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.
Additions:
~~~&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
Additions:
~~&it closes the <div class="page">. --NilsLindenberg
Revision [6718]
Edited on 2005-03-15 11:07:25 by proxy2.alstom.ch [oopse just noticed WikkaSpamFighting page]Deletions:
Does wikkawiki have any anti-spam features? In particular does it have a 'content blacklist' feature, which loads a file full of regular expressions, and blocks (with a message) any edits which cause the page to match any of the expressions. Other wiki engines do this, and it has proven to be more effective than IP blocking at stopping spam. Wiki administators have begun setting up networks to share and merge their blacklists, but I don't see any information about [[AntiSpamFeatures]] here (I suggest you create a page by that name). See also
http://wiki.chongqed.org//AntiSpamRecommendations -- Halz - 15th March 2005
Additions:
===Antispam features===
Does wikkawiki have any anti-spam features? In particular does it have a 'content blacklist' feature, which loads a file full of regular expressions, and blocks (with a message) any edits which cause the page to match any of the expressions. Other wiki engines do this, and it has proven to be more effective than IP blocking at stopping spam. Wiki administators have begun setting up networks to share and merge their blacklists, but I don't see any information about [[AntiSpamFeatures]] here (I suggest you create a page by that name). See also
http://wiki.chongqed.org//AntiSpamRecommendations -- Halz - 15th March 2005
Does wikkawiki have any anti-spam features? In particular does it have a 'content blacklist' feature, which loads a file full of regular expressions, and blocks (with a message) any edits which cause the page to match any of the expressions. Other wiki engines do this, and it has proven to be more effective than IP blocking at stopping spam. Wiki administators have begun setting up networks to share and merge their blacklists, but I don't see any information about [[AntiSpamFeatures]] here (I suggest you create a page by that name). See also
http://wiki.chongqed.org//AntiSpamRecommendations -- Halz - 15th March 2005
Additions:
~&What's the </div> for? I see no opening <div>. --JavaWoman
Additions:
===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>";
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>";
Revision [6480]
Edited on 2005-03-04 12:38:31 by JavaWoman [reply re: Search engine results inflation]Additions:
~&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
Additions:
===Sending 403 headers===
%%(php) header('HTTP/1.0 403 Forbidden');%%
%%(php) header('HTTP/1.0 403 Forbidden');%%
Deletions:
%%(php) header('HTTP/1.0 401 Unauthorized');%%
Additions:
For pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
Deletions:
No Differences
Additions:
===Sending 401 headers===
(related to the //Search engine results inflation// item below)
On pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 401 Unauthorized');%%
(related to the //Search engine results inflation// item below)
On pages to which the user has no read-access, do you think it might be feasible/interesting to send - along with the //You aren't allowed to read this page// message - a HTTP header like the following:
%%(php) header('HTTP/1.0 401 Unauthorized');%%
Revision [6353]
Edited on 2005-02-27 14:10:25 by JavaWoman [reply to FernandoBorcel re templating solutions]Additions:
==Give control over HTML (using a templating system)==
~~~~&Fernando, I mean it's "heavy" in two respects, actualy: 1) in terms of code size (currently Smarty is 137K compared to Wikka's 524K - zipped - while for instance Savant is only 39K); 2) in terms of usability - while it's quite powerful, there is a rather steep learning curve for those who've never worked with templates; Savant is simpler and much easier to learn, and looks still quite flexible. I'm not sure about resource usage, but I suspect that in that respect it might be heavier than Savant as well. We'd like to keep Wikka easy to use both for WikiAdmins and for WikiUsers. I still have to actually try Savant with Wikka, but from what I've see so far it fits our profile better, I think. Anyway, before we go forward with something like this, more research will be needed. --JavaWoman
~~~~&Fernando, I mean it's "heavy" in two respects, actualy: 1) in terms of code size (currently Smarty is 137K compared to Wikka's 524K - zipped - while for instance Savant is only 39K); 2) in terms of usability - while it's quite powerful, there is a rather steep learning curve for those who've never worked with templates; Savant is simpler and much easier to learn, and looks still quite flexible. I'm not sure about resource usage, but I suspect that in that respect it might be heavier than Savant as well. We'd like to keep Wikka easy to use both for WikiAdmins and for WikiUsers. I still have to actually try Savant with Wikka, but from what I've see so far it fits our profile better, I think. Anyway, before we go forward with something like this, more research will be needed. --JavaWoman
Deletions:
Additions:
~& Agreed, we should drop this restriction. Numbers in page names might also be useful to use Wikka as a [[Wikipedia:bliki bliki engine]], i.e. a hybrid blog/wiki software which is drawing increasing attention in the [[SocialSoftware social software]] community. Robert, take a look at this user-contributed plugin, which allows creating a calendar with single pages for days: JwCalendarWithPageCreation -- DarTar
Additions:
===Numbers as page names?===
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
I'm curious about the Wikka convention that numbers cannot be page names. I'd like to be able to create "date page" (e.g. 2005-02-26) for notes and journaling, so this is a feature I'd definitely suggest.
BTW, doing something along the lines of "journal/2005-02-26" or "journal_2005..." wants to create an external link.
Thx, RobertDaeley
Additions:
~~~&I'm sorry JW, but what do you mean by Smarty being rather "heavy" for Wikka? Resource-wise? Hard to use / implement? Difficult for the end user? -- FernandoBorcel
Additions:
===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
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
Additions:
~~&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
Additions:
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
Deletions:
Additions:
===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: [[site:wikka.jsnx.com revisions.xml 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 cached. Maybe we should think of some way to help the user decide what kind of content of her Wikka-powered site should be spidered by SE and what content should not. -- DarTar
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: [[site:wikka.jsnx.com revisions.xml 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 cached. Maybe we should think of some way to help the user decide what kind of content of her Wikka-powered site should be spidered by SE and what content should not. -- DarTar
Additions:
~& Hope you have a large screen: SoWhatAreTheNews --ChristianBarthelemy
Additions:
===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
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
Revision [6280]
Edited on 2005-02-23 22:11:15 by ChiWaWa [Generate page from an external database -> DynamicPageGeneration]Additions:
===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.
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.
Revision [6227]
Edited on 2005-02-21 17:38:58 by ChristianBarthelemy [Jason's idea to use phpMyEdit - any news?]Additions:
~~~&Hi Jason, I am still interested to know more about this... --ChristianBarthelemy
Additions:
die ("accès direct interdit");
+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):
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
else if ($thing == ""¥¥")
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Sometimes a forced link has a phrase as link description with spaces for readability but where these spaces should **not** cause wrapping in the middle of the string - in other words, the spaces really should be non-breaking spaces. Unfortunately, specifying ## ## will (unlike here) result in the entity becoming visible as an entity instead of as the character it encodes.
It should be possible to either specify ## ## where needed and have it result in the actual character (i.e., keep the actual entity rather than "escaping" it), or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
+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):
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
else if ($thing == ""¥¥")
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Sometimes a forced link has a phrase as link description with spaces for readability but where these spaces should **not** cause wrapping in the middle of the string - in other words, the spaces really should be non-breaking spaces. Unfortunately, specifying ## ## will (unlike here) result in the entity becoming visible as an entity instead of as the character it encodes.
It should be possible to either specify ## ## where needed and have it result in the actual character (i.e., keep the actual entity rather than "escaping" it), or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
Deletions:
+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):
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
else if ($thing == ""¥¥")
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Sometimes a forced link has a phrase as link description with spaces for readability but where these spaces should **not** cause wrapping in the middle of the string - in other words, the spaces really should be non-breaking spaces. Unfortunately, specifying ## ## will (unlike here) result in the entity becoming visible as an entity instead of as the character it encodes.
It should be possible to either specify ## ## where needed and have it result in the actual character (i.e., keep the actual entity rather than "escaping" it), or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
<a href="http://handbag.tamsquare.com/handbag.html">handbag</a>
<a href="http://handbag.tamsquare.com/coach-handbag.html">coach handbag</a>
<a href="http://handbag.tamsquare.com/designer-handbag.html">designer handbag</a>
<a href="http://handbag.tamsquare.com/gucci-handbag.html">gucci handbag</a>
<a href="http://handbag.tamsquare.com/louis-vuitton-handbag.html">louis vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/wholesale-handbag.html">wholesale handbag</a>
<a href="http://handbag.tamsquare.com/replica-handbag.html">replica handbag</a>
<a href="http://handbag.tamsquare.com/prada-handbag.html">prada handbag</a>
<a href="http://handbag.tamsquare.com/burberry-handbag.html">burberry handbag</a>
<a href="http://handbag.tamsquare.com/chanel-handbag.html">chanel handbag</a>
<a href="http://handbag.tamsquare.com/dooney-bourke-handbag.html">dooney bourke
handbag</a>
<a href="http://handbag.tamsquare.com/fendi-handbag.html">fendi handbag</a>
<a href="http://handbag.tamsquare.com/replica-designer-handbag.html">replica designer
handbag</a>
<a href="http://handbag.tamsquare.com/ugg-handbag.html">ugg handbag</a>
<a href="http://handbag.tamsquare.com/leather-handbag.html">leather handbag</a>
<a href="http://handbag.tamsquare.com/handbag-purse.html">handbag purse</a>
<a href="http://handbag.tamsquare.com/christian-dior-handbag.html">christian dior
handbag</a>
<a href="http://handbag.tamsquare.com/louis-vuitton-replica-handbag.html">louis vuitton replica
handbag</a>
<a href="http://handbag.tamsquare.com/handbag-accessory.html">handbag accessory</a>
<a href="http://handbag.tamsquare.com/brighton-handbag.html">brighton handbag</a>
<a href="http://handbag.tamsquare.com/knockoff-handbag.html">knockoff handbag</a>
<a href="http://handbag.tamsquare.com/juicy-couture-handbag.html">juicy couture
handbag</a>
<a href="http://handbag.tamsquare.com/ugg-australia-handbag.html">ugg australia
handbag</a>
<a href="http://handbag.tamsquare.com/kate-spade-handbag.html">kate spade handbag</a>
<a href="http://handbag.tamsquare.com/womens-handbag.html">womens handbag</a>
<a href="http://handbag.tamsquare.com/guess-handbag.html">guess handbag</a>
<a href="http://handbag.tamsquare.com/discount-designer-handbag.html">discount designer
handbag</a>
<a href="http://handbag.tamsquare.com/discount-handbag.html">discount handbag</a>
<a href="http://handbag.tamsquare.com/dior-handbag.html">dior handbag</a>
<a href="http://handbag.tamsquare.com/dooney-and-burke-handbag.html">dooney and burke
handbag</a>
<a href="http://handbag.tamsquare.com/marc-jacobs-handbag.html">marc jacobs handbag</a>
<a href="http://handbag.tamsquare.com/handbag-bag.html">handbag bag</a>
<a href="http://handbag.tamsquare.com/lv-handbag.html">lv handbag</a>
<a href="http://handbag.tamsquare.com/hermes-handbag.html">hermes handbag</a>
<a href="http://handbag.tamsquare.com/bradley-handbag-vera.html">bradley handbag vera</a>
<a href="http://handbag.tamsquare.com/fashion-handbag.html">fashion handbag</a>
<a href="http://handbag.tamsquare.com/louis-vitton-handbag.html">louis vitton handbag</a>
<a href="http://handbag.tamsquare.com/wholesale-replica-handbag.html">wholesale replica
handbag</a>
<a href="http://handbag.tamsquare.com/fossil-handbag.html">fossil handbag</a>
<a href="http://handbag.tamsquare.com/fake-designer-handbag.html">fake designer
handbag</a>
<a href="http://handbag.tamsquare.com/designer-inspired-handbag.html">designer inspired
handbag</a>
<a href="http://handbag.tamsquare.com/wholesale-designer-handbag.html">wholesale designer
handbag</a>
<a href="http://handbag.tamsquare.com/authentic-gucci-handbag.html">authentic gucci
handbag</a>
<a href="http://handbag.tamsquare.com/authentic-louis-vuitton-handbag.html">authentic louis vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/initial-handbag.html">initial handbag</a>
<a href="http://handbag.tamsquare.com/designer-knockoff-handbag.html">designer knockoff
handbag</a>
<a href="http://handbag.tamsquare.com/michael-kors-handbag.html">michael kors handbag</a>
<a href="http://handbag.tamsquare.com/stone-mountain-handbag.html">stone mountain
handbag</a>
<a href="http://handbag.tamsquare.com/accessory-handbag-shoes-womens.html">accessory handbag shoes
womens</a>
<a href="http://handbag.tamsquare.com/replica-coach-handbag.html">replica coach
handbag</a>
<a href="http://handbag.tamsquare.com/handmade-handbag.html">handmade handbag</a>
<a href="http://handbag.tamsquare.com/nine-west-handbag.html">nine west handbag</a>
<a href="http://handbag.tamsquare.com/tods-handbag.html">tods handbag</a>
<a href="http://handbag.tamsquare.com/chanel-replica-handbag.html">chanel replica
handbag</a>
<a href="http://handbag.tamsquare.com/vintage-handbag.html">vintage handbag</a>
<a href="http://handbag.tamsquare.com/discount-coach-handbag.html">discount coach
handbag</a>
<a href="http://handbag.tamsquare.com/knock-off-handbag.html">knock off handbag</a>
<a href="http://handbag.tamsquare.com/handbag-shoes.html">handbag shoes</a>
<a href="http://handbag.tamsquare.com/xoxo-handbag.html">xoxo handbag</a>
<a href="http://handbag.tamsquare.com/photo-handbag.html">photo handbag</a>
<a href="http://handbag.tamsquare.com/balenciaga-handbag.html">balenciaga handbag</a>
<a href="http://handbag.tamsquare.com/dkny-handbag.html">dkny handbag</a>
<a href="http://handbag.tamsquare.com/brahmin-handbag.html">brahmin handbag</a>
<a href="http://handbag.tamsquare.com/name-brand-handbag.html">name brand handbag</a>
<a href="http://handbag.tamsquare.com/mary-frances-handbag.html">mary frances handbag</a>
<a href="http://handbag.tamsquare.com/gucci-replica-handbag.html">gucci replica
handbag</a>
<a href="http://handbag.tamsquare.com/cheap-handbag.html">cheap handbag</a>
<a href="http://handbag.tamsquare.com/the-sak-handbag.html">the sak handbag</a>
<a href="http://handbag.tamsquare.com/hobo-handbag.html">hobo handbag</a>
<a href="http://handbag.tamsquare.com/imitation-handbag.html">imitation handbag</a>
<a href="http://handbag.tamsquare.com/hype-handbag.html">hype handbag</a>
<a href="http://handbag.tamsquare.com/fake-handbag.html">fake handbag</a>
<a href="http://handbag.tamsquare.com/channel-handbag.html">channel handbag</a>
<a href="http://handbag.tamsquare.com/puma-handbag.html">puma handbag</a>
<a href="http://handbag.tamsquare.com/wholesale-purse-handbag.html">wholesale purse
handbag</a>
<a href="http://handbag.tamsquare.com/louis-vutton-handbag.html">louis vutton handbag</a>
<a href="http://handbag.tamsquare.com/louie-vuitton-handbag.html">louie vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/cheap-designer-handbag.html">cheap designer
handbag</a>
<a href="http://handbag.tamsquare.com/jewelry-handbag.html">jewelry handbag</a>
<a href="http://handbag.tamsquare.com/tommy-hilfiger-handbag.html">tommy hilfiger
handbag</a>
<a href="http://handbag.tamsquare.com/lady-handbag.html">lady handbag</a>
<a href="http://handbag.tamsquare.com/my-flat-in-london-handbag.html">my flat in london
handbag</a>
<a href="http://handbag.tamsquare.com/discount-louis-vuitton-handbag.html">discount louis vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/boot-handbag-ugg.html">boot handbag ugg</a>
<a href="http://handbag.tamsquare.com/liz-claiborne-handbag.html">liz claiborne
handbag</a>
<a href="http://handbag.tamsquare.com/kenneth-cole-new-york-handbag.html">kenneth cole new york
handbag</a>
<a href="http://handbag.tamsquare.com/wholesale-louis-vuitton-handbag.html">wholesale louis vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/unique-handbag.html">unique handbag</a>
<a href="http://handbag.tamsquare.com/luxury-handbag.html">luxury handbag</a>
<a href="http://handbag.tamsquare.com/discount-gucci-handbag.html">discount gucci
handbag</a>
<a href="http://handbag.tamsquare.com/handbag-totes.html">handbag totes</a>
<a href="http://handbag.tamsquare.com/authentic-chanel-handbag.html">authentic chanel
handbag</a>
<a href="http://handbag.tamsquare.com/imitation-designer-handbag.html">imitation designer
handbag</a>
<a href="http://handbag.tamsquare.com/handbag-replica-ugg.html">handbag replica ugg</a>
<a href="http://handbag.tamsquare.com/handbag-pattern.html">handbag pattern</a>
<a href="http://handbag.tamsquare.com/inge-handbag.html">inge handbag</a>
<a href="http://handbag.tamsquare.com/fake-louis-vuitton-handbag.html">fake louis vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/nicky-hilton-handbag.html">nicky hilton handbag</a>
<a href="http://handbag.tamsquare.com/franco-sarto-handbag.html">franco sarto handbag</a>
<a href="http://handbag.tamsquare.com/kenneth-cole-handbag.html">kenneth cole handbag</a>
<a href="http://www.famousleather.com/wilsons-leather.html">wilsons leather</a>
<a href="http://www.famousleather.com/leather-jacket.html">leather jacket</a>
<a href="http://www.famousleather.com/leather.html">leather</a>
<a href="http://www.famousleather.com/leather-coats.html">leather coats</a>
<a href="http://www.famousleather.com/leather-sofa.html">leather sofa</a>
<a href="http://www.famousleather.com/leather-pants.html">leather pants</a>
<a href="http://www.famousleather.com/leather-furniture.html">leather furniture</a>
<a href="http://www.famousleather.com/leather-briefcase.html">leather briefcase</a>
<a href="http://www.famousleather.com/man-leather-jacket.html">man leather jacket</a>
<a href="http://www.famousleather.com/italian-leather.html">italian leather</a>
<a href="http://www.famousleather.com/leather-gloves.html">leather gloves</a>
<a href="http://www.famousleather.com/leather-handbag.html">leather handbag</a>
<a href="http://www.famousleather.com/leather-chair.html">leather chair</a>
<a href="http://www.famousleather.com/leather-lingerie.html">leather lingerie</a>
<a href="http://www.famousleather.com/womens-leather-jacket.html">womens leather
jacket</a>
<a href="http://www.famousleather.com/leather-wallet.html">leather wallet</a>
<a href="http://www.famousleather.com/leather-skirt.html">leather skirt</a>
<a href="http://www.famousleather.com/leather-motorcycle-jacket.html">leather motorcycle
jacket</a>
<a href="http://www.famousleather.com/shopping-fur-leather.html">shopping fur leather</a>
<a href="http://www.famousleather.com/leather-boot.html">leather boot</a>
<a href="http://www.famousleather.com/motorcycle-leather.html">motorcycle leather</a>
<a href="http://www.famousleather.com/man-leather-coats.html">man leather coats</a>
<a href="http://www.famousleather.com/leather-recliner.html">leather recliner</a>
<a href="http://www.famousleather.com/leather-belt.html">leather belt</a>
<a href="http://www.famousleather.com/womens-leather-coats.html">womens leather coats</a>
<a href="http://www.famousleather.com/leather-journal.html">leather journal</a>
<a href="http://www.famousleather.com/tandy-leather.html">tandy leather</a>
<a href="http://www.famousleather.com/leather-goods.html">leather goods</a>
<a href="http://www.famousleather.com/leather-backpack.html">leather backpack</a>
<a href="http://www.famousleather.com/leather-portfolio.html">leather portfolio</a>
<a href="http://www.famousleather.com/leather-bag.html">leather bag</a>
<a href="http://www.famousleather.com/leather-purse.html">leather purse</a>
<a href="http://www.famousleather.com/leather-couch.html">leather couch</a>
<a href="http://www.famousleather.com/coach-leather.html">coach leather</a>
<a href="http://www.famousleather.com/leather-repair.html">leather repair</a>
<a href="http://www.famousleather.com/leather-clothing.html">leather clothing</a>
<a href="http://www.famousleather.com/danier-leather.html">danier leather</a>
<a href="http://www.famousleather.com/leather-bomber-jacket.html">leather bomber
jacket</a>
<a href="http://www.famousleather.com/leather-chap.html">leather chap</a>
<a href="http://www.famousleather.com/wholesale-leather.html">wholesale leather</a>
<a href="http://www.famousleather.com/leather-vest.html">leather vest</a>
<a href="http://www.famousleather.com/leather-luggage.html">leather luggage</a>
<a href="http://www.famousleather.com/cleaning-leather.html">cleaning leather</a>
<a href="http://www.famousleather.com/leather-apparel.html">leather apparel</a>
<a href="http://www.famousleather.com/leather-and-lace.html">leather and lace</a>
<a href="http://www.famousleather.com/liquid-leather.html">liquid leather</a>
<a href="http://www.famousleather.com/man-leather-wallet.html">man leather wallet</a>
<a href="http://www.famousleather.com/leather-store.html">leather store</a>
<a href="http://www.famousleather.com/leather-blazer.html">leather blazer</a>
<a href="http://www.famousleather.com/leather-man.html">leather man</a>
<a href="http://www.famousleather.com/leather-photo-album.html">leather photo album</a>
<a href="http://www.famousleather.com/leather-bracelet.html">leather bracelet</a>
<a href="http://www.famousleather.com/jennifer-leather.html">jennifer leather</a>
<a href="http://www.famousleather.com/leather-craft.html">leather craft</a>
<a href="http://www.famousleather.com/leather-hat.html">leather hat</a>
<a href="http://www.famousleather.com/leather-messenger-bag.html">leather messenger
bag</a>
<a href="http://www.famousleather.com/leather-sectionals.html">leather sectionals</a>
<a href="http://www.famousleather.com/leather-trench-coats.html">leather trench coats</a>
<a href="http://www.famousleather.com/leather-clothes.html">leather clothes</a>
<a href="http://www.famousleather.com/puma-mostro-leather.html">puma mostro leather</a>
<a href="http://www.famousleather.com/leather-ottoman.html">leather ottoman</a>
<a href="http://www.famousleather.com/leather-money-clip.html">leather money clip</a>
<a href="http://www.famousleather.com/harley-davidson-leather-boot.html">harley davidson leather
boot</a>
<a href="http://www.famousleather.com/puma-h-street-leather.html">puma h street
leather</a>
<a href="http://www.famousleather.com/keds-leather.html">keds leather</a>
<a href="http://www.famousleather.com/leather-corset.html">leather corset</a>
<a href="http://www.famousleather.com/biker-leather.html">biker leather</a>
<a href="http://www.famousleather.com/leather-factory.html">leather factory</a>
<a href="http://www.famousleather.com/gay-leather.html">gay leather</a>
<a href="http://www.famousleather.com/leather-dress.html">leather dress</a>
<a href="http://www.famousleather.com/buy-converse-bomber-leather-shoes.html">buy converse bomber leather
shoes</a>
<a href="http://www.famousleather.com/non-leather-new-balance-shoes.html">non leather new balance
shoes</a>
<a href="http://www.famousleather.com/all-star-whistle-converse-patent-leather.html">all star whistle
converse patent leather</a>
<a href="http://www.famousleather.com/converse-all-star-whistle-patent-leather-shoes.html">converse all star
whistle patent leather shoes</a>
<a href="http://www.famousleather.com/leather-dog-collar.html">leather dog collar</a>
<a href="http://www.famousleather.com/leather-office-chair.html">leather office chair</a>
<a href="http://www.famousleather.com/leather-jewelry-box.html">leather jewelry box</a>
<a href="http://www.famousleather.com/leather-sectional-sofa.html">leather sectional
sofa</a>
<a href="http://www.famousleather.com/leather-cleaner.html">leather cleaner</a>
<a href="http://www.famousleather.com/leather-tote-bag.html">leather tote bag</a>
<a href="http://www.famousleather.com/leather-seat-cover.html">leather seat cover</a>
<a href="http://www.famousleather.com/leather-case.html">leather case</a>
<a href="http://www.famousleather.com/leather-travel-bag.html">leather travel bag</a>
<a href="http://www.famousleather.com/leather-sectional.html">leather sectional</a>
<a href="http://www.famousleather.com/man-leather-gloves.html">man leather gloves</a>
<a href="http://www.famousleather.com/leather-shoes.html">leather shoes</a>
<a href="http://www.famousleather.com/leather-care.html">leather care</a>
<a href="http://www.famousleather.com/woman-leather-jacket.html">woman leather jacket</a>
<a href="http://www.famousleather.com/black-leather.html">black leather</a>
<a href="http://www.famousleather.com/lady-leather-jacket.html">lady leather jacket</a>
<a href="http://www.famousleather.com/leather-accessory.html">leather accessory</a>
<a href="http://www.famousleather.com/leather-hide.html">leather hide</a>
<a href="http://www.famousleather.com/man-leather-pants.html">man leather pants</a>
<a href="http://www.famousleather.com/wide-selection-of-leather-coats.html">wide selection of leather
coats</a>
<a href="http://www.famousleather.com/leather-watch-band.html">leather watch band</a>
<a href="http://www.famousleather.com/vanson-leather.html">vanson leather</a>
<a href="http://www.famousleather.com/pelle-pelle-leather-jacket.html">pelle pelle leather
jacket</a>
<a href="http://www.famousleather.com/leather-armor.html">leather armor</a>
<a href="http://www.famousleather.com/leather-fetish.html">leather fetish</a>
<a href="http://www.famousleather.com/leather-product.html">leather product</a>
<a href="http://handbag.tamsquare.com">handbag</a>
<a href="http://shoes.tamsquare.com"> shoes</a>
<a href="http://lamp.tamsquare.com"> lamp</a>
<a href="http://peony.tamsquare.com"> peony</a>
<a href="http://luggage.tamsquare.com"> luggage</a>
<a href="http://gemstone.tamsquare.com"> gemstone</a>
<a href="http://platinum.tamsquare.com"> platinum</a>
<a href="http://frames.tamsquare.com"> frames</a>
<a href="http://sunglasses.tamsquare.com"> sunglasses</a>
<a href="http://furgarment.tamsquare.com"> fur garment</a>
<a href="http://crystal.tamsquare.com"> crystal</a>
<a href="http://backpacks.tamsquare.com"> backpacks</a>
<a href="http://briefcases.tamsquare.com"> briefcases</a>
<a href="http://furniture.tamsquare.com">furniture</a>
<a href="http://antique.tamsquare.com">antique</a>
<a href="http://plants.tamsquare.com">plants</a>
<a href="http://flowers.tamsquare.com">flowers</a>
<a href="http://rugs.tamsquare.com">rugs</a>
<a href="http://carpet.tamsquare.com"> carpet</a>
<a href="http://blinds.tamsquare.com"> blinds</a>
<a href="http://curtain.tamsquare.com"> curtain</a>
<a href="http://cookware.tamsquare.com"> cookware</a>
<a href="http://watches.tamsquare.com"> watches</a>
<a href="http://marble.tamsquare.com"> marble</a>
<a href="http://chairs.tamsquare.com">chairs</a>
<a href="http://sofa.tamsquare.com">sofa</a>
<a href="http://sculpture.tamsquare.com">sculpture</a>
<a href="http://golf.tamsquare.com">golf</a>
<a href="http://bicycles.tamsquare.com">bicycles</a>
<a href="http://leather.tamsquare.com">leather</a>
<a href="http://toys.tamsquare.com">toys</a>
<a href="http://pearl.tamsquare.com">pearl</a>
<a href="http://gold.tamsquare.com">gold</a>
<a href="http://silver.tamsquare.com">silver</a>
<a href="http://jewelry.tamsquare.com">jewelry</a>
<a href="http://diamond.tamsquare.com">diamond</a>
<a href="http://leather.handbag.com/wilsons-leather.html">wilsons leather</a>
<a href="http://leather.handbag.com/leather-jacket.html">leather jacket</a>
<a href="http://leather.handbag.com/leather.html">leather</a>
<a href="http://leather.handbag.com/leather-coats.html">leather coats</a>
<a href="http://leather.handbag.com/leather-sofa.html">leather sofa</a>
<a href="http://leather.handbag.com/leather-pants.html">leather pants</a>
<a href="http://leather.handbag.com/leather-furniture.html">leather furniture</a>
<a href="http://leather.handbag.com/leather-briefcase.html">leather briefcase</a>
<a href="http://leather.handbag.com/man-leather-jacket.html">man leather jacket</a>
<a href="http://leather.handbag.com/italian-leather.html">italian leather</a>
<a href="http://leather.handbag.com/leather-gloves.html">leather gloves</a>
<a href="http://leather.handbag.com/leather-handbag.html">leather handbag</a>
<a href="http://leather.handbag.com/leather-chair.html">leather chair</a>
<a href="http://leather.handbag.com/leather-lingerie.html">leather lingerie</a>
<a href="http://leather.handbag.com/womens-leather-jacket.html">womens leather jacket</a>
<a href="http://leather.handbag.com/leather-wallet.html">leather wallet</a>
<a href="http://leather.handbag.com/leather-skirt.html">leather skirt</a>
<a href="http://leather.handbag.com/leather-motorcycle-jacket.html">leather motorcycle jacket</a>
<a href="http://leather.handbag.com/shopping-fur-leather.html">shopping fur leather</a>
<a href="http://leather.handbag.com/leather-boot.html">leather boot</a>
<a href="http://leather.handbag.com/motorcycle-leather.html">motorcycle leather</a>
<a href="http://leather.handbag.com/man-leather-coats.html">man leather coats</a>
<a href="http://leather.handbag.com/leather-recliner.html">leather recliner</a>
<a href="http://leather.handbag.com/leather-belt.html">leather belt</a>
<a href="http://leather.handbag.com/womens-leather-coats.html">womens leather coats</a>
<a href="http://leather.handbag.com/leather-journal.html">leather journal</a>
<a href="http://leather.handbag.com/tandy-leather.html">tandy leather</a>
<a href="http://leather.handbag.com/leather-goods.html">leather goods</a>
<a href="http://leather.handbag.com/leather-backpack.html">leather backpack</a>
<a href="http://leather.handbag.com/leather-portfolio.html">leather portfolio</a>
<a href="http://leather.handbag.com/leather-bag.html">leather bag</a>
<a href="http://leather.handbag.com/leather-purse.html">leather purse</a>
<a href="http://leather.handbag.com/leather-couch.html">leather couch</a>
<a href="http://leather.handbag.com/coach-leather.html">coach leather</a>
<a href="http://leather.handbag.com/leather-repair.html">leather repair</a>
<a href="http://leather.handbag.com/leather-clothing.html">leather clothing</a>
<a href="http://leather.handbag.com/danier-leather.html">danier leather</a>
<a href="http://leather.handbag.com/leather-bomber-jacket.html">leather bomber jacket</a>
<a href="http://leather.handbag.com/leather-chap.html">leather chap</a>
<a href="http://leather.handbag.com/wholesale-leather.html">wholesale leather</a>
<a href="http://leather.handbag.com/leather-vest.html">leather vest</a>
<a href="http://leather.handbag.com/leather-luggage.html">leather luggage</a>
<a href="http://leather.handbag.com/cleaning-leather.html">cleaning leather</a>
<a href="http://leather.handbag.com/leather-apparel.html">leather apparel</a>
<a href="http://leather.handbag.com/leather-and-lace.html">leather and lace</a>
<a href="http://leather.handbag.com/liquid-leather.html">liquid leather</a>
<a href="http://leather.handbag.com/man-leather-wallet.html">man leather wallet</a>
<a href="http://leather.handbag.com/leather-store.html">leather store</a>
<a href="http://leather.handbag.com/leather-blazer.html">leather blazer</a>
<a href="http://leather.handbag.com/leather-man.html">leather man</a>
<a href="http://leather.handbag.com/leather-photo-album.html">leather photo album</a>
<a href="http://leather.handbag.com/leather-bracelet.html">leather bracelet</a>
<a href="http://leather.handbag.com/jennifer-leather.html">jennifer leather</a>
<a href="http://leather.handbag.com/leather-craft.html">leather craft</a>
<a href="http://leather.handbag.com/leather-hat.html">leather hat</a>
<a href="http://leather.handbag.com/leather-messenger-bag.html">leather messenger bag</a>
<a href="http://leather.handbag.com/leather-sectionals.html">leather sectionals</a>
<a href="http://leather.handbag.com/leather-trench-coats.html">leather trench coats</a>
<a href="http://leather.handbag.com/leather-clothes.html">leather clothes</a>
<a href="http://leather.handbag.com/puma-mostro-leather.html">puma mostro leather</a>
<a href="http://leather.handbag.com/leather-ottoman.html">leather ottoman</a>
<a href="http://leather.handbag.com/leather-money-clip.html">leather money clip</a>
<a href="http://leather.handbag.com/harley-davidson-leather-boot.html">harley davidson leather boot</a>
<a href="http://leather.handbag.com/puma-h-street-leather.html">puma h street leather</a>
<a href="http://leather.handbag.com/keds-leather.html">keds leather</a>
<a href="http://leather.handbag.com/leather-corset.html">leather corset</a>
<a href="http://leather.handbag.com/biker-leather.html">biker leather</a>
<a href="http://leather.handbag.com/leather-factory.html">leather factory</a>
<a href="http://leather.handbag.com/gay-leather.html">gay leather</a>
<a href="http://leather.handbag.com/leather-dress.html">leather dress</a>
<a href="http://leather.handbag.com/buy-converse-bomber-leather-shoes.html">buy converse bomber leather
shoes</a>
<a href="http://leather.handbag.com/non-leather-new-balance-shoes.html">non leather new balance shoes</a>
<a href="http://leather.handbag.com/all-star-whistle-converse-patent-leather.html">all star whistle converse
patent leather</a>
<a href="http://leather.handbag.com/converse-all-star-whistle-patent-leather-shoes.html">converse all star
whistle patent leather shoes</a>
<a href="http://leather.handbag.com/leather-dog-collar.html">leather dog collar</a>
<a href="http://leather.handbag.com/leather-office-chair.html">leather office chair</a>
<a href="http://leather.handbag.com/leather-jewelry-box.html">leather jewelry box</a>
<a href="http://leather.handbag.com/leather-sectional-sofa.html">leather sectional sofa</a>
<a href="http://leather.handbag.com/leather-cleaner.html">leather cleaner</a>
<a href="http://leather.handbag.com/leather-tote-bag.html">leather tote bag</a>
<a href="http://leather.handbag.com/leather-seat-cover.html">leather seat cover</a>
<a href="http://leather.handbag.com/leather-case.html">leather case</a>
<a href="http://leather.handbag.com/leather-travel-bag.html">leather travel bag</a>
<a href="http://leather.handbag.com/leather-sectional.html">leather sectional</a>
<a href="http://leather.handbag.com/man-leather-gloves.html">man leather gloves</a>
<a href="http://leather.handbag.com/leather-shoes.html">leather shoes</a>
<a href="http://leather.handbag.com/leather-care.html">leather care</a>
<a href="http://leather.handbag.com/woman-leather-jacket.html">woman leather jacket</a>
<a href="http://leather.handbag.com/black-leather.html">black leather</a>
<a href="http://leather.handbag.com/lady-leather-jacket.html">lady leather jacket</a>
<a href="http://leather.handbag.com/leather-accessory.html">leather accessory</a>
<a href="http://leather.handbag.com/leather-hide.html">leather hide</a>
<a href="http://leather.handbag.com/man-leather-pants.html">man leather pants</a>
<a href="http://leather.handbag.com/wide-selection-of-leather-coats.html">wide selection of leather
coats</a>
<a href="http://leather.handbag.com/leather-watch-band.html">leather watch band</a>
<a href="http://leather.handbag.com/vanson-leather.html">vanson leather</a>
<a href="http://leather.handbag.com/pelle-pelle-leather-jacket.html">pelle pelle leather jacket</a>
<a href="http://leather.handbag.com/leather-armor.html">leather armor</a>
<a href="http://leather.handbag.com/leather-fetish.html">leather fetish</a>
<a href="http://leather.handbag.com/leather-product.html">leather product</a>
Additions:
<a href="http://handbag.tamsquare.com/handbag.html">handbag</a>
<a href="http://handbag.tamsquare.com/coach-handbag.html">coach handbag</a>
<a href="http://handbag.tamsquare.com/designer-handbag.html">designer handbag</a>
<a href="http://handbag.tamsquare.com/gucci-handbag.html">gucci handbag</a>
<a href="http://handbag.tamsquare.com/louis-vuitton-handbag.html">louis vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/wholesale-handbag.html">wholesale handbag</a>
<a href="http://handbag.tamsquare.com/replica-handbag.html">replica handbag</a>
<a href="http://handbag.tamsquare.com/prada-handbag.html">prada handbag</a>
<a href="http://handbag.tamsquare.com/burberry-handbag.html">burberry handbag</a>
<a href="http://handbag.tamsquare.com/chanel-handbag.html">chanel handbag</a>
<a href="http://handbag.tamsquare.com/dooney-bourke-handbag.html">dooney bourke
handbag</a>
<a href="http://handbag.tamsquare.com/fendi-handbag.html">fendi handbag</a>
<a href="http://handbag.tamsquare.com/replica-designer-handbag.html">replica designer
handbag</a>
<a href="http://handbag.tamsquare.com/ugg-handbag.html">ugg handbag</a>
<a href="http://handbag.tamsquare.com/leather-handbag.html">leather handbag</a>
<a href="http://handbag.tamsquare.com/handbag-purse.html">handbag purse</a>
<a href="http://handbag.tamsquare.com/christian-dior-handbag.html">christian dior
handbag</a>
<a href="http://handbag.tamsquare.com/louis-vuitton-replica-handbag.html">louis vuitton replica
handbag</a>
<a href="http://handbag.tamsquare.com/handbag-accessory.html">handbag accessory</a>
<a href="http://handbag.tamsquare.com/brighton-handbag.html">brighton handbag</a>
<a href="http://handbag.tamsquare.com/knockoff-handbag.html">knockoff handbag</a>
<a href="http://handbag.tamsquare.com/juicy-couture-handbag.html">juicy couture
handbag</a>
<a href="http://handbag.tamsquare.com/ugg-australia-handbag.html">ugg australia
handbag</a>
<a href="http://handbag.tamsquare.com/kate-spade-handbag.html">kate spade handbag</a>
<a href="http://handbag.tamsquare.com/womens-handbag.html">womens handbag</a>
<a href="http://handbag.tamsquare.com/guess-handbag.html">guess handbag</a>
<a href="http://handbag.tamsquare.com/discount-designer-handbag.html">discount designer
handbag</a>
<a href="http://handbag.tamsquare.com/discount-handbag.html">discount handbag</a>
<a href="http://handbag.tamsquare.com/dior-handbag.html">dior handbag</a>
<a href="http://handbag.tamsquare.com/dooney-and-burke-handbag.html">dooney and burke
handbag</a>
<a href="http://handbag.tamsquare.com/marc-jacobs-handbag.html">marc jacobs handbag</a>
<a href="http://handbag.tamsquare.com/handbag-bag.html">handbag bag</a>
<a href="http://handbag.tamsquare.com/lv-handbag.html">lv handbag</a>
<a href="http://handbag.tamsquare.com/hermes-handbag.html">hermes handbag</a>
<a href="http://handbag.tamsquare.com/bradley-handbag-vera.html">bradley handbag vera</a>
<a href="http://handbag.tamsquare.com/fashion-handbag.html">fashion handbag</a>
<a href="http://handbag.tamsquare.com/louis-vitton-handbag.html">louis vitton handbag</a>
<a href="http://handbag.tamsquare.com/wholesale-replica-handbag.html">wholesale replica
handbag</a>
<a href="http://handbag.tamsquare.com/fossil-handbag.html">fossil handbag</a>
<a href="http://handbag.tamsquare.com/fake-designer-handbag.html">fake designer
handbag</a>
<a href="http://handbag.tamsquare.com/designer-inspired-handbag.html">designer inspired
handbag</a>
<a href="http://handbag.tamsquare.com/wholesale-designer-handbag.html">wholesale designer
handbag</a>
<a href="http://handbag.tamsquare.com/authentic-gucci-handbag.html">authentic gucci
handbag</a>
<a href="http://handbag.tamsquare.com/authentic-louis-vuitton-handbag.html">authentic louis vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/initial-handbag.html">initial handbag</a>
<a href="http://handbag.tamsquare.com/designer-knockoff-handbag.html">designer knockoff
handbag</a>
<a href="http://handbag.tamsquare.com/michael-kors-handbag.html">michael kors handbag</a>
<a href="http://handbag.tamsquare.com/stone-mountain-handbag.html">stone mountain
handbag</a>
<a href="http://handbag.tamsquare.com/accessory-handbag-shoes-womens.html">accessory handbag shoes
womens</a>
<a href="http://handbag.tamsquare.com/replica-coach-handbag.html">replica coach
handbag</a>
<a href="http://handbag.tamsquare.com/handmade-handbag.html">handmade handbag</a>
<a href="http://handbag.tamsquare.com/nine-west-handbag.html">nine west handbag</a>
<a href="http://handbag.tamsquare.com/tods-handbag.html">tods handbag</a>
<a href="http://handbag.tamsquare.com/chanel-replica-handbag.html">chanel replica
handbag</a>
<a href="http://handbag.tamsquare.com/vintage-handbag.html">vintage handbag</a>
<a href="http://handbag.tamsquare.com/discount-coach-handbag.html">discount coach
handbag</a>
<a href="http://handbag.tamsquare.com/knock-off-handbag.html">knock off handbag</a>
<a href="http://handbag.tamsquare.com/handbag-shoes.html">handbag shoes</a>
<a href="http://handbag.tamsquare.com/xoxo-handbag.html">xoxo handbag</a>
<a href="http://handbag.tamsquare.com/photo-handbag.html">photo handbag</a>
<a href="http://handbag.tamsquare.com/balenciaga-handbag.html">balenciaga handbag</a>
<a href="http://handbag.tamsquare.com/dkny-handbag.html">dkny handbag</a>
<a href="http://handbag.tamsquare.com/brahmin-handbag.html">brahmin handbag</a>
<a href="http://handbag.tamsquare.com/name-brand-handbag.html">name brand handbag</a>
<a href="http://handbag.tamsquare.com/mary-frances-handbag.html">mary frances handbag</a>
<a href="http://handbag.tamsquare.com/gucci-replica-handbag.html">gucci replica
handbag</a>
<a href="http://handbag.tamsquare.com/cheap-handbag.html">cheap handbag</a>
<a href="http://handbag.tamsquare.com/the-sak-handbag.html">the sak handbag</a>
<a href="http://handbag.tamsquare.com/hobo-handbag.html">hobo handbag</a>
<a href="http://handbag.tamsquare.com/imitation-handbag.html">imitation handbag</a>
<a href="http://handbag.tamsquare.com/hype-handbag.html">hype handbag</a>
<a href="http://handbag.tamsquare.com/fake-handbag.html">fake handbag</a>
<a href="http://handbag.tamsquare.com/channel-handbag.html">channel handbag</a>
<a href="http://handbag.tamsquare.com/puma-handbag.html">puma handbag</a>
<a href="http://handbag.tamsquare.com/wholesale-purse-handbag.html">wholesale purse
handbag</a>
<a href="http://handbag.tamsquare.com/louis-vutton-handbag.html">louis vutton handbag</a>
<a href="http://handbag.tamsquare.com/louie-vuitton-handbag.html">louie vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/cheap-designer-handbag.html">cheap designer
handbag</a>
<a href="http://handbag.tamsquare.com/jewelry-handbag.html">jewelry handbag</a>
<a href="http://handbag.tamsquare.com/tommy-hilfiger-handbag.html">tommy hilfiger
handbag</a>
<a href="http://handbag.tamsquare.com/lady-handbag.html">lady handbag</a>
<a href="http://handbag.tamsquare.com/my-flat-in-london-handbag.html">my flat in london
handbag</a>
<a href="http://handbag.tamsquare.com/discount-louis-vuitton-handbag.html">discount louis vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/boot-handbag-ugg.html">boot handbag ugg</a>
<a href="http://handbag.tamsquare.com/liz-claiborne-handbag.html">liz claiborne
handbag</a>
<a href="http://handbag.tamsquare.com/kenneth-cole-new-york-handbag.html">kenneth cole new york
handbag</a>
<a href="http://handbag.tamsquare.com/wholesale-louis-vuitton-handbag.html">wholesale louis vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/unique-handbag.html">unique handbag</a>
<a href="http://handbag.tamsquare.com/luxury-handbag.html">luxury handbag</a>
<a href="http://handbag.tamsquare.com/discount-gucci-handbag.html">discount gucci
handbag</a>
<a href="http://handbag.tamsquare.com/handbag-totes.html">handbag totes</a>
<a href="http://handbag.tamsquare.com/authentic-chanel-handbag.html">authentic chanel
handbag</a>
<a href="http://handbag.tamsquare.com/imitation-designer-handbag.html">imitation designer
handbag</a>
<a href="http://handbag.tamsquare.com/handbag-replica-ugg.html">handbag replica ugg</a>
<a href="http://handbag.tamsquare.com/handbag-pattern.html">handbag pattern</a>
<a href="http://handbag.tamsquare.com/inge-handbag.html">inge handbag</a>
<a href="http://handbag.tamsquare.com/fake-louis-vuitton-handbag.html">fake louis vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/nicky-hilton-handbag.html">nicky hilton handbag</a>
<a href="http://handbag.tamsquare.com/franco-sarto-handbag.html">franco sarto handbag</a>
<a href="http://handbag.tamsquare.com/kenneth-cole-handbag.html">kenneth cole handbag</a>
<a href="http://www.famousleather.com/wilsons-leather.html">wilsons leather</a>
<a href="http://www.famousleather.com/leather-jacket.html">leather jacket</a>
<a href="http://www.famousleather.com/leather.html">leather</a>
<a href="http://www.famousleather.com/leather-coats.html">leather coats</a>
<a href="http://www.famousleather.com/leather-sofa.html">leather sofa</a>
<a href="http://www.famousleather.com/leather-pants.html">leather pants</a>
<a href="http://www.famousleather.com/leather-furniture.html">leather furniture</a>
<a href="http://www.famousleather.com/leather-briefcase.html">leather briefcase</a>
<a href="http://www.famousleather.com/man-leather-jacket.html">man leather jacket</a>
<a href="http://www.famousleather.com/italian-leather.html">italian leather</a>
<a href="http://www.famousleather.com/leather-gloves.html">leather gloves</a>
<a href="http://www.famousleather.com/leather-handbag.html">leather handbag</a>
<a href="http://www.famousleather.com/leather-chair.html">leather chair</a>
<a href="http://www.famousleather.com/leather-lingerie.html">leather lingerie</a>
<a href="http://www.famousleather.com/womens-leather-jacket.html">womens leather
jacket</a>
<a href="http://www.famousleather.com/leather-wallet.html">leather wallet</a>
<a href="http://www.famousleather.com/leather-skirt.html">leather skirt</a>
<a href="http://www.famousleather.com/leather-motorcycle-jacket.html">leather motorcycle
jacket</a>
<a href="http://www.famousleather.com/shopping-fur-leather.html">shopping fur leather</a>
<a href="http://www.famousleather.com/leather-boot.html">leather boot</a>
<a href="http://www.famousleather.com/motorcycle-leather.html">motorcycle leather</a>
<a href="http://www.famousleather.com/man-leather-coats.html">man leather coats</a>
<a href="http://www.famousleather.com/leather-recliner.html">leather recliner</a>
<a href="http://www.famousleather.com/leather-belt.html">leather belt</a>
<a href="http://www.famousleather.com/womens-leather-coats.html">womens leather coats</a>
<a href="http://www.famousleather.com/leather-journal.html">leather journal</a>
<a href="http://www.famousleather.com/tandy-leather.html">tandy leather</a>
<a href="http://www.famousleather.com/leather-goods.html">leather goods</a>
<a href="http://www.famousleather.com/leather-backpack.html">leather backpack</a>
<a href="http://www.famousleather.com/leather-portfolio.html">leather portfolio</a>
<a href="http://www.famousleather.com/leather-bag.html">leather bag</a>
<a href="http://www.famousleather.com/leather-purse.html">leather purse</a>
<a href="http://www.famousleather.com/leather-couch.html">leather couch</a>
<a href="http://www.famousleather.com/coach-leather.html">coach leather</a>
<a href="http://www.famousleather.com/leather-repair.html">leather repair</a>
<a href="http://www.famousleather.com/leather-clothing.html">leather clothing</a>
<a href="http://www.famousleather.com/danier-leather.html">danier leather</a>
<a href="http://www.famousleather.com/leather-bomber-jacket.html">leather bomber
jacket</a>
<a href="http://www.famousleather.com/leather-chap.html">leather chap</a>
<a href="http://www.famousleather.com/wholesale-leather.html">wholesale leather</a>
<a href="http://www.famousleather.com/leather-vest.html">leather vest</a>
<a href="http://www.famousleather.com/leather-luggage.html">leather luggage</a>
<a href="http://www.famousleather.com/cleaning-leather.html">cleaning leather</a>
<a href="http://www.famousleather.com/leather-apparel.html">leather apparel</a>
<a href="http://www.famousleather.com/leather-and-lace.html">leather and lace</a>
<a href="http://www.famousleather.com/liquid-leather.html">liquid leather</a>
<a href="http://www.famousleather.com/man-leather-wallet.html">man leather wallet</a>
<a href="http://www.famousleather.com/leather-store.html">leather store</a>
<a href="http://www.famousleather.com/leather-blazer.html">leather blazer</a>
<a href="http://www.famousleather.com/leather-man.html">leather man</a>
<a href="http://www.famousleather.com/leather-photo-album.html">leather photo album</a>
<a href="http://www.famousleather.com/leather-bracelet.html">leather bracelet</a>
<a href="http://www.famousleather.com/jennifer-leather.html">jennifer leather</a>
<a href="http://www.famousleather.com/leather-craft.html">leather craft</a>
<a href="http://www.famousleather.com/leather-hat.html">leather hat</a>
<a href="http://www.famousleather.com/leather-messenger-bag.html">leather messenger
bag</a>
<a href="http://www.famousleather.com/leather-sectionals.html">leather sectionals</a>
<a href="http://www.famousleather.com/leather-trench-coats.html">leather trench coats</a>
<a href="http://www.famousleather.com/leather-clothes.html">leather clothes</a>
<a href="http://www.famousleather.com/puma-mostro-leather.html">puma mostro leather</a>
<a href="http://www.famousleather.com/leather-ottoman.html">leather ottoman</a>
<a href="http://www.famousleather.com/leather-money-clip.html">leather money clip</a>
<a href="http://www.famousleather.com/harley-davidson-leather-boot.html">harley davidson leather
boot</a>
<a href="http://www.famousleather.com/puma-h-street-leather.html">puma h street
leather</a>
<a href="http://www.famousleather.com/keds-leather.html">keds leather</a>
<a href="http://www.famousleather.com/leather-corset.html">leather corset</a>
<a href="http://www.famousleather.com/biker-leather.html">biker leather</a>
<a href="http://www.famousleather.com/leather-factory.html">leather factory</a>
<a href="http://www.famousleather.com/gay-leather.html">gay leather</a>
<a href="http://www.famousleather.com/leather-dress.html">leather dress</a>
<a href="http://www.famousleather.com/buy-converse-bomber-leather-shoes.html">buy converse bomber leather
shoes</a>
<a href="http://www.famousleather.com/non-leather-new-balance-shoes.html">non leather new balance
shoes</a>
<a href="http://www.famousleather.com/all-star-whistle-converse-patent-leather.html">all star whistle
converse patent leather</a>
<a href="http://www.famousleather.com/converse-all-star-whistle-patent-leather-shoes.html">converse all star
whistle patent leather shoes</a>
<a href="http://www.famousleather.com/leather-dog-collar.html">leather dog collar</a>
<a href="http://www.famousleather.com/leather-office-chair.html">leather office chair</a>
<a href="http://www.famousleather.com/leather-jewelry-box.html">leather jewelry box</a>
<a href="http://www.famousleather.com/leather-sectional-sofa.html">leather sectional
sofa</a>
<a href="http://www.famousleather.com/leather-cleaner.html">leather cleaner</a>
<a href="http://www.famousleather.com/leather-tote-bag.html">leather tote bag</a>
<a href="http://www.famousleather.com/leather-seat-cover.html">leather seat cover</a>
<a href="http://www.famousleather.com/leather-case.html">leather case</a>
<a href="http://www.famousleather.com/leather-travel-bag.html">leather travel bag</a>
<a href="http://www.famousleather.com/leather-sectional.html">leather sectional</a>
<a href="http://www.famousleather.com/man-leather-gloves.html">man leather gloves</a>
<a href="http://www.famousleather.com/leather-shoes.html">leather shoes</a>
<a href="http://www.famousleather.com/leather-care.html">leather care</a>
<a href="http://www.famousleather.com/woman-leather-jacket.html">woman leather jacket</a>
<a href="http://www.famousleather.com/black-leather.html">black leather</a>
<a href="http://www.famousleather.com/lady-leather-jacket.html">lady leather jacket</a>
<a href="http://www.famousleather.com/leather-accessory.html">leather accessory</a>
<a href="http://www.famousleather.com/leather-hide.html">leather hide</a>
<a href="http://www.famousleather.com/man-leather-pants.html">man leather pants</a>
<a href="http://www.famousleather.com/wide-selection-of-leather-coats.html">wide selection of leather
coats</a>
<a href="http://www.famousleather.com/leather-watch-band.html">leather watch band</a>
<a href="http://www.famousleather.com/vanson-leather.html">vanson leather</a>
<a href="http://www.famousleather.com/pelle-pelle-leather-jacket.html">pelle pelle leather
jacket</a>
<a href="http://www.famousleather.com/leather-armor.html">leather armor</a>
<a href="http://www.famousleather.com/leather-fetish.html">leather fetish</a>
<a href="http://www.famousleather.com/leather-product.html">leather product</a>
<a href="http://handbag.tamsquare.com">handbag</a>
<a href="http://shoes.tamsquare.com"> shoes</a>
<a href="http://lamp.tamsquare.com"> lamp</a>
<a href="http://peony.tamsquare.com"> peony</a>
<a href="http://luggage.tamsquare.com"> luggage</a>
<a href="http://gemstone.tamsquare.com"> gemstone</a>
<a href="http://platinum.tamsquare.com"> platinum</a>
<a href="http://frames.tamsquare.com"> frames</a>
<a href="http://sunglasses.tamsquare.com"> sunglasses</a>
<a href="http://furgarment.tamsquare.com"> fur garment</a>
<a href="http://crystal.tamsquare.com"> crystal</a>
<a href="http://backpacks.tamsquare.com"> backpacks</a>
<a href="http://briefcases.tamsquare.com"> briefcases</a>
<a href="http://furniture.tamsquare.com">furniture</a>
<a href="http://antique.tamsquare.com">antique</a>
<a href="http://plants.tamsquare.com">plants</a>
<a href="http://flowers.tamsquare.com">flowers</a>
<a href="http://rugs.tamsquare.com">rugs</a>
<a href="http://carpet.tamsquare.com"> carpet</a>
<a href="http://blinds.tamsquare.com"> blinds</a>
<a href="http://curtain.tamsquare.com"> curtain</a>
<a href="http://cookware.tamsquare.com"> cookware</a>
<a href="http://watches.tamsquare.com"> watches</a>
<a href="http://marble.tamsquare.com"> marble</a>
<a href="http://chairs.tamsquare.com">chairs</a>
<a href="http://sofa.tamsquare.com">sofa</a>
<a href="http://sculpture.tamsquare.com">sculpture</a>
<a href="http://golf.tamsquare.com">golf</a>
<a href="http://bicycles.tamsquare.com">bicycles</a>
<a href="http://leather.tamsquare.com">leather</a>
<a href="http://toys.tamsquare.com">toys</a>
<a href="http://pearl.tamsquare.com">pearl</a>
<a href="http://gold.tamsquare.com">gold</a>
<a href="http://silver.tamsquare.com">silver</a>
<a href="http://jewelry.tamsquare.com">jewelry</a>
<a href="http://diamond.tamsquare.com">diamond</a>
<a href="http://leather.handbag.com/wilsons-leather.html">wilsons leather</a>
<a href="http://leather.handbag.com/leather-jacket.html">leather jacket</a>
<a href="http://leather.handbag.com/leather.html">leather</a>
<a href="http://leather.handbag.com/leather-coats.html">leather coats</a>
<a href="http://leather.handbag.com/leather-sofa.html">leather sofa</a>
<a href="http://leather.handbag.com/leather-pants.html">leather pants</a>
<a href="http://leather.handbag.com/leather-furniture.html">leather furniture</a>
<a href="http://leather.handbag.com/leather-briefcase.html">leather briefcase</a>
<a href="http://leather.handbag.com/man-leather-jacket.html">man leather jacket</a>
<a href="http://leather.handbag.com/italian-leather.html">italian leather</a>
<a href="http://leather.handbag.com/leather-gloves.html">leather gloves</a>
<a href="http://leather.handbag.com/leather-handbag.html">leather handbag</a>
<a href="http://leather.handbag.com/leather-chair.html">leather chair</a>
<a href="http://leather.handbag.com/leather-lingerie.html">leather lingerie</a>
<a href="http://leather.handbag.com/womens-leather-jacket.html">womens leather jacket</a>
<a href="http://leather.handbag.com/leather-wallet.html">leather wallet</a>
<a href="http://leather.handbag.com/leather-skirt.html">leather skirt</a>
<a href="http://leather.handbag.com/leather-motorcycle-jacket.html">leather motorcycle jacket</a>
<a href="http://leather.handbag.com/shopping-fur-leather.html">shopping fur leather</a>
<a href="http://leather.handbag.com/leather-boot.html">leather boot</a>
<a href="http://leather.handbag.com/motorcycle-leather.html">motorcycle leather</a>
<a href="http://leather.handbag.com/man-leather-coats.html">man leather coats</a>
<a href="http://leather.handbag.com/leather-recliner.html">leather recliner</a>
<a href="http://leather.handbag.com/leather-belt.html">leather belt</a>
<a href="http://leather.handbag.com/womens-leather-coats.html">womens leather coats</a>
<a href="http://leather.handbag.com/leather-journal.html">leather journal</a>
<a href="http://leather.handbag.com/tandy-leather.html">tandy leather</a>
<a href="http://leather.handbag.com/leather-goods.html">leather goods</a>
<a href="http://leather.handbag.com/leather-backpack.html">leather backpack</a>
<a href="http://leather.handbag.com/leather-portfolio.html">leather portfolio</a>
<a href="http://leather.handbag.com/leather-bag.html">leather bag</a>
<a href="http://leather.handbag.com/leather-purse.html">leather purse</a>
<a href="http://leather.handbag.com/leather-couch.html">leather couch</a>
<a href="http://leather.handbag.com/coach-leather.html">coach leather</a>
<a href="http://leather.handbag.com/leather-repair.html">leather repair</a>
<a href="http://leather.handbag.com/leather-clothing.html">leather clothing</a>
<a href="http://leather.handbag.com/danier-leather.html">danier leather</a>
<a href="http://leather.handbag.com/leather-bomber-jacket.html">leather bomber jacket</a>
<a href="http://leather.handbag.com/leather-chap.html">leather chap</a>
<a href="http://leather.handbag.com/wholesale-leather.html">wholesale leather</a>
<a href="http://leather.handbag.com/leather-vest.html">leather vest</a>
<a href="http://leather.handbag.com/leather-luggage.html">leather luggage</a>
<a href="http://leather.handbag.com/cleaning-leather.html">cleaning leather</a>
<a href="http://leather.handbag.com/leather-apparel.html">leather apparel</a>
<a href="http://leather.handbag.com/leather-and-lace.html">leather and lace</a>
<a href="http://leather.handbag.com/liquid-leather.html">liquid leather</a>
<a href="http://leather.handbag.com/man-leather-wallet.html">man leather wallet</a>
<a href="http://leather.handbag.com/leather-store.html">leather store</a>
<a href="http://leather.handbag.com/leather-blazer.html">leather blazer</a>
<a href="http://leather.handbag.com/leather-man.html">leather man</a>
<a href="http://leather.handbag.com/leather-photo-album.html">leather photo album</a>
<a href="http://leather.handbag.com/leather-bracelet.html">leather bracelet</a>
<a href="http://leather.handbag.com/jennifer-leather.html">jennifer leather</a>
<a href="http://leather.handbag.com/leather-craft.html">leather craft</a>
<a href="http://leather.handbag.com/leather-hat.html">leather hat</a>
<a href="http://leather.handbag.com/leather-messenger-bag.html">leather messenger bag</a>
<a href="http://leather.handbag.com/leather-sectionals.html">leather sectionals</a>
<a href="http://leather.handbag.com/leather-trench-coats.html">leather trench coats</a>
<a href="http://leather.handbag.com/leather-clothes.html">leather clothes</a>
<a href="http://leather.handbag.com/puma-mostro-leather.html">puma mostro leather</a>
<a href="http://leather.handbag.com/leather-ottoman.html">leather ottoman</a>
<a href="http://leather.handbag.com/leather-money-clip.html">leather money clip</a>
<a href="http://leather.handbag.com/harley-davidson-leather-boot.html">harley davidson leather boot</a>
<a href="http://leather.handbag.com/puma-h-street-leather.html">puma h street leather</a>
<a href="http://leather.handbag.com/keds-leather.html">keds leather</a>
<a href="http://leather.handbag.com/leather-corset.html">leather corset</a>
<a href="http://leather.handbag.com/biker-leather.html">biker leather</a>
<a href="http://leather.handbag.com/leather-factory.html">leather factory</a>
<a href="http://leather.handbag.com/gay-leather.html">gay leather</a>
<a href="http://leather.handbag.com/leather-dress.html">leather dress</a>
<a href="http://leather.handbag.com/buy-converse-bomber-leather-shoes.html">buy converse bomber leather
shoes</a>
<a href="http://leather.handbag.com/non-leather-new-balance-shoes.html">non leather new balance shoes</a>
<a href="http://leather.handbag.com/all-star-whistle-converse-patent-leather.html">all star whistle converse
patent leather</a>
<a href="http://leather.handbag.com/converse-all-star-whistle-patent-leather-shoes.html">converse all star
whistle patent leather shoes</a>
<a href="http://leather.handbag.com/leather-dog-collar.html">leather dog collar</a>
<a href="http://leather.handbag.com/leather-office-chair.html">leather office chair</a>
<a href="http://leather.handbag.com/leather-jewelry-box.html">leather jewelry box</a>
<a href="http://leather.handbag.com/leather-sectional-sofa.html">leather sectional sofa</a>
<a href="http://leather.handbag.com/leather-cleaner.html">leather cleaner</a>
<a href="http://leather.handbag.com/leather-tote-bag.html">leather tote bag</a>
<a href="http://leather.handbag.com/leather-seat-cover.html">leather seat cover</a>
<a href="http://leather.handbag.com/leather-case.html">leather case</a>
<a href="http://leather.handbag.com/leather-travel-bag.html">leather travel bag</a>
<a href="http://leather.handbag.com/leather-sectional.html">leather sectional</a>
<a href="http://leather.handbag.com/man-leather-gloves.html">man leather gloves</a>
<a href="http://leather.handbag.com/leather-shoes.html">leather shoes</a>
<a href="http://leather.handbag.com/leather-care.html">leather care</a>
<a href="http://leather.handbag.com/woman-leather-jacket.html">woman leather jacket</a>
<a href="http://leather.handbag.com/black-leather.html">black leather</a>
<a href="http://leather.handbag.com/lady-leather-jacket.html">lady leather jacket</a>
<a href="http://leather.handbag.com/leather-accessory.html">leather accessory</a>
<a href="http://leather.handbag.com/leather-hide.html">leather hide</a>
<a href="http://leather.handbag.com/man-leather-pants.html">man leather pants</a>
<a href="http://leather.handbag.com/wide-selection-of-leather-coats.html">wide selection of leather
coats</a>
<a href="http://leather.handbag.com/leather-watch-band.html">leather watch band</a>
<a href="http://leather.handbag.com/vanson-leather.html">vanson leather</a>
<a href="http://leather.handbag.com/pelle-pelle-leather-jacket.html">pelle pelle leather jacket</a>
<a href="http://leather.handbag.com/leather-armor.html">leather armor</a>
<a href="http://leather.handbag.com/leather-fetish.html">leather fetish</a>
<a href="http://leather.handbag.com/leather-product.html">leather product</a>
<a href="http://handbag.tamsquare.com/coach-handbag.html">coach handbag</a>
<a href="http://handbag.tamsquare.com/designer-handbag.html">designer handbag</a>
<a href="http://handbag.tamsquare.com/gucci-handbag.html">gucci handbag</a>
<a href="http://handbag.tamsquare.com/louis-vuitton-handbag.html">louis vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/wholesale-handbag.html">wholesale handbag</a>
<a href="http://handbag.tamsquare.com/replica-handbag.html">replica handbag</a>
<a href="http://handbag.tamsquare.com/prada-handbag.html">prada handbag</a>
<a href="http://handbag.tamsquare.com/burberry-handbag.html">burberry handbag</a>
<a href="http://handbag.tamsquare.com/chanel-handbag.html">chanel handbag</a>
<a href="http://handbag.tamsquare.com/dooney-bourke-handbag.html">dooney bourke
handbag</a>
<a href="http://handbag.tamsquare.com/fendi-handbag.html">fendi handbag</a>
<a href="http://handbag.tamsquare.com/replica-designer-handbag.html">replica designer
handbag</a>
<a href="http://handbag.tamsquare.com/ugg-handbag.html">ugg handbag</a>
<a href="http://handbag.tamsquare.com/leather-handbag.html">leather handbag</a>
<a href="http://handbag.tamsquare.com/handbag-purse.html">handbag purse</a>
<a href="http://handbag.tamsquare.com/christian-dior-handbag.html">christian dior
handbag</a>
<a href="http://handbag.tamsquare.com/louis-vuitton-replica-handbag.html">louis vuitton replica
handbag</a>
<a href="http://handbag.tamsquare.com/handbag-accessory.html">handbag accessory</a>
<a href="http://handbag.tamsquare.com/brighton-handbag.html">brighton handbag</a>
<a href="http://handbag.tamsquare.com/knockoff-handbag.html">knockoff handbag</a>
<a href="http://handbag.tamsquare.com/juicy-couture-handbag.html">juicy couture
handbag</a>
<a href="http://handbag.tamsquare.com/ugg-australia-handbag.html">ugg australia
handbag</a>
<a href="http://handbag.tamsquare.com/kate-spade-handbag.html">kate spade handbag</a>
<a href="http://handbag.tamsquare.com/womens-handbag.html">womens handbag</a>
<a href="http://handbag.tamsquare.com/guess-handbag.html">guess handbag</a>
<a href="http://handbag.tamsquare.com/discount-designer-handbag.html">discount designer
handbag</a>
<a href="http://handbag.tamsquare.com/discount-handbag.html">discount handbag</a>
<a href="http://handbag.tamsquare.com/dior-handbag.html">dior handbag</a>
<a href="http://handbag.tamsquare.com/dooney-and-burke-handbag.html">dooney and burke
handbag</a>
<a href="http://handbag.tamsquare.com/marc-jacobs-handbag.html">marc jacobs handbag</a>
<a href="http://handbag.tamsquare.com/handbag-bag.html">handbag bag</a>
<a href="http://handbag.tamsquare.com/lv-handbag.html">lv handbag</a>
<a href="http://handbag.tamsquare.com/hermes-handbag.html">hermes handbag</a>
<a href="http://handbag.tamsquare.com/bradley-handbag-vera.html">bradley handbag vera</a>
<a href="http://handbag.tamsquare.com/fashion-handbag.html">fashion handbag</a>
<a href="http://handbag.tamsquare.com/louis-vitton-handbag.html">louis vitton handbag</a>
<a href="http://handbag.tamsquare.com/wholesale-replica-handbag.html">wholesale replica
handbag</a>
<a href="http://handbag.tamsquare.com/fossil-handbag.html">fossil handbag</a>
<a href="http://handbag.tamsquare.com/fake-designer-handbag.html">fake designer
handbag</a>
<a href="http://handbag.tamsquare.com/designer-inspired-handbag.html">designer inspired
handbag</a>
<a href="http://handbag.tamsquare.com/wholesale-designer-handbag.html">wholesale designer
handbag</a>
<a href="http://handbag.tamsquare.com/authentic-gucci-handbag.html">authentic gucci
handbag</a>
<a href="http://handbag.tamsquare.com/authentic-louis-vuitton-handbag.html">authentic louis vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/initial-handbag.html">initial handbag</a>
<a href="http://handbag.tamsquare.com/designer-knockoff-handbag.html">designer knockoff
handbag</a>
<a href="http://handbag.tamsquare.com/michael-kors-handbag.html">michael kors handbag</a>
<a href="http://handbag.tamsquare.com/stone-mountain-handbag.html">stone mountain
handbag</a>
<a href="http://handbag.tamsquare.com/accessory-handbag-shoes-womens.html">accessory handbag shoes
womens</a>
<a href="http://handbag.tamsquare.com/replica-coach-handbag.html">replica coach
handbag</a>
<a href="http://handbag.tamsquare.com/handmade-handbag.html">handmade handbag</a>
<a href="http://handbag.tamsquare.com/nine-west-handbag.html">nine west handbag</a>
<a href="http://handbag.tamsquare.com/tods-handbag.html">tods handbag</a>
<a href="http://handbag.tamsquare.com/chanel-replica-handbag.html">chanel replica
handbag</a>
<a href="http://handbag.tamsquare.com/vintage-handbag.html">vintage handbag</a>
<a href="http://handbag.tamsquare.com/discount-coach-handbag.html">discount coach
handbag</a>
<a href="http://handbag.tamsquare.com/knock-off-handbag.html">knock off handbag</a>
<a href="http://handbag.tamsquare.com/handbag-shoes.html">handbag shoes</a>
<a href="http://handbag.tamsquare.com/xoxo-handbag.html">xoxo handbag</a>
<a href="http://handbag.tamsquare.com/photo-handbag.html">photo handbag</a>
<a href="http://handbag.tamsquare.com/balenciaga-handbag.html">balenciaga handbag</a>
<a href="http://handbag.tamsquare.com/dkny-handbag.html">dkny handbag</a>
<a href="http://handbag.tamsquare.com/brahmin-handbag.html">brahmin handbag</a>
<a href="http://handbag.tamsquare.com/name-brand-handbag.html">name brand handbag</a>
<a href="http://handbag.tamsquare.com/mary-frances-handbag.html">mary frances handbag</a>
<a href="http://handbag.tamsquare.com/gucci-replica-handbag.html">gucci replica
handbag</a>
<a href="http://handbag.tamsquare.com/cheap-handbag.html">cheap handbag</a>
<a href="http://handbag.tamsquare.com/the-sak-handbag.html">the sak handbag</a>
<a href="http://handbag.tamsquare.com/hobo-handbag.html">hobo handbag</a>
<a href="http://handbag.tamsquare.com/imitation-handbag.html">imitation handbag</a>
<a href="http://handbag.tamsquare.com/hype-handbag.html">hype handbag</a>
<a href="http://handbag.tamsquare.com/fake-handbag.html">fake handbag</a>
<a href="http://handbag.tamsquare.com/channel-handbag.html">channel handbag</a>
<a href="http://handbag.tamsquare.com/puma-handbag.html">puma handbag</a>
<a href="http://handbag.tamsquare.com/wholesale-purse-handbag.html">wholesale purse
handbag</a>
<a href="http://handbag.tamsquare.com/louis-vutton-handbag.html">louis vutton handbag</a>
<a href="http://handbag.tamsquare.com/louie-vuitton-handbag.html">louie vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/cheap-designer-handbag.html">cheap designer
handbag</a>
<a href="http://handbag.tamsquare.com/jewelry-handbag.html">jewelry handbag</a>
<a href="http://handbag.tamsquare.com/tommy-hilfiger-handbag.html">tommy hilfiger
handbag</a>
<a href="http://handbag.tamsquare.com/lady-handbag.html">lady handbag</a>
<a href="http://handbag.tamsquare.com/my-flat-in-london-handbag.html">my flat in london
handbag</a>
<a href="http://handbag.tamsquare.com/discount-louis-vuitton-handbag.html">discount louis vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/boot-handbag-ugg.html">boot handbag ugg</a>
<a href="http://handbag.tamsquare.com/liz-claiborne-handbag.html">liz claiborne
handbag</a>
<a href="http://handbag.tamsquare.com/kenneth-cole-new-york-handbag.html">kenneth cole new york
handbag</a>
<a href="http://handbag.tamsquare.com/wholesale-louis-vuitton-handbag.html">wholesale louis vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/unique-handbag.html">unique handbag</a>
<a href="http://handbag.tamsquare.com/luxury-handbag.html">luxury handbag</a>
<a href="http://handbag.tamsquare.com/discount-gucci-handbag.html">discount gucci
handbag</a>
<a href="http://handbag.tamsquare.com/handbag-totes.html">handbag totes</a>
<a href="http://handbag.tamsquare.com/authentic-chanel-handbag.html">authentic chanel
handbag</a>
<a href="http://handbag.tamsquare.com/imitation-designer-handbag.html">imitation designer
handbag</a>
<a href="http://handbag.tamsquare.com/handbag-replica-ugg.html">handbag replica ugg</a>
<a href="http://handbag.tamsquare.com/handbag-pattern.html">handbag pattern</a>
<a href="http://handbag.tamsquare.com/inge-handbag.html">inge handbag</a>
<a href="http://handbag.tamsquare.com/fake-louis-vuitton-handbag.html">fake louis vuitton
handbag</a>
<a href="http://handbag.tamsquare.com/nicky-hilton-handbag.html">nicky hilton handbag</a>
<a href="http://handbag.tamsquare.com/franco-sarto-handbag.html">franco sarto handbag</a>
<a href="http://handbag.tamsquare.com/kenneth-cole-handbag.html">kenneth cole handbag</a>
<a href="http://www.famousleather.com/wilsons-leather.html">wilsons leather</a>
<a href="http://www.famousleather.com/leather-jacket.html">leather jacket</a>
<a href="http://www.famousleather.com/leather.html">leather</a>
<a href="http://www.famousleather.com/leather-coats.html">leather coats</a>
<a href="http://www.famousleather.com/leather-sofa.html">leather sofa</a>
<a href="http://www.famousleather.com/leather-pants.html">leather pants</a>
<a href="http://www.famousleather.com/leather-furniture.html">leather furniture</a>
<a href="http://www.famousleather.com/leather-briefcase.html">leather briefcase</a>
<a href="http://www.famousleather.com/man-leather-jacket.html">man leather jacket</a>
<a href="http://www.famousleather.com/italian-leather.html">italian leather</a>
<a href="http://www.famousleather.com/leather-gloves.html">leather gloves</a>
<a href="http://www.famousleather.com/leather-handbag.html">leather handbag</a>
<a href="http://www.famousleather.com/leather-chair.html">leather chair</a>
<a href="http://www.famousleather.com/leather-lingerie.html">leather lingerie</a>
<a href="http://www.famousleather.com/womens-leather-jacket.html">womens leather
jacket</a>
<a href="http://www.famousleather.com/leather-wallet.html">leather wallet</a>
<a href="http://www.famousleather.com/leather-skirt.html">leather skirt</a>
<a href="http://www.famousleather.com/leather-motorcycle-jacket.html">leather motorcycle
jacket</a>
<a href="http://www.famousleather.com/shopping-fur-leather.html">shopping fur leather</a>
<a href="http://www.famousleather.com/leather-boot.html">leather boot</a>
<a href="http://www.famousleather.com/motorcycle-leather.html">motorcycle leather</a>
<a href="http://www.famousleather.com/man-leather-coats.html">man leather coats</a>
<a href="http://www.famousleather.com/leather-recliner.html">leather recliner</a>
<a href="http://www.famousleather.com/leather-belt.html">leather belt</a>
<a href="http://www.famousleather.com/womens-leather-coats.html">womens leather coats</a>
<a href="http://www.famousleather.com/leather-journal.html">leather journal</a>
<a href="http://www.famousleather.com/tandy-leather.html">tandy leather</a>
<a href="http://www.famousleather.com/leather-goods.html">leather goods</a>
<a href="http://www.famousleather.com/leather-backpack.html">leather backpack</a>
<a href="http://www.famousleather.com/leather-portfolio.html">leather portfolio</a>
<a href="http://www.famousleather.com/leather-bag.html">leather bag</a>
<a href="http://www.famousleather.com/leather-purse.html">leather purse</a>
<a href="http://www.famousleather.com/leather-couch.html">leather couch</a>
<a href="http://www.famousleather.com/coach-leather.html">coach leather</a>
<a href="http://www.famousleather.com/leather-repair.html">leather repair</a>
<a href="http://www.famousleather.com/leather-clothing.html">leather clothing</a>
<a href="http://www.famousleather.com/danier-leather.html">danier leather</a>
<a href="http://www.famousleather.com/leather-bomber-jacket.html">leather bomber
jacket</a>
<a href="http://www.famousleather.com/leather-chap.html">leather chap</a>
<a href="http://www.famousleather.com/wholesale-leather.html">wholesale leather</a>
<a href="http://www.famousleather.com/leather-vest.html">leather vest</a>
<a href="http://www.famousleather.com/leather-luggage.html">leather luggage</a>
<a href="http://www.famousleather.com/cleaning-leather.html">cleaning leather</a>
<a href="http://www.famousleather.com/leather-apparel.html">leather apparel</a>
<a href="http://www.famousleather.com/leather-and-lace.html">leather and lace</a>
<a href="http://www.famousleather.com/liquid-leather.html">liquid leather</a>
<a href="http://www.famousleather.com/man-leather-wallet.html">man leather wallet</a>
<a href="http://www.famousleather.com/leather-store.html">leather store</a>
<a href="http://www.famousleather.com/leather-blazer.html">leather blazer</a>
<a href="http://www.famousleather.com/leather-man.html">leather man</a>
<a href="http://www.famousleather.com/leather-photo-album.html">leather photo album</a>
<a href="http://www.famousleather.com/leather-bracelet.html">leather bracelet</a>
<a href="http://www.famousleather.com/jennifer-leather.html">jennifer leather</a>
<a href="http://www.famousleather.com/leather-craft.html">leather craft</a>
<a href="http://www.famousleather.com/leather-hat.html">leather hat</a>
<a href="http://www.famousleather.com/leather-messenger-bag.html">leather messenger
bag</a>
<a href="http://www.famousleather.com/leather-sectionals.html">leather sectionals</a>
<a href="http://www.famousleather.com/leather-trench-coats.html">leather trench coats</a>
<a href="http://www.famousleather.com/leather-clothes.html">leather clothes</a>
<a href="http://www.famousleather.com/puma-mostro-leather.html">puma mostro leather</a>
<a href="http://www.famousleather.com/leather-ottoman.html">leather ottoman</a>
<a href="http://www.famousleather.com/leather-money-clip.html">leather money clip</a>
<a href="http://www.famousleather.com/harley-davidson-leather-boot.html">harley davidson leather
boot</a>
<a href="http://www.famousleather.com/puma-h-street-leather.html">puma h street
leather</a>
<a href="http://www.famousleather.com/keds-leather.html">keds leather</a>
<a href="http://www.famousleather.com/leather-corset.html">leather corset</a>
<a href="http://www.famousleather.com/biker-leather.html">biker leather</a>
<a href="http://www.famousleather.com/leather-factory.html">leather factory</a>
<a href="http://www.famousleather.com/gay-leather.html">gay leather</a>
<a href="http://www.famousleather.com/leather-dress.html">leather dress</a>
<a href="http://www.famousleather.com/buy-converse-bomber-leather-shoes.html">buy converse bomber leather
shoes</a>
<a href="http://www.famousleather.com/non-leather-new-balance-shoes.html">non leather new balance
shoes</a>
<a href="http://www.famousleather.com/all-star-whistle-converse-patent-leather.html">all star whistle
converse patent leather</a>
<a href="http://www.famousleather.com/converse-all-star-whistle-patent-leather-shoes.html">converse all star
whistle patent leather shoes</a>
<a href="http://www.famousleather.com/leather-dog-collar.html">leather dog collar</a>
<a href="http://www.famousleather.com/leather-office-chair.html">leather office chair</a>
<a href="http://www.famousleather.com/leather-jewelry-box.html">leather jewelry box</a>
<a href="http://www.famousleather.com/leather-sectional-sofa.html">leather sectional
sofa</a>
<a href="http://www.famousleather.com/leather-cleaner.html">leather cleaner</a>
<a href="http://www.famousleather.com/leather-tote-bag.html">leather tote bag</a>
<a href="http://www.famousleather.com/leather-seat-cover.html">leather seat cover</a>
<a href="http://www.famousleather.com/leather-case.html">leather case</a>
<a href="http://www.famousleather.com/leather-travel-bag.html">leather travel bag</a>
<a href="http://www.famousleather.com/leather-sectional.html">leather sectional</a>
<a href="http://www.famousleather.com/man-leather-gloves.html">man leather gloves</a>
<a href="http://www.famousleather.com/leather-shoes.html">leather shoes</a>
<a href="http://www.famousleather.com/leather-care.html">leather care</a>
<a href="http://www.famousleather.com/woman-leather-jacket.html">woman leather jacket</a>
<a href="http://www.famousleather.com/black-leather.html">black leather</a>
<a href="http://www.famousleather.com/lady-leather-jacket.html">lady leather jacket</a>
<a href="http://www.famousleather.com/leather-accessory.html">leather accessory</a>
<a href="http://www.famousleather.com/leather-hide.html">leather hide</a>
<a href="http://www.famousleather.com/man-leather-pants.html">man leather pants</a>
<a href="http://www.famousleather.com/wide-selection-of-leather-coats.html">wide selection of leather
coats</a>
<a href="http://www.famousleather.com/leather-watch-band.html">leather watch band</a>
<a href="http://www.famousleather.com/vanson-leather.html">vanson leather</a>
<a href="http://www.famousleather.com/pelle-pelle-leather-jacket.html">pelle pelle leather
jacket</a>
<a href="http://www.famousleather.com/leather-armor.html">leather armor</a>
<a href="http://www.famousleather.com/leather-fetish.html">leather fetish</a>
<a href="http://www.famousleather.com/leather-product.html">leather product</a>
<a href="http://handbag.tamsquare.com">handbag</a>
<a href="http://shoes.tamsquare.com"> shoes</a>
<a href="http://lamp.tamsquare.com"> lamp</a>
<a href="http://peony.tamsquare.com"> peony</a>
<a href="http://luggage.tamsquare.com"> luggage</a>
<a href="http://gemstone.tamsquare.com"> gemstone</a>
<a href="http://platinum.tamsquare.com"> platinum</a>
<a href="http://frames.tamsquare.com"> frames</a>
<a href="http://sunglasses.tamsquare.com"> sunglasses</a>
<a href="http://furgarment.tamsquare.com"> fur garment</a>
<a href="http://crystal.tamsquare.com"> crystal</a>
<a href="http://backpacks.tamsquare.com"> backpacks</a>
<a href="http://briefcases.tamsquare.com"> briefcases</a>
<a href="http://furniture.tamsquare.com">furniture</a>
<a href="http://antique.tamsquare.com">antique</a>
<a href="http://plants.tamsquare.com">plants</a>
<a href="http://flowers.tamsquare.com">flowers</a>
<a href="http://rugs.tamsquare.com">rugs</a>
<a href="http://carpet.tamsquare.com"> carpet</a>
<a href="http://blinds.tamsquare.com"> blinds</a>
<a href="http://curtain.tamsquare.com"> curtain</a>
<a href="http://cookware.tamsquare.com"> cookware</a>
<a href="http://watches.tamsquare.com"> watches</a>
<a href="http://marble.tamsquare.com"> marble</a>
<a href="http://chairs.tamsquare.com">chairs</a>
<a href="http://sofa.tamsquare.com">sofa</a>
<a href="http://sculpture.tamsquare.com">sculpture</a>
<a href="http://golf.tamsquare.com">golf</a>
<a href="http://bicycles.tamsquare.com">bicycles</a>
<a href="http://leather.tamsquare.com">leather</a>
<a href="http://toys.tamsquare.com">toys</a>
<a href="http://pearl.tamsquare.com">pearl</a>
<a href="http://gold.tamsquare.com">gold</a>
<a href="http://silver.tamsquare.com">silver</a>
<a href="http://jewelry.tamsquare.com">jewelry</a>
<a href="http://diamond.tamsquare.com">diamond</a>
<a href="http://leather.handbag.com/wilsons-leather.html">wilsons leather</a>
<a href="http://leather.handbag.com/leather-jacket.html">leather jacket</a>
<a href="http://leather.handbag.com/leather.html">leather</a>
<a href="http://leather.handbag.com/leather-coats.html">leather coats</a>
<a href="http://leather.handbag.com/leather-sofa.html">leather sofa</a>
<a href="http://leather.handbag.com/leather-pants.html">leather pants</a>
<a href="http://leather.handbag.com/leather-furniture.html">leather furniture</a>
<a href="http://leather.handbag.com/leather-briefcase.html">leather briefcase</a>
<a href="http://leather.handbag.com/man-leather-jacket.html">man leather jacket</a>
<a href="http://leather.handbag.com/italian-leather.html">italian leather</a>
<a href="http://leather.handbag.com/leather-gloves.html">leather gloves</a>
<a href="http://leather.handbag.com/leather-handbag.html">leather handbag</a>
<a href="http://leather.handbag.com/leather-chair.html">leather chair</a>
<a href="http://leather.handbag.com/leather-lingerie.html">leather lingerie</a>
<a href="http://leather.handbag.com/womens-leather-jacket.html">womens leather jacket</a>
<a href="http://leather.handbag.com/leather-wallet.html">leather wallet</a>
<a href="http://leather.handbag.com/leather-skirt.html">leather skirt</a>
<a href="http://leather.handbag.com/leather-motorcycle-jacket.html">leather motorcycle jacket</a>
<a href="http://leather.handbag.com/shopping-fur-leather.html">shopping fur leather</a>
<a href="http://leather.handbag.com/leather-boot.html">leather boot</a>
<a href="http://leather.handbag.com/motorcycle-leather.html">motorcycle leather</a>
<a href="http://leather.handbag.com/man-leather-coats.html">man leather coats</a>
<a href="http://leather.handbag.com/leather-recliner.html">leather recliner</a>
<a href="http://leather.handbag.com/leather-belt.html">leather belt</a>
<a href="http://leather.handbag.com/womens-leather-coats.html">womens leather coats</a>
<a href="http://leather.handbag.com/leather-journal.html">leather journal</a>
<a href="http://leather.handbag.com/tandy-leather.html">tandy leather</a>
<a href="http://leather.handbag.com/leather-goods.html">leather goods</a>
<a href="http://leather.handbag.com/leather-backpack.html">leather backpack</a>
<a href="http://leather.handbag.com/leather-portfolio.html">leather portfolio</a>
<a href="http://leather.handbag.com/leather-bag.html">leather bag</a>
<a href="http://leather.handbag.com/leather-purse.html">leather purse</a>
<a href="http://leather.handbag.com/leather-couch.html">leather couch</a>
<a href="http://leather.handbag.com/coach-leather.html">coach leather</a>
<a href="http://leather.handbag.com/leather-repair.html">leather repair</a>
<a href="http://leather.handbag.com/leather-clothing.html">leather clothing</a>
<a href="http://leather.handbag.com/danier-leather.html">danier leather</a>
<a href="http://leather.handbag.com/leather-bomber-jacket.html">leather bomber jacket</a>
<a href="http://leather.handbag.com/leather-chap.html">leather chap</a>
<a href="http://leather.handbag.com/wholesale-leather.html">wholesale leather</a>
<a href="http://leather.handbag.com/leather-vest.html">leather vest</a>
<a href="http://leather.handbag.com/leather-luggage.html">leather luggage</a>
<a href="http://leather.handbag.com/cleaning-leather.html">cleaning leather</a>
<a href="http://leather.handbag.com/leather-apparel.html">leather apparel</a>
<a href="http://leather.handbag.com/leather-and-lace.html">leather and lace</a>
<a href="http://leather.handbag.com/liquid-leather.html">liquid leather</a>
<a href="http://leather.handbag.com/man-leather-wallet.html">man leather wallet</a>
<a href="http://leather.handbag.com/leather-store.html">leather store</a>
<a href="http://leather.handbag.com/leather-blazer.html">leather blazer</a>
<a href="http://leather.handbag.com/leather-man.html">leather man</a>
<a href="http://leather.handbag.com/leather-photo-album.html">leather photo album</a>
<a href="http://leather.handbag.com/leather-bracelet.html">leather bracelet</a>
<a href="http://leather.handbag.com/jennifer-leather.html">jennifer leather</a>
<a href="http://leather.handbag.com/leather-craft.html">leather craft</a>
<a href="http://leather.handbag.com/leather-hat.html">leather hat</a>
<a href="http://leather.handbag.com/leather-messenger-bag.html">leather messenger bag</a>
<a href="http://leather.handbag.com/leather-sectionals.html">leather sectionals</a>
<a href="http://leather.handbag.com/leather-trench-coats.html">leather trench coats</a>
<a href="http://leather.handbag.com/leather-clothes.html">leather clothes</a>
<a href="http://leather.handbag.com/puma-mostro-leather.html">puma mostro leather</a>
<a href="http://leather.handbag.com/leather-ottoman.html">leather ottoman</a>
<a href="http://leather.handbag.com/leather-money-clip.html">leather money clip</a>
<a href="http://leather.handbag.com/harley-davidson-leather-boot.html">harley davidson leather boot</a>
<a href="http://leather.handbag.com/puma-h-street-leather.html">puma h street leather</a>
<a href="http://leather.handbag.com/keds-leather.html">keds leather</a>
<a href="http://leather.handbag.com/leather-corset.html">leather corset</a>
<a href="http://leather.handbag.com/biker-leather.html">biker leather</a>
<a href="http://leather.handbag.com/leather-factory.html">leather factory</a>
<a href="http://leather.handbag.com/gay-leather.html">gay leather</a>
<a href="http://leather.handbag.com/leather-dress.html">leather dress</a>
<a href="http://leather.handbag.com/buy-converse-bomber-leather-shoes.html">buy converse bomber leather
shoes</a>
<a href="http://leather.handbag.com/non-leather-new-balance-shoes.html">non leather new balance shoes</a>
<a href="http://leather.handbag.com/all-star-whistle-converse-patent-leather.html">all star whistle converse
patent leather</a>
<a href="http://leather.handbag.com/converse-all-star-whistle-patent-leather-shoes.html">converse all star
whistle patent leather shoes</a>
<a href="http://leather.handbag.com/leather-dog-collar.html">leather dog collar</a>
<a href="http://leather.handbag.com/leather-office-chair.html">leather office chair</a>
<a href="http://leather.handbag.com/leather-jewelry-box.html">leather jewelry box</a>
<a href="http://leather.handbag.com/leather-sectional-sofa.html">leather sectional sofa</a>
<a href="http://leather.handbag.com/leather-cleaner.html">leather cleaner</a>
<a href="http://leather.handbag.com/leather-tote-bag.html">leather tote bag</a>
<a href="http://leather.handbag.com/leather-seat-cover.html">leather seat cover</a>
<a href="http://leather.handbag.com/leather-case.html">leather case</a>
<a href="http://leather.handbag.com/leather-travel-bag.html">leather travel bag</a>
<a href="http://leather.handbag.com/leather-sectional.html">leather sectional</a>
<a href="http://leather.handbag.com/man-leather-gloves.html">man leather gloves</a>
<a href="http://leather.handbag.com/leather-shoes.html">leather shoes</a>
<a href="http://leather.handbag.com/leather-care.html">leather care</a>
<a href="http://leather.handbag.com/woman-leather-jacket.html">woman leather jacket</a>
<a href="http://leather.handbag.com/black-leather.html">black leather</a>
<a href="http://leather.handbag.com/lady-leather-jacket.html">lady leather jacket</a>
<a href="http://leather.handbag.com/leather-accessory.html">leather accessory</a>
<a href="http://leather.handbag.com/leather-hide.html">leather hide</a>
<a href="http://leather.handbag.com/man-leather-pants.html">man leather pants</a>
<a href="http://leather.handbag.com/wide-selection-of-leather-coats.html">wide selection of leather
coats</a>
<a href="http://leather.handbag.com/leather-watch-band.html">leather watch band</a>
<a href="http://leather.handbag.com/vanson-leather.html">vanson leather</a>
<a href="http://leather.handbag.com/pelle-pelle-leather-jacket.html">pelle pelle leather jacket</a>
<a href="http://leather.handbag.com/leather-armor.html">leather armor</a>
<a href="http://leather.handbag.com/leather-fetish.html">leather fetish</a>
<a href="http://leather.handbag.com/leather-product.html">leather product</a>
Additions:
See GrabCodeHandler for a first proposal -- DarTar
Deletions:
Additions:
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//?
See CodeSnippetHandler for a first proposal -- DarTar
See CodeSnippetHandler for a first proposal -- DarTar
Deletions:
Additions:
===Security Verification Test from Wikini===
~&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
~&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
Deletions:
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
Revision [6057]
Edited on 2005-02-16 21:53:11 by JavaWoman [reaction re: Automatic Table of Content Generation]Additions:
~&Have a look at TableofcontentsAction for some ideas about creating a TOC (automatically or triggered by an action...) --JavaWoman
Revision [6050]
Edited on 2005-02-16 16:58:28 by ChristianBarthelemy [Info for KarmaTester, DarTar and IanAndolina]Additions:
~~& Some more at IconsInWikka -- ChristianBarthelemy
Additions:
~~& 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
Additions:
{{lastedit show="3"}}
Additions:
~& 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
Revision [6022]
Edited on 2005-02-16 07:32:27 by DotMG [reply to Ian Andolina's SecurityVerifTest, suggesting .htaccess workaround to favicon.ico]Additions:
===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
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
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
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
Deletions:
Add this to, for example handler/page/revisions.xml.php:
%%(php)<?php
$xml = "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n";
$xml .= '<?xml-stylesheet href="' . $this->GetConfigValue("base_url") .'/css/xml.css" type="text/css"?' .">\n";
?>%%
Add a file named xml.css in css/, the content is like XmlStyleSheet
--DotMG
Revision [6020]
Edited on 2005-02-16 06:58:30 by DotMG [RobotFriendlyPages : Adding link to RobotFriendly]Additions:
~&See RobotFriendly. --DotMG
Revision [6016]
Edited on 2005-02-16 06:28:55 by KarmaTester [Section Editing Redux, Category Icons, TOC]Additions:
===Section Editing Redux===
Instead of a full blown section editing implementation why not just implement a tag like '<WikiPage>' which inserts the contents of WikiPage (no comments) at the markers location. <WikiPage x> would insert the first x lines of the WikiPage into the current page. And/or <WikiPage Header> would pull just the section of the page which is demarked by Header and EOP or next header. Such sections can be inserted in a special color/block/font/whatever and automatically link back to the original page for editing. The goal is to provide better editing granularity and readability on pages which have lots of information density. Could also be used to mimic blog functionality. -KarmaTester
===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
===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
----
Instead of a full blown section editing implementation why not just implement a tag like '<WikiPage>' which inserts the contents of WikiPage (no comments) at the markers location. <WikiPage x> would insert the first x lines of the WikiPage into the current page. And/or <WikiPage Header> would pull just the section of the page which is demarked by Header and EOP or next header. Such sections can be inserted in a special color/block/font/whatever and automatically link back to the original page for editing. The goal is to provide better editing granularity and readability on pages which have lots of information density. Could also be used to mimic blog functionality. -KarmaTester
===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
===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
----
Additions:
~~~&With my current proposed structure on WikkaCodeStructure, it would go into the library folder; classes that are shared, into library/common. I prefer a //functional// separation rather than one based on coding format. --JavaWoman
Additions:
~~&Maybe a folder called classes? the handlers/page/diff has a bunch of classes inside, too. --NilsLindenberg
Revision [5987]
Edited on 2005-02-15 10:49:20 by GmBowen [insights from Robot FRiendly Pages addition]Additions:
~&Ah, maybe this is why a now non-existent page that I deleted 2 months ago is still getting 50hits or so a day from the porn/vicodin/viagra sites that linked to it (don't ask //me// why...it was a completely inoccuous page)...at least according to the referrers database table. --GmBowen
Additions:
~~~&DarTar, that's silly. The admin actions that you have developed are looking fantastic! I was never thinking of using phpMyEdit to replace your actions. I'm using phpMyEdit to interface with non-Wikka tables; I like to see the data shown from Wikka, and I also like being able to use Wikka formatting within the data. It might help if I gave an example of how I use phpMyEdit. [... I'll write an example later on ...] -- JsnX
Deletions:
Revision [5976]
Edited on 2005-02-15 04:19:54 by BarkerJr [Added Robot Friendly Pages and Added Missing Horizontal Lines.]Additions:
===Robot Friendly Pages===
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
Right now (1.1.6.0), if a non-existant page is requested, the wiki returns status code 200, which will cause the page to be indexed by search engine spiders. It'd probably be better to return 404 (not found) or 410 (gone) or include robots exclusion meta tags in the pages that don't exist. --BarkerJr
Additions:
=== //Kant-en-klaar// code blocks ===
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) open a ##/raw## version of the page;
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
~1) open a text editor;
~1) copy the code block;
~1) paste it in the text editor;
~1) save the file.
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//? -- DarTar
A micro-idea before going to bed. We all know it's a bad idea to copy code blocks from the formatted version of a page.
If I want to test some freshly posted code, here's what I have to do:
~1) open a ##/raw## version of the page;
~1) scan the page for the chunk of code I want to save (this can be pretty difficult on long source pages with no syntax highlighting);
~1) open a text editor;
~1) copy the code block;
~1) paste it in the text editor;
~1) save the file.
Wouldn't it be nice to have at the end of each code block a small link pointing to a handler allowing the user to download the code block with the right name and the right extension just //with one click//? -- DarTar
Additions:
===Security Verifiction 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
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
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
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Additions:
~&DiN, this is a //very// good idea. I fact, the idea had crossed my mind already, but thanks for the reminder. :) Indeed, a class belongs in a file of its own. --JavaWoman
Additions:
===mod_rewrite idea (.htaccess)===
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
(The following was copied from a comment on ModRewrite -- JavaWoman)
//Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include ""RewriteBase"" /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.
-- h-67-102-97-191.mclnva23.covad.net (2005-02-11 04:49:37)//
The installer **correctly** deduces the base path for the configuration; it could conceivably also detect if it's sitting in a subdirectory, and if so, dynamically change the .htaccess file and include the correct ""RewriteBase"" statement to take care of this. --JavaWoman
Revision [5920]
Edited on 2005-02-11 18:03:22 by JavaWoman ['tags in the edit-notes' moved to WikkaBugs]Deletions:
I made a edit note: "removed a <?php (to much)" and got "removed a". Perhaps replacing <> would be the better option? --NilsLindenberg
~&Funny - I just stumbled over the same problem - only in the RecentChanges newsfeed: the <?php causes imbalanced tags there, and thus a syntax error: until that post has "aged" off of the feed, it can't be loaded any more! The [[http://feedvalidator.org/check?url=http%3a%2f%2fwikka.jsnx.com%2fRecentChanges%2frecentchanges.xml validation result]] clearly shows what the problem is. So yes, edit notes should be fed threough htmlspecialchars[_ent]() everywhere they're presented, and that includes the RSS feed! --JavaWoman
~~&And the WikiPing, too :) --NilsLindenberg
~&Oh is **that** what you removed Nils. I couldn't figure out using history what you did. Where did you take it from? And why? Did I have one more <?php than was necessary? In which code block? --GmBowen
~~&It was at the beginning of mail.php: %%(php) <?php <?php%%. I guess you overlooked it when you copied your new version to the page. Happent to me in another case, too. --NilsLindenberg
Additions:
~~&And the WikiPing, too :) --NilsLindenberg
~&Oh is **that** what you removed Nils. I couldn't figure out using history what you did. Where did you take it from? And why? Did I have one more <?php than was necessary? In which code block? --GmBowen
~~&It was at the beginning of mail.php: %%(php) <?php <?php%%. I guess you overlooked it when you copied your new version to the page. Happent to me in another case, too. --NilsLindenberg
~&Oh is **that** what you removed Nils. I couldn't figure out using history what you did. Where did you take it from? And why? Did I have one more <?php than was necessary? In which code block? --GmBowen
~~&It was at the beginning of mail.php: %%(php) <?php <?php%%. I guess you overlooked it when you copied your new version to the page. Happent to me in another case, too. --NilsLindenberg
Deletions:
~~~&It was at the beginning of mail.php: %%(php) <?php <?php%%. I guess you overlooked it when you copied your new version to the page. Happent to me in another case, too. --NilsLindenberg
Additions:
~~~&It was at the beginning of mail.php: %%(php) <?php <?php%%. I guess you overlooked it when you copied your new version to the page. Happent to me in another case, too. --NilsLindenberg
Additions:
~~&Oh is **that** what you removed Nils. I couldn't figure out using history what you did. Where did you take it from? And why? Did I have one more <?php than was necessary? In which code block? --GmBowen
Revision [5892]
Edited on 2005-02-10 20:05:23 by JavaWoman [addition to tags in edit notes bug + RSS validator link]Additions:
I made a edit note: "removed a <?php (to much)" and got "removed a". Perhaps replacing <> would be the better option? --NilsLindenberg
~&Funny - I just stumbled over the same problem - only in the RecentChanges newsfeed: the <?php causes imbalanced tags there, and thus a syntax error: until that post has "aged" off of the feed, it can't be loaded any more! The [[http://feedvalidator.org/check?url=http%3a%2f%2fwikka.jsnx.com%2fRecentChanges%2frecentchanges.xml validation result]] clearly shows what the problem is. So yes, edit notes should be fed threough htmlspecialchars[_ent]() everywhere they're presented, and that includes the RSS feed! --JavaWoman
~&Funny - I just stumbled over the same problem - only in the RecentChanges newsfeed: the <?php causes imbalanced tags there, and thus a syntax error: until that post has "aged" off of the feed, it can't be loaded any more! The [[http://feedvalidator.org/check?url=http%3a%2f%2fwikka.jsnx.com%2fRecentChanges%2frecentchanges.xml validation result]] clearly shows what the problem is. So yes, edit notes should be fed threough htmlspecialchars[_ent]() everywhere they're presented, and that includes the RSS feed! --JavaWoman
Deletions:
Revision [5890]
Edited on 2005-02-10 19:48:10 by NilsLindenberg [addition to tags in edit notes bug + RSS validator link]Additions:
===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
I made a edit note: "removed a <?php (to much)" and got "removed a". Perhaps replacing <> would be the better option? --NilsLindenberg
Revision [5786]
Edited on 2005-02-08 10:04:44 by DiN [addition to tags in edit notes bug + RSS validator link]Additions:
===Separation of Wakka class from wikka.php===
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
include ('Wakka.class.php');
-- DiN
I use wikka as wiki engine of [[http://diantn.free.fr my page]].
IMO, the wikka.php file is too big to be one single file. I suggest that we separate the Wakka class into new file, say Wakka.class.php
And then in the wikka.php, e.g at line where the Wakka class previously located, simply we put:
include ('Wakka.class.php');
-- DiN
Additions:
~&Well, Jason, I do think it would help I you would explain what you are using this **for** (especially if not for Wikka administration); I'd also like to know then why you chose phpMyEdit and not another browser-based client - and why a browser-based client in the first place. I've only ever tried phpMyAdmin and found it lacking because it tends (tended) to work on single tables only. I quickly switched to "real" clients that are more powerful and allow me to build queries involving several tables if needed, so consistency can be maintained. I have a bunch of handy tools (for Windows), all free: for design, administration and maintenance. And though I do have phpMyAdmin available, I don't intend to use it. --JavaWoman
~~~&LOL! But - "inadvertently"? Using double percent signs should be possible in code - and if not, that's a bug in Wikka, not your fault! (Not that I have a solution for that yet, though I have been thinking about that problem.) --JavaWoman
~~~&LOL! But - "inadvertently"? Using double percent signs should be possible in code - and if not, that's a bug in Wikka, not your fault! (Not that I have a solution for that yet, though I have been thinking about that problem.) --JavaWoman
Deletions:
Revision [5768]
Edited on 2005-02-07 23:13:54 by GmBowen [reply to JW re: her query to Jsn wrt PhpMyEdit]Additions:
~~&My bet is that Jason's using it to fix the pages where I've (inadertently) submitted double percent signs as part of submitted code so that the history feature works properly. {grin} --GmBowen
Additions:
~&Well, Jason, I do think it would help I you would explain what you are using this **for** (especially if not for Wikka administration); I'd also like to know then why you chode phpMyEdit and not another browser-based client - and why a browser-based client in the first place. I've only ever tried phpMyAdmin and found it lacking because it tends (tended) to work on single tables only. I quickly switched to "real" clients that are more powerful and allow me to build queries involving several tables if needed, so consistency can be maintained. I have a bunch of handy tools (for Windows), all free: for design, administration and maintenance. And though I do have phpMyAdmin available, I don't intend to use it. --JavaWoman
Revision [5754]
Edited on 2005-02-07 18:30:10 by JsnX [Replying to DarTar, JW, and Christian on phpMyEdit]Additions:
~~~~&DarTar, that's silly. The admin actions that you have developed are looking fantastic! I was never thinking of using phpMyEdit to replace your actions. I'm using phpMyEdit to interface with non-Wikka tables; I like to see the data shown from Wikka, and I also like being able to use Wikka formatting within the data. It might help if I gave an example of how I use phpMyEdit. [... I'll write an example later on ...] -- JsnX
~~~~&Thanks for the comments. I expected there would be some reservations about including this in Wikka. I too have some reservations about phpMyEdit. However, with that said, I also find it to be a **very useful** tool which I will continue to use. It doesn't matter to me whether phpMyEdit is ever an official Wikka component because using it requires zero modifications to the Wikka code -- there will be no ongoing maintenance when upgrading to new Wikka versions. It's not my intention to support this, but if someone wants to use it, I'm happy to make my modified phpMyEdit version available. I'm proposing this as an official "unofficial Wikka add-on". :) -- JsnX
~~&Yes, I plan to play around with it for a few more days, then I'll upload the code and some instructions. -- JsnX
~~~~&Thanks for the comments. I expected there would be some reservations about including this in Wikka. I too have some reservations about phpMyEdit. However, with that said, I also find it to be a **very useful** tool which I will continue to use. It doesn't matter to me whether phpMyEdit is ever an official Wikka component because using it requires zero modifications to the Wikka code -- there will be no ongoing maintenance when upgrading to new Wikka versions. It's not my intention to support this, but if someone wants to use it, I'm happy to make my modified phpMyEdit version available. I'm proposing this as an official "unofficial Wikka add-on". :) -- JsnX
~~&Yes, I plan to play around with it for a few more days, then I'll upload the code and some instructions. -- JsnX
Additions:
~&I am interested by the idea to interact with MySQL tables from a Wikka page. Would you please share the updated phpMyEdit code? --ChristianBarthelemy
Additions:
=====Suggestion Box=====
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
**See also:**
~-WikkaSpamFighting for spam-related issues
~-WikkaWorkarounds for specific platforms
~-WikkaOptimization
>>{{feedback}}::c::
===phpMyEdit in Wikka===
I've set up a demo of [[http://www.jsnx.com/wikka-dev/SuggestionBox phpMyEdit running within Wikka]]. This would be useful for anyone wanting to directly interact with MySQL tables from a Wikka page. -- JsnX
~&I assume this is meant for admins only but ... Could you add some explanation? I looked but don't have a clue how to use it. What are the radio buttons for, for instance? What's the "V" button at the top? The UI is very confusing. --JavaWoman
~~& Jsnx, that's interesting. I think the idea is worth consideration. I have used phpMyEdit as an interface to allow my users to store their profiles in the DB when I still was a MySQL newbie :) and it's true that it allows a number of tricky things (especially cross-reference between tables). So I think a plugin for integrating phpMyEdit within Wikka pages might be a nice extension. You probably know though that all the interface options can only be set by editing the source, or were you thinking of allowing some kind of admin access to the interface options? And be honest, are you thinking of phpMyEdit as a sort of replacement for my baby admin actions, aren't you?! In a sense this might be interesting, but it would really be unnecessary compared to what we can do by creating direct calls to the DB using core functions. Why heavily tweak an external script to do something wikka-like if we can already use something that only needs core functions? --- Moreover, when you perform operations on pages (like 'add', 'copy' or 'delete') you generally want to do something more complicated than just modify single records of the page table. Using phpMyEdit as a sort of proxy for a page admin action can lead to major inconsistencies in the page structure. --- And, JW, the "v" button is for filtering the table ;-) -- DarTar
~~~&Filtering? Well first it's not obvious, nor explained; but I just went back and tried pressing the "v" button - and I get three other mystifying buttons in return. Frankly, I don't want to use something as badly-designed as this. Shudder. DarTar, your Admin functions may need some refinement, but mystifying they are not. Let's stick with those, and build on them. Sorry, JsnX, but this doesn't get my vote. --JavaWoman
===Support for (Technorati) tags===
I think it might be interesting to provide Wikka support for (Technorati) "**tags**". "Tags" in this context are simple keywords that help identify and categorize web content, in particular blog posts. Such keywords coupled with a ping system can be used by remote servers to retrieve fresh content for specific topics. See for instance how technorati.com aggregates fresh information about [[http://www.technorati.com/tag/wiki wikis]] from a number of sources.
[[http://www.technorati.com/help/tags.html More information on Technorati tags]]
~&Seems like we need to update our RSS (feed) implementation first... --JavaWoman
===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
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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?
--GregorLindner
----
==Signature==
(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
----
== 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
----
== Create rewrite rules on install ==
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
== Image dimensions ==
The [[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
----
==Clearing ACLs==
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
----
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
== RSS options ==
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
----
== 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
----
== Language file ==
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
== 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
----
==Finally using CVS?==
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
==Stopping Spammers getting Google Juice==
//(moved to WikkaSpamFighting)//
----
==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
----
==Give control over HTML==
It would be nice to see a template engine in Wikka to give the users the full control over the HTML source. Smarty is always a good choice.
~& I would love to see Wikka adopt some type of template system. I think that its is sorely needed. Changing the look of Wikka requires tedious editing of php files, and alot of the time it is non-obvious where you need to go to edit such files. Another alternative to [[http://smarty.php.net Smarty]] could be [[http://wiki.ciaweb.net/yawiki/index.php?area=Savant Savant]]. --KickTheDonkey
~~&While I use and like Smarty very much (and it's quite fast), it's rather "heavy" for Wikka, I think. I just had a look at Savant2 which I hadn't heard of before. It looks like a good fit, is lightweight and easy to use. A templating system like this would also provide much more flexibility for Wikka admins to have control over page structure and layout. I'll want to play with it some (in combination with Wikka), but my first impression based on documentation and code is very favorable. More when I've had a chance to exercise it. --JavaWoman
----
==Allow spaces in pagetitle==
Allow Spaces in the document title and replace it later with "-" to optimize it for search engines.
----
==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
----
==Local links==
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--KickTheDonkey
----
==Idea for Category Support==
moved to CategorySystemOverhaul, it is the better place, thanks DarTar
--ArpY
~& ArpY, take a look at CategorySystemOverhaul for an open discussion on how to improve the category system -- DarTar
----
==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.
----
==Section Editing ==
- http://c2.com/cgi/wiki?SectionEditing
- It makes allows you to flow and edit much quicker.
- Each topic should have a corresponding edit button. This allows your to edit each section with out breaking your flow.
- http://www.splitbrain.org/dokuwiki/wiki:section_editing
----
==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
----
==Standard date and time format==
Although I'm all for using the ISO date/time format as we see in the timestamp of the footer of every page, I note that several other parts of Wikka use different date/time formats. I'd like to see an approach where this is standardized.
Proposal:
~-Define date-time format (or separately date and time, as well as a way to combine them) in the configuration; use the ISO format as a default (in the initial configuration, as well as when no format is defined in the config).
~-Use this format wherever date and/or time are formatted.
~-Make using the configured formats a requirement for every Wikka extension (that displays date/time information) to be included with the distribution.
I realize that in principle it's possible to pick up formats from a locale but for a Wikka targeted at an international audience this may not be the best approach, and for a Wikka with a "local" audience it may not be either if it's hosted on a (public) server outside that country - hence the idea to define a format in the configuration.
--JavaWoman
~''Agreed -- DarTar''
----
==Handling the config==
I have three questions about the config. See HandlingWikkaConfig.
--NilsLindenberg
''See also WikkaSecureConfig for a possible new appraoch. --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
----
==Online editing of mindmaps would be great==
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
----
==Tables ==
For the discussion on tables in Wikka, take a look at WikkaTables.
~&See also TableAction for a preliminary solution. --JavaWoman
----
==Wikka Exporting/Importing ==
Just added a few thoughts [[WikkaFilters here]]
-- DarTar
----
==how to format code to get two % characters without space together?==
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
----
==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
----
==showing comments==
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
----
==Language support==
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
----
== 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
----
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
----
== 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
----
==Using FPDF with Wikka==
Not so much a suggestion, more a request although it may be useful to others.
I have been using FPDF from [[http://www.fpdf.org FPDF ]] to export content from a database to pdf files.
I would like to extend my usage of FPDF to wikka by adding a hyperlink to the top of my wikka pages which would allow me to post the page tag or page id to the FPDF script for exporting the content into a pdf file.
The link would be in the form similar to
http://www.mysite.com/script.php?id=
Can anyone tell me how I can extract the page tag or page id from the wikka_pages table in order to do this.
----
====Resolved Suggestions====
== Question: PHP 4.3 and "mysql_escape_string()"? ==
For the Wikka Wakka Wiki 1.1.4.0 you need at least PHP 4.3 because the "mysql_real_escape_string()" in wakka.php is only available in PHP 4.3. A lot of hoster just offering PHP 4.1 or 4.2. Then you have to replace "mysql_real_escape_string()" with "mysql_escape_string()". What was the reason for the replacement in the new release? Again: Keep on the good work.
-- SkyWalk
~&The reason is that ##mysql_real_escape_string()## is more secure than ##mysql_escape_string()## so we want to take advantage of that; but as implemented this left users of older versions of PHP in the cold. A workaround for this will be in version 1.1.6.0 (see above) - now avaliable as a [[HomePage public beta]]. --JavaWoman
----
== Typo correction in embedded Wiki Edit 2 ==
For the new (1.1.6.0) release, line 645 of wikiedit2/wikiedit2.js should be fixed to say:
%% s += " Ctrl+Shift+Minus - Horizontal line\n";%%
not "horisontal." I've already fixed it in my local copy, but no sense in perpetuating errors. :) --MovieLady
~&Thanks to eagle-eyed JsnX it's //aready// fixed in 1.1.6.0 beta4 :) but thanks for the note! --JavaWoman
~~& Marvelous, thanks! :) --MovieLady
==Compatibility with PHP 4.1.x==
with Debian GNU/Linux 3.0 (woody) are installed PHP 4.1.2 and this version don't support "mysql_real_escape_string" function.
temporary fix on wikka.php head:
%%(php)
if ( ! function_exists("mysql_real_escape_string") )
{
function mysql_real_escape_string($string)
{
return mysql_escape_string($string);
}
}%%
~&This will be in version 1.1.6.0 - now avaliable as a [[HomePage public beta]]. --JavaWoman
==Don't let old pages get indexed==
//(moved to WikkaSpamFighting)//
==User page==
If someone registers as a new user and chooses a Wikiname, his wikinamepage is empty. I think it would be nice, if the page whould be created from the wiki, containing a text with perhaps a welcome, some (Wiki)rules and usefull pages (this text should be stored somewhere so that it could be customized from the WikiAdmin). The page should automatically belong to the category user. Regards, NilsLindenberg
==Non-breaking space in forced links==
Sometimes a forced link has a phrase as link description with spaces for readability but where these spaces should **not** cause wrapping in the middle of the string - in other words, the spaces really should be non-breaking spaces. Unfortunately, specifying ## ## will (unlike here) result in the entity becoming visible as an entity instead of as the character it encodes.
It should be possible to either specify ## ## where needed and have it result in the actual character (i.e., keep the actual entity rather than "escaping" it), or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
//**Note:** Actually, with the 1.1.6.0 beta version running on this site, this demonstrates how the new htmlspecialchars_unicode() function is indeed buggy - as I pointed out on WikkaDevelopment. The solution is presented [[WikkaDevelopment there]] now (look for **htmlspecialchars_unicode()**).//
--JavaWoman
==User Control==
Is there an easy way to not allow registration? I would like to have it so that I can control the registration process, not let just anyone sign-up.
--BooYa
... (Nils proposing a solution)
A nice contribution Nils. If you want to go further with fiddling with the code for registration, I've thought it would be useful if there was a feature that required a password from an administrator to be able to register so that if you were going to register you put in your user info (as now) and a password you've obtained from the admin that allows you to register....for instance, in this way a teacher could set up a wikki with registration "on" and send a note to all of the parents with the registration password so that they could register....outsiders couldn't register, only those with the registration key. Possibly a quite useful feature to many potential user groups. -- GmBowen
~Look at UserRegistration for the first version, or [[http://www.niehle.info/UserSettings try it]] --NilsLindenberg
----
==Cookies and logging out==
This issue issue moved to StayingLoggedIn!
==Page viewed counter==
It occurs to me that some kind of "counter" for how many times the wikipage has been viewed might be a useful "action" for somebody to be able to use...this way a page author would know how often somebody has gone to the page & this might help focus development (especially for those keeners that have multiple pages/projects). [and I agree with the contributor below....Wikkawiki is great software]
''I completed altering a script and modifying the wikka code for this.....go to GmBowenCounter for the php script and the necessary alterations'' --GmBowen
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
==Mod rewrite and a problem==
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough?
''Good catch. Adding the end slash should be fine. It will be added by default in the next Wikka release. -- Jsnx''
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. -- JockeAndersson
''Jocke, in the style sheet [wikka.css by default], add "text-decoration: none;" to the smallprint style. Or am I not understanding the problem? -- JsnX''
~~~.smallprint a {
~~~color: #987;
~~~text-decoration: none;
~~~}
It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
The reason the above addition to smallprint doesn't work is that the links are visited meaning the pseudo-class a:visited must be defined as well with "text-decoration: none" in it. There is no definition for a:visited in the css by default. Perhaps this should be added to Wikka's code? -- JockeAndersson
Sure, I'll add it. Just curious though, what web browser are you using? Internet Explorer does not show underlined links as you have described...at least not for me. -- JsnX
I'm currently using Mozilla Firefox, but I'm testing pages in IE as well. The underlines were only visible in Firefox. IE is usually the one to screw up page rendering, not being fully standards-compliant and all. Oh, and the code could use an a:active definition as well. Be sure to define them in correct order though: a visited hover active. W3C were specific about that for some reason. -- JockeAndersson
Thanks for the tip. By the way, your site looks awesome. -- JsnX
You really think so? Thanks!! :) Much of the general layout comes from A List Apart's site, but adapted to my needs. I've had a site running for a while but can't find the time to update it properly. I believe Wikka will change all that and am seriously thinking of replacing my ordinary site with a Wikka wiki. The forum will still be phpbb, but the site itself could really benefit from the pros of Wikka. I second [[MarkHissinkMuller MarkHissinkMullers]] suggestions for improvement. Especially the possibility to manage ACLs based on user groups as well as individual users, would be great. -- JockeAndersson
~& I tried to do something like this at ACLsWithUserGroups.
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action (LOL) if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}""). -- Mike Bowen
I use stylesheet for xml, I don't know anything about compatibility to validators :
Add this to, for example handler/page/revisions.xml.php:
%%(php)<?php
$xml = "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n";
$xml .= '<?xml-stylesheet href="' . $this->GetConfigValue("base_url") .'/css/xml.css" type="text/css"?' .">\n";
?>%%
Add a file named xml.css in css/, the content is like XmlStyleSheet
--DotMG
----
CategoryWikka
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
**See also:**
~-WikkaSpamFighting for spam-related issues
~-WikkaWorkarounds for specific platforms
~-WikkaOptimization
>>{{feedback}}::c::
===phpMyEdit in Wikka===
I've set up a demo of [[http://www.jsnx.com/wikka-dev/SuggestionBox phpMyEdit running within Wikka]]. This would be useful for anyone wanting to directly interact with MySQL tables from a Wikka page. -- JsnX
~&I assume this is meant for admins only but ... Could you add some explanation? I looked but don't have a clue how to use it. What are the radio buttons for, for instance? What's the "V" button at the top? The UI is very confusing. --JavaWoman
~~& Jsnx, that's interesting. I think the idea is worth consideration. I have used phpMyEdit as an interface to allow my users to store their profiles in the DB when I still was a MySQL newbie :) and it's true that it allows a number of tricky things (especially cross-reference between tables). So I think a plugin for integrating phpMyEdit within Wikka pages might be a nice extension. You probably know though that all the interface options can only be set by editing the source, or were you thinking of allowing some kind of admin access to the interface options? And be honest, are you thinking of phpMyEdit as a sort of replacement for my baby admin actions, aren't you?! In a sense this might be interesting, but it would really be unnecessary compared to what we can do by creating direct calls to the DB using core functions. Why heavily tweak an external script to do something wikka-like if we can already use something that only needs core functions? --- Moreover, when you perform operations on pages (like 'add', 'copy' or 'delete') you generally want to do something more complicated than just modify single records of the page table. Using phpMyEdit as a sort of proxy for a page admin action can lead to major inconsistencies in the page structure. --- And, JW, the "v" button is for filtering the table ;-) -- DarTar
~~~&Filtering? Well first it's not obvious, nor explained; but I just went back and tried pressing the "v" button - and I get three other mystifying buttons in return. Frankly, I don't want to use something as badly-designed as this. Shudder. DarTar, your Admin functions may need some refinement, but mystifying they are not. Let's stick with those, and build on them. Sorry, JsnX, but this doesn't get my vote. --JavaWoman
===Support for (Technorati) tags===
I think it might be interesting to provide Wikka support for (Technorati) "**tags**". "Tags" in this context are simple keywords that help identify and categorize web content, in particular blog posts. Such keywords coupled with a ping system can be used by remote servers to retrieve fresh content for specific topics. See for instance how technorati.com aggregates fresh information about [[http://www.technorati.com/tag/wiki wikis]] from a number of sources.
[[http://www.technorati.com/help/tags.html More information on Technorati tags]]
~&Seems like we need to update our RSS (feed) implementation first... --JavaWoman
===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
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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?
--GregorLindner
----
==Signature==
(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
----
== 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
----
== Create rewrite rules on install ==
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
== Image dimensions ==
The [[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
----
==Clearing ACLs==
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
----
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
== RSS options ==
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
----
== 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
----
== Language file ==
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
== 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
----
==Finally using CVS?==
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
==Stopping Spammers getting Google Juice==
//(moved to WikkaSpamFighting)//
----
==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
----
==Give control over HTML==
It would be nice to see a template engine in Wikka to give the users the full control over the HTML source. Smarty is always a good choice.
~& I would love to see Wikka adopt some type of template system. I think that its is sorely needed. Changing the look of Wikka requires tedious editing of php files, and alot of the time it is non-obvious where you need to go to edit such files. Another alternative to [[http://smarty.php.net Smarty]] could be [[http://wiki.ciaweb.net/yawiki/index.php?area=Savant Savant]]. --KickTheDonkey
~~&While I use and like Smarty very much (and it's quite fast), it's rather "heavy" for Wikka, I think. I just had a look at Savant2 which I hadn't heard of before. It looks like a good fit, is lightweight and easy to use. A templating system like this would also provide much more flexibility for Wikka admins to have control over page structure and layout. I'll want to play with it some (in combination with Wikka), but my first impression based on documentation and code is very favorable. More when I've had a chance to exercise it. --JavaWoman
----
==Allow spaces in pagetitle==
Allow Spaces in the document title and replace it later with "-" to optimize it for search engines.
----
==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
----
==Local links==
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--KickTheDonkey
----
==Idea for Category Support==
moved to CategorySystemOverhaul, it is the better place, thanks DarTar
--ArpY
~& ArpY, take a look at CategorySystemOverhaul for an open discussion on how to improve the category system -- DarTar
----
==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.
----
==Section Editing ==
- http://c2.com/cgi/wiki?SectionEditing
- It makes allows you to flow and edit much quicker.
- Each topic should have a corresponding edit button. This allows your to edit each section with out breaking your flow.
- http://www.splitbrain.org/dokuwiki/wiki:section_editing
----
==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
----
==Standard date and time format==
Although I'm all for using the ISO date/time format as we see in the timestamp of the footer of every page, I note that several other parts of Wikka use different date/time formats. I'd like to see an approach where this is standardized.
Proposal:
~-Define date-time format (or separately date and time, as well as a way to combine them) in the configuration; use the ISO format as a default (in the initial configuration, as well as when no format is defined in the config).
~-Use this format wherever date and/or time are formatted.
~-Make using the configured formats a requirement for every Wikka extension (that displays date/time information) to be included with the distribution.
I realize that in principle it's possible to pick up formats from a locale but for a Wikka targeted at an international audience this may not be the best approach, and for a Wikka with a "local" audience it may not be either if it's hosted on a (public) server outside that country - hence the idea to define a format in the configuration.
--JavaWoman
~''Agreed -- DarTar''
----
==Handling the config==
I have three questions about the config. See HandlingWikkaConfig.
--NilsLindenberg
''See also WikkaSecureConfig for a possible new appraoch. --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
----
==Online editing of mindmaps would be great==
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
----
==Tables ==
For the discussion on tables in Wikka, take a look at WikkaTables.
~&See also TableAction for a preliminary solution. --JavaWoman
----
==Wikka Exporting/Importing ==
Just added a few thoughts [[WikkaFilters here]]
-- DarTar
----
==how to format code to get two % characters without space together?==
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
----
==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
----
==showing comments==
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
----
==Language support==
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
----
== 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
----
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
----
== 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
----
==Using FPDF with Wikka==
Not so much a suggestion, more a request although it may be useful to others.
I have been using FPDF from [[http://www.fpdf.org FPDF ]] to export content from a database to pdf files.
I would like to extend my usage of FPDF to wikka by adding a hyperlink to the top of my wikka pages which would allow me to post the page tag or page id to the FPDF script for exporting the content into a pdf file.
The link would be in the form similar to
http://www.mysite.com/script.php?id=
Can anyone tell me how I can extract the page tag or page id from the wikka_pages table in order to do this.
----
====Resolved Suggestions====
== Question: PHP 4.3 and "mysql_escape_string()"? ==
For the Wikka Wakka Wiki 1.1.4.0 you need at least PHP 4.3 because the "mysql_real_escape_string()" in wakka.php is only available in PHP 4.3. A lot of hoster just offering PHP 4.1 or 4.2. Then you have to replace "mysql_real_escape_string()" with "mysql_escape_string()". What was the reason for the replacement in the new release? Again: Keep on the good work.
-- SkyWalk
~&The reason is that ##mysql_real_escape_string()## is more secure than ##mysql_escape_string()## so we want to take advantage of that; but as implemented this left users of older versions of PHP in the cold. A workaround for this will be in version 1.1.6.0 (see above) - now avaliable as a [[HomePage public beta]]. --JavaWoman
----
== Typo correction in embedded Wiki Edit 2 ==
For the new (1.1.6.0) release, line 645 of wikiedit2/wikiedit2.js should be fixed to say:
%% s += " Ctrl+Shift+Minus - Horizontal line\n";%%
not "horisontal." I've already fixed it in my local copy, but no sense in perpetuating errors. :) --MovieLady
~&Thanks to eagle-eyed JsnX it's //aready// fixed in 1.1.6.0 beta4 :) but thanks for the note! --JavaWoman
~~& Marvelous, thanks! :) --MovieLady
==Compatibility with PHP 4.1.x==
with Debian GNU/Linux 3.0 (woody) are installed PHP 4.1.2 and this version don't support "mysql_real_escape_string" function.
temporary fix on wikka.php head:
%%(php)
if ( ! function_exists("mysql_real_escape_string") )
{
function mysql_real_escape_string($string)
{
return mysql_escape_string($string);
}
}%%
~&This will be in version 1.1.6.0 - now avaliable as a [[HomePage public beta]]. --JavaWoman
==Don't let old pages get indexed==
//(moved to WikkaSpamFighting)//
==User page==
If someone registers as a new user and chooses a Wikiname, his wikinamepage is empty. I think it would be nice, if the page whould be created from the wiki, containing a text with perhaps a welcome, some (Wiki)rules and usefull pages (this text should be stored somewhere so that it could be customized from the WikiAdmin). The page should automatically belong to the category user. Regards, NilsLindenberg
==Non-breaking space in forced links==
Sometimes a forced link has a phrase as link description with spaces for readability but where these spaces should **not** cause wrapping in the middle of the string - in other words, the spaces really should be non-breaking spaces. Unfortunately, specifying ## ## will (unlike here) result in the entity becoming visible as an entity instead of as the character it encodes.
It should be possible to either specify ## ## where needed and have it result in the actual character (i.e., keep the actual entity rather than "escaping" it), or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
//**Note:** Actually, with the 1.1.6.0 beta version running on this site, this demonstrates how the new htmlspecialchars_unicode() function is indeed buggy - as I pointed out on WikkaDevelopment. The solution is presented [[WikkaDevelopment there]] now (look for **htmlspecialchars_unicode()**).//
--JavaWoman
==User Control==
Is there an easy way to not allow registration? I would like to have it so that I can control the registration process, not let just anyone sign-up.
--BooYa
... (Nils proposing a solution)
A nice contribution Nils. If you want to go further with fiddling with the code for registration, I've thought it would be useful if there was a feature that required a password from an administrator to be able to register so that if you were going to register you put in your user info (as now) and a password you've obtained from the admin that allows you to register....for instance, in this way a teacher could set up a wikki with registration "on" and send a note to all of the parents with the registration password so that they could register....outsiders couldn't register, only those with the registration key. Possibly a quite useful feature to many potential user groups. -- GmBowen
~Look at UserRegistration for the first version, or [[http://www.niehle.info/UserSettings try it]] --NilsLindenberg
----
==Cookies and logging out==
This issue issue moved to StayingLoggedIn!
==Page viewed counter==
It occurs to me that some kind of "counter" for how many times the wikipage has been viewed might be a useful "action" for somebody to be able to use...this way a page author would know how often somebody has gone to the page & this might help focus development (especially for those keeners that have multiple pages/projects). [and I agree with the contributor below....Wikkawiki is great software]
''I completed altering a script and modifying the wikka code for this.....go to GmBowenCounter for the php script and the necessary alterations'' --GmBowen
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
==Mod rewrite and a problem==
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough?
''Good catch. Adding the end slash should be fine. It will be added by default in the next Wikka release. -- Jsnx''
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. -- JockeAndersson
''Jocke, in the style sheet [wikka.css by default], add "text-decoration: none;" to the smallprint style. Or am I not understanding the problem? -- JsnX''
~~~.smallprint a {
~~~color: #987;
~~~text-decoration: none;
~~~}
It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
The reason the above addition to smallprint doesn't work is that the links are visited meaning the pseudo-class a:visited must be defined as well with "text-decoration: none" in it. There is no definition for a:visited in the css by default. Perhaps this should be added to Wikka's code? -- JockeAndersson
Sure, I'll add it. Just curious though, what web browser are you using? Internet Explorer does not show underlined links as you have described...at least not for me. -- JsnX
I'm currently using Mozilla Firefox, but I'm testing pages in IE as well. The underlines were only visible in Firefox. IE is usually the one to screw up page rendering, not being fully standards-compliant and all. Oh, and the code could use an a:active definition as well. Be sure to define them in correct order though: a visited hover active. W3C were specific about that for some reason. -- JockeAndersson
Thanks for the tip. By the way, your site looks awesome. -- JsnX
You really think so? Thanks!! :) Much of the general layout comes from A List Apart's site, but adapted to my needs. I've had a site running for a while but can't find the time to update it properly. I believe Wikka will change all that and am seriously thinking of replacing my ordinary site with a Wikka wiki. The forum will still be phpbb, but the site itself could really benefit from the pros of Wikka. I second [[MarkHissinkMuller MarkHissinkMullers]] suggestions for improvement. Especially the possibility to manage ACLs based on user groups as well as individual users, would be great. -- JockeAndersson
~& I tried to do something like this at ACLsWithUserGroups.
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action (LOL) if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}""). -- Mike Bowen
I use stylesheet for xml, I don't know anything about compatibility to validators :
Add this to, for example handler/page/revisions.xml.php:
%%(php)<?php
$xml = "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n";
$xml .= '<?xml-stylesheet href="' . $this->GetConfigValue("base_url") .'/css/xml.css" type="text/css"?' .">\n";
?>%%
Add a file named xml.css in css/, the content is like XmlStyleSheet
--DotMG
----
CategoryWikka
Deletions:
Feedback is welcomed and appreciated. Use the form or edit this page.
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
**See also:**
~-WikkaSpamFighting for spam-related issues
~-WikkaWorkarounds for specific platforms
~-WikkaOptimization
>>{{feedback}}::c::
===phpMyEdit in Wikka===
I've set up a demo of [[http://www.jsnx.com/wikka-dev/SuggestionBox phpMyEdit running within Wikka]]. This would be useful for anyone wanting to directly interact with MySQL tables from a Wikka page. -- JsnX
~&I assume this is meant for admins only but ... Could you add some explanation? I looked but don't have a clue how to use it. What are the radio buttons for, for instance? What's the "V" button at the top? The UI is very confusing. --JavaWoman
~~& Jsnx, that's interesting. I think the idea is worth consideration. I have used phpMyEdit as an interface to allow my users to store their profiles in the DB when I still was a MySQL newbie :) and it's true that it allows a number of tricky things (especially cross-reference between tables). So I think a plugin for integrating phpMyEdit within Wikka pages might be a nice extension. You probably know though that all the interface options can only be set by editing the source, or were you thinking of allowing some kind of admin access to the interface options? And be honest, are you thinking of phpMyEdit as a sort of replacement for my baby admin actions, aren't you?! In a sense this might be interesting, but it would really be unnecessary compared to what we can do by creating direct calls to the DB using core functions. Why heavily tweak an external script to do something wikka-like if we can already use something that only needs core functions? --- Moreover, when you perform operations on pages (like 'add', 'copy' or 'delete') you generally want to do something more complicated than just modify single records of the page table. Using phpMyEdit as a sort of proxy for a page admin action can lead to major inconsistencies in the page structure. --- And, JW, the "v" button is for filtering the table ;-) -- DarTar
===Support for (Technorati) tags===
I think it might be interesting to provide Wikka support for (Technorati) "**tags**". "Tags" in this context are simple keywords that help identify and categorize web content, in particular blog posts. Such keywords coupled with a ping system can be used by remote servers to retrieve fresh content for specific topics. See for instance how technorati.com aggregates fresh information about [[http://www.technorati.com/tag/wiki wikis]] from a number of sources.
[[http://www.technorati.com/help/tags.html More information on Technorati tags]]
~&Seems like we need to update our RSS (feed) implementation first... --JavaWoman
===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
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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?
--GregorLindner
----
==Signature==
(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
----
== 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
----
== Create rewrite rules on install ==
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
----
== Image dimensions ==
The [[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
----
==Clearing ACLs==
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
----
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
{
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
%%
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
%%
~&--NilsLindenberg
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
----
== RSS options ==
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
----
== 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
----
== Language file ==
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
----
== 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
----
==Finally using CVS?==
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
----
==Stopping Spammers getting Google Juice==
//(moved to WikkaSpamFighting)//
----
==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
----
==Give control over HTML==
It would be nice to see a template engine in Wikka to give the users the full control over the HTML source. Smarty is always a good choice.
~& I would love to see Wikka adopt some type of template system. I think that its is sorely needed. Changing the look of Wikka requires tedious editing of php files, and alot of the time it is non-obvious where you need to go to edit such files. Another alternative to [[http://smarty.php.net Smarty]] could be [[http://wiki.ciaweb.net/yawiki/index.php?area=Savant Savant]]. --KickTheDonkey
~~&While I use and like Smarty very much (and it's quite fast), it's rather "heavy" for Wikka, I think. I just had a look at Savant2 which I hadn't heard of before. It looks like a good fit, is lightweight and easy to use. A templating system like this would also provide much more flexibility for Wikka admins to have control over page structure and layout. I'll want to play with it some (in combination with Wikka), but my first impression based on documentation and code is very favorable. More when I've had a chance to exercise it. --JavaWoman
----
==Allow spaces in pagetitle==
Allow Spaces in the document title and replace it later with "-" to optimize it for search engines.
----
==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
----
==Local links==
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--KickTheDonkey
----
==Idea for Category Support==
moved to CategorySystemOverhaul, it is the better place, thanks DarTar
--ArpY
~& ArpY, take a look at CategorySystemOverhaul for an open discussion on how to improve the category system -- DarTar
----
==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.
----
==Section Editing ==
- http://c2.com/cgi/wiki?SectionEditing
- It makes allows you to flow and edit much quicker.
- Each topic should have a corresponding edit button. This allows your to edit each section with out breaking your flow.
- http://www.splitbrain.org/dokuwiki/wiki:section_editing
----
==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
----
==Standard date and time format==
Although I'm all for using the ISO date/time format as we see in the timestamp of the footer of every page, I note that several other parts of Wikka use different date/time formats. I'd like to see an approach where this is standardized.
Proposal:
~-Define date-time format (or separately date and time, as well as a way to combine them) in the configuration; use the ISO format as a default (in the initial configuration, as well as when no format is defined in the config).
~-Use this format wherever date and/or time are formatted.
~-Make using the configured formats a requirement for every Wikka extension (that displays date/time information) to be included with the distribution.
I realize that in principle it's possible to pick up formats from a locale but for a Wikka targeted at an international audience this may not be the best approach, and for a Wikka with a "local" audience it may not be either if it's hosted on a (public) server outside that country - hence the idea to define a format in the configuration.
--JavaWoman
~''Agreed -- DarTar''
----
==Handling the config==
I have three questions about the config. See HandlingWikkaConfig.
--NilsLindenberg
''See also WikkaSecureConfig for a possible new appraoch. --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
----
==Online editing of mindmaps would be great==
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
----
==Tables ==
For the discussion on tables in Wikka, take a look at WikkaTables.
~&See also TableAction for a preliminary solution. --JavaWoman
----
==Wikka Exporting/Importing ==
Just added a few thoughts [[WikkaFilters here]]
-- DarTar
----
==how to format code to get two % characters without space together?==
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Is there a solution? I could not find a literal entity for "percent"
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
----
==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
----
==showing comments==
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
----
==Language support==
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
----
== 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
----
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
-- SkyWalk
this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
----
== 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
----
==Using FPDF with Wikka==
Not so much a suggestion, more a request although it may be useful to others.
I have been using FPDF from [[http://www.fpdf.org FPDF ]] to export content from a database to pdf files.
I would like to extend my usage of FPDF to wikka by adding a hyperlink to the top of my wikka pages which would allow me to post the page tag or page id to the FPDF script for exporting the content into a pdf file.
The link would be in the form similar to
http://www.mysite.com/script.php?id=
Can anyone tell me how I can extract the page tag or page id from the wikka_pages table in order to do this.
----
====Resolved Suggestions====
== Question: PHP 4.3 and "mysql_escape_string()"? ==
For the Wikka Wakka Wiki 1.1.4.0 you need at least PHP 4.3 because the "mysql_real_escape_string()" in wakka.php is only available in PHP 4.3. A lot of hoster just offering PHP 4.1 or 4.2. Then you have to replace "mysql_real_escape_string()" with "mysql_escape_string()". What was the reason for the replacement in the new release? Again: Keep on the good work.
-- SkyWalk
~&The reason is that ##mysql_real_escape_string()## is more secure than ##mysql_escape_string()## so we want to take advantage of that; but as implemented this left users of older versions of PHP in the cold. A workaround for this will be in version 1.1.6.0 (see above) - now avaliable as a [[HomePage public beta]]. --JavaWoman
----
== Typo correction in embedded Wiki Edit 2 ==
For the new (1.1.6.0) release, line 645 of wikiedit2/wikiedit2.js should be fixed to say:
%% s += " Ctrl+Shift+Minus - Horizontal line\n";%%
not "horisontal." I've already fixed it in my local copy, but no sense in perpetuating errors. :) --MovieLady
~&Thanks to eagle-eyed JsnX it's //aready// fixed in 1.1.6.0 beta4 :) but thanks for the note! --JavaWoman
~~& Marvelous, thanks! :) --MovieLady
==Compatibility with PHP 4.1.x==
with Debian GNU/Linux 3.0 (woody) are installed PHP 4.1.2 and this version don't support "mysql_real_escape_string" function.
temporary fix on wikka.php head:
%%(php)
if ( ! function_exists("mysql_real_escape_string") )
{
function mysql_real_escape_string($string)
{
return mysql_escape_string($string);
}
}%%
~&This will be in version 1.1.6.0 - now avaliable as a [[HomePage public beta]]. --JavaWoman
==Don't let old pages get indexed==
//(moved to WikkaSpamFighting)//
==User page==
If someone registers as a new user and chooses a Wikiname, his wikinamepage is empty. I think it would be nice, if the page whould be created from the wiki, containing a text with perhaps a welcome, some (Wiki)rules and usefull pages (this text should be stored somewhere so that it could be customized from the WikiAdmin). The page should automatically belong to the category user. Regards, NilsLindenberg
==Non-breaking space in forced links==
Sometimes a forced link has a phrase as link description with spaces for readability but where these spaces should **not** cause wrapping in the middle of the string - in other words, the spaces really should be non-breaking spaces. Unfortunately, specifying ## ## will (unlike here) result in the entity becoming visible as an entity instead of as the character it encodes.
It should be possible to either specify ## ## where needed and have it result in the actual character (i.e., keep the actual entity rather than "escaping" it), or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
//**Note:** Actually, with the 1.1.6.0 beta version running on this site, this demonstrates how the new htmlspecialchars_unicode() function is indeed buggy - as I pointed out on WikkaDevelopment. The solution is presented [[WikkaDevelopment there]] now (look for **htmlspecialchars_unicode()**).//
--JavaWoman
==User Control==
Is there an easy way to not allow registration? I would like to have it so that I can control the registration process, not let just anyone sign-up.
--BooYa
... (Nils proposing a solution)
A nice contribution Nils. If you want to go further with fiddling with the code for registration, I've thought it would be useful if there was a feature that required a password from an administrator to be able to register so that if you were going to register you put in your user info (as now) and a password you've obtained from the admin that allows you to register....for instance, in this way a teacher could set up a wikki with registration "on" and send a note to all of the parents with the registration password so that they could register....outsiders couldn't register, only those with the registration key. Possibly a quite useful feature to many potential user groups. -- GmBowen
~Look at UserRegistration for the first version, or [[http://www.niehle.info/UserSettings try it]] --NilsLindenberg
----
==Cookies and logging out==
This issue issue moved to StayingLoggedIn!
==Page viewed counter==
It occurs to me that some kind of "counter" for how many times the wikipage has been viewed might be a useful "action" for somebody to be able to use...this way a page author would know how often somebody has gone to the page & this might help focus development (especially for those keeners that have multiple pages/projects). [and I agree with the contributor below....Wikkawiki is great software]
''I completed altering a script and modifying the wikka code for this.....go to GmBowenCounter for the php script and the necessary alterations'' --GmBowen
==Wikka markup inside tables==
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
==Mod rewrite and a problem==
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough?
''Good catch. Adding the end slash should be fine. It will be added by default in the next Wikka release. -- Jsnx''
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. -- JockeAndersson
''Jocke, in the style sheet [wikka.css by default], add "text-decoration: none;" to the smallprint style. Or am I not understanding the problem? -- JsnX''
~~~.smallprint a {
~~~color: #987;
~~~text-decoration: none;
~~~}
It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
The reason the above addition to smallprint doesn't work is that the links are visited meaning the pseudo-class a:visited must be defined as well with "text-decoration: none" in it. There is no definition for a:visited in the css by default. Perhaps this should be added to Wikka's code? -- JockeAndersson
Sure, I'll add it. Just curious though, what web browser are you using? Internet Explorer does not show underlined links as you have described...at least not for me. -- JsnX
I'm currently using Mozilla Firefox, but I'm testing pages in IE as well. The underlines were only visible in Firefox. IE is usually the one to screw up page rendering, not being fully standards-compliant and all. Oh, and the code could use an a:active definition as well. Be sure to define them in correct order though: a visited hover active. W3C were specific about that for some reason. -- JockeAndersson
Thanks for the tip. By the way, your site looks awesome. -- JsnX
You really think so? Thanks!! :) Much of the general layout comes from A List Apart's site, but adapted to my needs. I've had a site running for a while but can't find the time to update it properly. I believe Wikka will change all that and am seriously thinking of replacing my ordinary site with a Wikka wiki. The forum will still be phpbb, but the site itself could really benefit from the pros of Wikka. I second [[MarkHissinkMuller MarkHissinkMullers]] suggestions for improvement. Especially the possibility to manage ACLs based on user groups as well as individual users, would be great. -- JockeAndersson
~& I tried to do something like this at ACLsWithUserGroups.
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action (LOL) if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}""). -- Mike Bowen
I use stylesheet for xml, I don't know anything about compatibility to validators :
Add this to, for example handler/page/revisions.xml.php:
%%(php)<?php
$xml = "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n";
$xml .= '<?xml-stylesheet href="' . $this->GetConfigValue("base_url") .'/css/xml.css" type="text/css"?' .">\n";
?>%%
Add a file named xml.css in css/, the content is like XmlStyleSheet
--DotMG
----
CategoryWikka
Additions:
~~& Jsnx, that's interesting. I think the idea is worth consideration. I have used phpMyEdit as an interface to allow my users to store their profiles in the DB when I still was a MySQL newbie :) and it's true that it allows a number of tricky things (especially cross-reference between tables). So I think a plugin for integrating phpMyEdit within Wikka pages might be a nice extension. You probably know though that all the interface options can only be set by editing the source, or were you thinking of allowing some kind of admin access to the interface options? And be honest, are you thinking of phpMyEdit as a sort of replacement for my baby admin actions, aren't you?! In a sense this might be interesting, but it would really be unnecessary compared to what we can do by creating direct calls to the DB using core functions. Why heavily tweak an external script to do something wikka-like if we can already use something that only needs core functions? --- Moreover, when you perform operations on pages (like 'add', 'copy' or 'delete') you generally want to do something more complicated than just modify single records of the page table. Using phpMyEdit as a sort of proxy for a page admin action can lead to major inconsistencies in the page structure. --- And, JW, the "v" button is for filtering the table ;-) -- DarTar
Deletions:
Additions:
~~& Jsnx, that's interesting. I think the idea is worth consideration. I have used phpMyEdit as an interface to allow my users to store their profiles in the DB when I still was a MySQL newbie :) and it's true that it allows a number of tricky things (especially cross-reference between tables). So I think a plugin for integrating phpMyEdit within Wikka pages might be a nice extension. You probably know though that all the interface options can only be set by editing the source, or were you thinking of allowing some kind of admin access to the interface options? And be honest, are you thinking of phpMyEdit as a sort of replacement for my baby admin actions, aren't you?! In a sense this might be interesting, but it would really be unnecessary compared to what we can do by creating direct calls to the DB using core functions. Why heavily tweak an external script to do something wikka-like if we can already use something that only needs core functions? JW, the "v" button is for filtering the table ;-) -- DarTar
Deletions:
Additions:
~~& Jsnx, that's interesting. I think the idea is worth consideration. I have used phpMyEdit as an interface to allow my users to store their profiles in the DB when I still was a MySQL newbie :) and it's true that it allows a number of tricky things (especially cross-reference between tables). So I think a plugin for integrating phpMyEdit within Wikka pages might be a nice extension. You probably know though that all the interface options can only be set by editing the source, or were you thinking of allowing some kind of admin access to the interface options? JW, the "v" button is for filtering the table ;-) -- DarTar
Revision [5705]
Edited on 2005-02-06 22:39:20 by JavaWoman [comment on option to use Savant as templateing system]Additions:
~~&While I use and like Smarty very much (and it's quite fast), it's rather "heavy" for Wikka, I think. I just had a look at Savant2 which I hadn't heard of before. It looks like a good fit, is lightweight and easy to use. A templating system like this would also provide much more flexibility for Wikka admins to have control over page structure and layout. I'll want to play with it some (in combination with Wikka), but my first impression based on documentation and code is very favorable. More when I've had a chance to exercise it. --JavaWoman
Additions:
~&I assume this is meant for admins only but ... Could you add some explanation? I looked but don't have a clue how to use it. What are the radio buttons for, for instance? What's the "V" button at the top? The UI is very confusing. --JavaWoman
Deletions:
Additions:
~&I assuem this is meant for admins only but ... Could you add some explanation? I looked but don't have a clue how to use it. What are the radio buttons for, for instance? What's the "V" button at the top? The UI is very confusing. --JavaWoman
Revision [5702]
Edited on 2005-02-06 22:24:29 by JavaWoman [adding reference to HierarchiesAndInheritance]Additions:
See also HierarchiesAndInheritance for some background --JavaWoman
Additions:
===phpMyEdit in Wikka===
I've set up a demo of [[http://www.jsnx.com/wikka-dev/SuggestionBox phpMyEdit running within Wikka]]. This would be useful for anyone wanting to directly interact with MySQL tables from a Wikka page. -- JsnX
I've set up a demo of [[http://www.jsnx.com/wikka-dev/SuggestionBox phpMyEdit running within Wikka]]. This would be useful for anyone wanting to directly interact with MySQL tables from a Wikka page. -- JsnX
Additions:
~&Seems like we need to update our RSS (feed) implementation first... --JavaWoman
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Revision [5678]
Edited on 2005-02-06 11:54:27 by IanAndolina [+1 and more on why wikka formatter should use paragraphs]Additions:
+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
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
%%(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
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Revision [5673]
Edited on 2005-02-06 09:20:20 by JavaWoman [tags - slight clarification and comment]Additions:
===Support for (Technorati) tags===
I think it might be interesting to provide Wikka support for (Technorati) "**tags**". "Tags" in this context are simple keywords that help identify and categorize web content, in particular blog posts. Such keywords coupled with a ping system can be used by remote servers to retrieve fresh content for specific topics. See for instance how technorati.com aggregates fresh information about [[http://www.technorati.com/tag/wiki wikis]] from a number of sources.
[[http://www.technorati.com/help/tags.html More information on Technorati tags]]
~&Seems like we need to update our RSS (feed) implementation first...
I think it might be interesting to provide Wikka support for (Technorati) "**tags**". "Tags" in this context are simple keywords that help identify and categorize web content, in particular blog posts. Such keywords coupled with a ping system can be used by remote servers to retrieve fresh content for specific topics. See for instance how technorati.com aggregates fresh information about [[http://www.technorati.com/tag/wiki wikis]] from a number of sources.
[[http://www.technorati.com/help/tags.html More information on Technorati tags]]
~&Seems like we need to update our RSS (feed) implementation first...
Deletions:
I think it might be interesting to provide Wikka support for **tags**. Tags are simple keywords that help identify and categorize web content, in particular blog posts. Tags coupled with a ping system can be used by remote servers to retrieve fresh content for specific topics. See for instance how technorati.com aggregates fresh information about [[http://www.technorati.com/tag/wiki wikis]] from a number of sources.
[[http://www.technorati.com/help/tags.html More information on tags]]
Additions:
===Support for tags===
I think it might be interesting to provide Wikka support for **tags**. Tags are simple keywords that help identify and categorize web content, in particular blog posts. Tags coupled with a ping system can be used by remote servers to retrieve fresh content for specific topics. See for instance how technorati.com aggregates fresh information about [[http://www.technorati.com/tag/wiki wikis]] from a number of sources.
[[http://www.technorati.com/help/tags.html More information on tags]]
I think it might be interesting to provide Wikka support for **tags**. Tags are simple keywords that help identify and categorize web content, in particular blog posts. Tags coupled with a ping system can be used by remote servers to retrieve fresh content for specific topics. See for instance how technorati.com aggregates fresh information about [[http://www.technorati.com/tag/wiki wikis]] from a number of sources.
[[http://www.technorati.com/help/tags.html More information on tags]]
Additions:
~& I would love to see Wikka adopt some type of template system. I think that its is sorely needed. Changing the look of Wikka requires tedious editing of php files, and alot of the time it is non-obvious where you need to go to edit such files. Another alternative to [[http://smarty.php.net Smarty]] could be [[http://wiki.ciaweb.net/yawiki/index.php?area=Savant Savant]]. --KickTheDonkey
Deletions:
Additions:
~~& 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
Additions:
~~& Dartar, just saw your reply. Thanks for the hint! --JeroenJansen
Additions:
>>{{feedback}}::c::
Deletions:
Revision [5531]
Edited on 2005-02-03 16:13:07 by host217-42-192-144.range217-42.btcentralplus.com [answer to 'Inherit Acl from parents' GeorgePetsagourakis...]Additions:
~&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
~&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
Revision [5501]
Edited on 2005-02-02 19:43:04 by MovieLady [response to JW & CB re image dimensions]Additions:
~~~~& 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
~& That's great, Christian, thank you! --MovieLady
~& That's great, Christian, thank you! --MovieLady
Additions:
===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
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
Revision [5495]
Edited on 2005-02-02 14:59:21 by DarTar [Copying Scumble's suggestion on paragraphs]Additions:
~-WikkaWorkarounds for specific platforms
~-WikkaOptimization
===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
~-WikkaOptimization
===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
Deletions:
Revision [5471]
Edited on 2005-02-02 10:59:03 by NilsLindenberg [copied Ideas from WikkaDevelopment]Additions:
===Save Pages to PDF Format===
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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
(copied from WikkaDevelopment --Nils)
Page output to an Adobe pdf file using FPDF.
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
Additions:
~& Jeroen, there is a hack for automatically adding a user's signature in WakkaWiki posted by NickK on his [[http://wakkawiki.de/NickK homepage]]. It should be easy to adapt to Wikka. -- DarTar
Additions:
==="target=" in external links?===
Is there a way to include a target in a link, so that the Link opens in a new window?
--GregorLindner
Is there a way to include a target in a link, so that the Link opens in a new window?
--GregorLindner
No Differences
Additions:
==Signature==
(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
(copied from WikkaFaq, but perhaps better at WantedFormatters? --NilsLindenberg)
Does Wikka support automatic user signatures in pages (not comments)? I need some code so that users don't need to enter their username and time/date when they are working on a page in ThreadMode. I've searched in the docs, but I could not find anything about this, any ideas?
-- JeroenJansen (2005-01-28 11:35:43)
Revision [5295]
Edited on 2005-01-28 06:52:14 by ChristianBarthelemy [Want WIDTH & HEIGTH in the image action? Got it!]Additions:
Dear all: see my proposal at EnhancedImageAction
Revision [5269]
Edited on 2005-01-27 14:30:52 by 212.8.217.254 [Want WIDTH & HEIGTH in the image action? Got it!]Additions:
MatthewLangham
Revision [5268]
Edited on 2005-01-27 14:29:07 by 212.8.217.254 [Want WIDTH & HEIGTH in the image action? Got it!]Additions:
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.
The del.icio.us [[http://del.icio.us/doc/about page]] offers some user contributed hacks which may be a starting point.
Deletions:
The del.icio.us {{page http://del.icio.us/doc/about}} offers some user contributed hacks which may be a starting point.
Revision [5267]
Edited on 2005-01-27 14:27:24 by 212.8.217.254 [Want WIDTH & HEIGTH in the image action? Got it!]Additions:
== 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 JavaScriptlet 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 {{page http://del.icio.us/doc/about}} offers some user contributed hacks which may be a starting point.
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 JavaScriptlet 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 {{page http://del.icio.us/doc/about}} offers some user contributed hacks which may be a starting point.
Additions:
== Create rewrite rules on install ==
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
~//copied from comment on WikkaInstallation --JavaWoman//
Since I installed wikka in a subdirectory under the domain root I needed to add the following to the .htaccess file just under """RewriteEngine on""":
""RewriteBase"" /subdirectory/
Devs, how about writing the .htaccess rules at the same time you write out the wikka.config.php file since you automatically pickup the wiki base location at that point?
-kt
-- KarmaTester (2005-01-26 06:52:07)
Revision [5253]
Edited on 2005-01-26 21:48:01 by JavaWoman [ref. to WikkaOptimization moved here from WikkaBugs]Additions:
**See also:**
~-WikkaSpamFighting for spam-related issues
~-a new page dedicated for optimization : WikkaOptimization (???)
~-WikkaSpamFighting for spam-related issues
~-a new page dedicated for optimization : WikkaOptimization (???)
Deletions:
Additions:
== Question: PHP 4.3 and "mysql_escape_string()"? ==
... (Nils proposing a solution)
... (Nils proposing a solution)
Deletions:
... (Nils propsing a solution)
Additions:
~&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
~~&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
Deletions:
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
Additions:
~&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
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
Deletions:
Revision [5233]
Edited on 2005-01-26 18:51:46 by NilsLindenberg [moved some suggestions to Resolved Suggestions]Additions:
==Compatibility & Installer==
- Compatibility-problem is solved now, text moved below to Resolved Suggestions->Compatibility with PHP 4.1.x) --NilsLindenberg
- Compatibility-problem is solved now, text moved below to Resolved Suggestions->Compatibility with PHP 4.1.x) --NilsLindenberg
Additions:
~&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
Revision [5218]
Edited on 2005-01-26 08:49:44 by 66.194.unused-addr.ncport.ru [reply re: Image dimensions]Deletions:
Additions:
The [[AddingImages image]] action really needs the ability to specify image height and width. :) --MovieLady
Deletions:
Additions:
== Image dimensions ==
The ""{{image}}"" action really needs the ability to specify image height and width. :) --MovieLady
The ""{{image}}"" action really needs the ability to specify image height and width. :) --MovieLady
Additions:
~~& LOL I can imagine. Thanks so much for this - I'll try it out this evening. --MovieLady
~~~~~& Fabulous! I'll check it out. --MovieLady
~~~~~& Fabulous! I'll check it out. --MovieLady
Additions:
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will keep many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
Deletions:
Additions:
~~~~&Yes, "Captcha" is an old trick - it will keep out some bots (but not all) and it will many people out, too, like those who are visually handicapped (not just people who are totally blind - being colorblind may be enough to be defeated by such tricks). Add a sound equivalent? Well, there are people who are deaf **and** blind. Are we going to deny them access to our wikis? I'm not in favor of making Wikka **in**accessible when we should be working towards making it **more** accessible. --JavaWoman.
Revision [5133]
Edited on 2005-01-24 19:23:59 by GmBowen [making registration more difficult for spam bots....image verification examples]Additions:
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here]] and [[http://www.horobey.com/demos/codegen/ here]] are examples of what I mean (I like the simplicity of the first version in the second example). -- GmBowen
Deletions:
Revision [5132]
Edited on 2005-01-24 19:18:34 by GmBowen [suggestion for making registration bots' lives more miserable]Additions:
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. [[http://www.bluecopia.com/form.php Here's]] an example of what I mean. -- GmBowen
Deletions:
Revision [5130]
Edited on 2005-01-24 18:40:00 by GmBowen [suggestions for obfuscating registration further for spam bots]Additions:
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. If I see links to that code around I'll post it. -- GmBowen
~~~&there's also code around that uses GD & that could be built onto Nils' code that generates a "registration password" automatically and outputs it as a distorted graphic image.....the code is intended to befuddle auto spam registers & thus stop open-registration sites from being hit by spam bots that register themselves as users. Ultimately, as the bots become more sophisticated I think we'll have to use something like that or else sites like this one (with open registration) will be victimized. If I see links to that code around I'll post it. -- GmBowen
Deletions:
Additions:
~&You know how many TestUsers my Wikka already has? *g* This should do the job (this time no config option, sorry jw :)
~&%%(php)
function ExistsEmail($email)
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
~&--NilsLindenberg
~&%%(php)
function ExistsEmail($email)
$count = 0;
$query = "SELECT COUNT(email)
FROM ".$this->config['table_prefix']."users
WHERE email='".mysql_real_escape_string($email)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
~&Place this function in wikka.php right after function UserWantsComments(). And change in actions/usersettings.php the following line: %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
%% to %%(php)
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
~&--NilsLindenberg
Additions:
~~~~&Thank you. About your Admin-adding-user case: that's an addition to UserAdmin, not for usersettings. --NilsLindenberg
Additions:
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
~~& (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~~~& Doh! I somehow missed that. That's pretty much what I had in mind. Nice job, Nils! :) -- JsnX
Deletions:
Additions:
~~~~& 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
Deletions:
Additions:
~~~~& See AutomaticUserPageCreation for a first version. --NilsLindenberg
Revision [5050]
Edited on 2005-01-24 10:31:43 by JavaWoman [moving spam-related issues to WikkaSpamFighting]Additions:
**See also** WikkaSpamFighting for spam-related issues
//(moved to WikkaSpamFighting)//
//(moved to WikkaSpamFighting)//
//(moved to WikkaSpamFighting)//
//(moved to WikkaSpamFighting)//
Deletions:
~&Good point, Ian. I had thought about this, after having seen several Wikis and blogs that use the Google redirection... I do think it should be configurable though - not every Wiki installation may want to do this (in fact, some may welcome external links as long as spam is repaired fast enough). --JavaWoman
~~&I asked an export for SEO and he replied that it should be enough to use a simple internal redirect (e.g. exit.php?url=...) to create this effect. He also said that it might be helpful to disallow any spider access to that file (robots.txt). -- ReimerStegelmann
~~~&Unfortunately, search engine robots these days mostly **do** follow URLs with parameters, and an "internal redirect" done that way would be retrieved by a bot; HTTP redirects are followed, too (which is what you'd have to use with that "internal redirect" method). **Meta** redirects mostly aren't but you cannot apply this as a general "redirect external links" (especially not since you cannot have any URL parameters in a meta redirect - and you want to allow all //valid// external links, merely have them not count towards page rank in search engines, mostly Google). Excluding a single file with robots.txt won't work since all of Wikka runs off the single wikka.php file. The Google redirect method gets around all of that (at least for Google's ranking mechanism - which is what spammers are mostly targeting). --JavaWoman
~~~~&They follow, but that is not the point of spam. The main target of a spammer is the reach a high ranking in search engines. They post links which linktext contains important keywords (e.g. [[Keyword1 keyword2 http://domain.tld]]). So, if you enter keyword1 oder keyword2 to a search engine, you will see the homepage of the spammer. By using a simple redirect, spiders will follow the link, but they give a fuck about the keywords and so the spammer gives a fuck about the link.
~~~~~&Exactly - and using the Google redirect **prevents** the target page from getting a higher ranking from incoming (spam) links because it won't be counted at all. :) --JavaWoman
~~~~~~&Yeah, but you don't need Google to make this happen. A simple internal redirect is enough and looks better than a Google-Redirect ;)
~~~~~~~&Nope, because an internal redirect //will// be followed by Google and //still// count for page rank - that's the problem; the Google redirect prevents this. --JavaWoman
~~~~~~~~&I talked to Abakus, a German SEO expert and he said it does not count. There is no difference between an internal redirect oder a Google redirect. Keywords of the link (s. above) only count for the redirect site and not for link behind the redirect. And well, why should a spider follow an internal link (via exit.php?url=...), but not a Google redirect?
~~~~~~~~~& A spider will follow any redirect, whether it's local or through an internal redirect. Never mind the keywords, it's still a link //into// the spammed site; with a local redirect that won't make any difference, but with the Google redirect Google knows to **not** count it as an incoming link. It's not (just) about keywords but about **Page Rank** (PR) - and PR is highly dependent on incoming links (and where they come from). That much we know. But no one except some Google employees knows the exact algorithm that determines PR - not even Abakus ;-) --JavaWoman
~&Maybe the solution is [[http://www.google.com/googleblog/2005/01/preventing-comment-spam.html here]].
~&If a user is not registered, to all external links he creates on the wiki will be added the attribute rel="nofollow".
~&This technique is now adopted by Google, Yahoo and MSN. --DotMG
~~&Thanks, DotMG! This is great news - I had seen this technique being discussed as a proposed possible solution but had missed the news the proposal has actually been adopted now. (Should we worry about Altavista? Probably not too much - these SEs are the ones spammers will target primarily.) One possible hole I can see is that a spammer might write a script to quickly register and then post on a number of pages - but scripted registrations can be defended against with other means. Nothing will probably provide a 100% solution but this is a big step in the right direction. --JavaWoman
To make absolutely sure old pages don't get archived (irrespective of your robots.txt) - essential to stopping WikiSpam from still getting juice from archived pages, why not make sure to add meta directives to those pages by adding something like:
<?php if ($this->GetMethod() != 'show' || $this->page["latest"] == "N") echo "<meta name=\"robots\" content=\"noindex, nofollow, noarchive\" />\n<meta name=\"googlebot\" content=\"noarchive, noindex, nofollow\">\n";?>%%
to header.php. This stops pages with handlers other than show or non current pages from any kind of archiving/cacheing.
~&Ian, thanks for the suggestion. Wikka has had something similar to this in place since the first release. See Mod033bRobotIndexing. But your suggestion expands the idea and adds the latest page check, "noarchive", and the googlebot part--which seem like good ideas. I'll add this to the upcoming release. By the way, when are you going to switch your site over to Wikka? ;) -- JsnX
~~&Yes, nice idea. But the googlebot part is actually redundant, Google obeys the robots meta directives. (And that second meta tag isn't valid XHTML - it's unclosed.) I suggest we merely add the "noarchive". Apart from that, it would also be nice to stop indexing etc. from the SandBox page. --JavaWoman
~~~&The latest page check is important because wiki spammers don't really care if you delete their spam, as long as their links sit on an old archived page waiting to be indexed. The added googlebot directive (thanks for spotting typo btw) is just **extra paranoia on my part** :). And you are all doing an **excellent** job with Wikka - the only reason I haven't switched is that quite a lot on my Wakka is heavily customised and I don't have the time to redo that - especially as lots of pages would break without re-jigging of e.g. SafeHTML (my BookMarklets page for example). If I have time, I will eventually migrate...! -- IanAndolina
~&Both the "noarchive" addition and applying it to the Sandbox as well as old pages will be in Wikka version 1.1.6.0 - as you can see in the [[HomePage public beta]]! --JavaWoman
Additions:
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX (you saw UserRegistration by Nils? I think it, or something like it, should be standard. mike)
Deletions:
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
Additions:
==Clearing ACLs==
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
There should be a button on the ACL page to "Reset ACLs to Default". What this would do is delete the record for the current page from the acls table. There is a distinction between setting the ACLs to the sites default values and not having ACLs defined for a page. If the ACLs are set and the default values get changed, the page will remain at the set values. However, if no ACLs are defined, the page will always use the default values.
To help show the distinction, there should be a visual indicator on the ACL handler page which states whether the page has ACLs defined or is using the site's default values. Basically, just check for a record in the acls table for the current page, and display a message accordingly. -- JsnX
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack. -- JsnX
Deletions:
Additions:
~& Speaking of registration control, note to self: make a configuration option to turn off new account registrations. Some sites might be private and not want people registering. Admin privilege should override this and still show the registration fields in usersettings, to save the admin from having to go into the database manually to add acounts or some other hack.
Additions:
== User registration control ==
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~~~~~& Ah well, I'll keep working on trying to figure out a way to do it. *g* Thanks! :) --MovieLady
It would nice to have the registration function check to make sure there isn't another account with the same email already registered so that one person doesn't clutter up the db with multiple accounts. (Or at least the configurable option to check for only one email/one account.)
It should also then be easier (I would think) to use it to essentially ban by email address; if the registration process checked for an email in the user table, found that it was already in use and didn't let the person create a new username, one could use the wonderful ACLsWithUserGroups hack that Christian created to make a list of banned users by username. Yeah, yeah, folks who want to abuse the system could always create new email addresses on the various free sites, but that's an awful lot of work, and this would at least slow down some of it. --MovieLady
~~~~~& Ah well, I'll keep working on trying to figure out a way to do it. *g* Thanks! :) --MovieLady
Revision [4945]
Edited on 2005-01-22 13:51:34 by ChristianBarthelemy [No magic in IncludeAction sorry :-(]Additions:
~& I am doing this using the IncludeAction - at least you only update one page (TheNews). --ChristianBarthelemy
~~~~& Nope. I just only keep the news updated in TheNews page so that the whole page is displayed when included. --ChristianBarthelemy
~~~~& Nope. I just only keep the news updated in TheNews page so that the whole page is displayed when included. --ChristianBarthelemy
Deletions:
Additions:
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" could show only the headlines and the update field (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --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
~~~& 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
Deletions:
Revision [4932]
Edited on 2005-01-22 00:40:59 by MovieLady [(another *g*) suggestion & answer to Christian]Additions:
== RSS options ==
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" would show only the headlines and update note (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
~~& Thanks, I'll try that out. --MovieLady
It would be wonderful to be able to choose what kind of RSS feed is created for a page. For example, ""{{rss}}""/""{{rss show="1"}}"" would show only the headlines and update note (current setting), ""{{rss show="2"}}"" could show a blurb of the updated info, ""{{rss show="3"}}"" could show the whole update. --MovieLady
~~& Thanks, I'll try that out. --MovieLady
Additions:
~& I am doing this using the IncludeAction - at leat you only update one page (TheNews).
Additions:
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
~~& Marvelous, thanks! :) --MovieLady
~~& Marvelous, thanks! :) --MovieLady
Deletions:
Additions:
==Mod rewrite and a problem==
Deletions:
Additions:
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}}""?) on the main page that displays only the most recent (configurable) number (e.g. ""{{news show="2"}}"" would show the last 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 [[http://dir.aithine.org/Home front page]] and the [[http://dir.aithine.org/News 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
Deletions:
Additions:
== 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}}""?) on the main page that displays only the most recent (configurable) number (e.g. ""{{news show=2}}"" would show the last 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 [[http://dir.aithine.org/Home front page]] and the [[http://dir.aithine.org/News 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 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}}""?) on the main page that displays only the most recent (configurable) number (e.g. ""{{news show=2}}"" would show the last 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 [[http://dir.aithine.org/Home front page]] and the [[http://dir.aithine.org/News 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
Additions:
==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
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
Additions:
~&Noted - good suggestion. --JavaWoman
~&Thanks to eagle-eyed JsnX it's //aready// fixed in 1.1.6.0 beta4 :) but thanks for the note! --JavaWoman
~&Thanks to eagle-eyed JsnX it's //aready// fixed in 1.1.6.0 beta4 :) but thanks for the note! --JavaWoman
Additions:
~& 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
Deletions:
Additions:
== 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
== Typo correction in embedded Wiki Edit 2 ==
For the new (1.1.6.0) release, line 645 of wikiedit2/wikiedit2.js should be fixed to say:
%% s += " Ctrl+Shift+Minus - Horizontal line\n";%%
not "horisontal." I've already fixed it in my local copy, but no sense in perpetuating errors. :) --MovieLady
~~~& Excellent point, hadn't thought about that. :) --MovieLady
~& 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. But that's certainly not the only place that must check 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
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
== Typo correction in embedded Wiki Edit 2 ==
For the new (1.1.6.0) release, line 645 of wikiedit2/wikiedit2.js should be fixed to say:
%% s += " Ctrl+Shift+Minus - Horizontal line\n";%%
not "horisontal." I've already fixed it in my local copy, but no sense in perpetuating errors. :) --MovieLady
~~~& Excellent point, hadn't thought about that. :) --MovieLady
~& 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. But that's certainly not the only place that must check 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
Revision [4878]
Edited on 2005-01-19 20:55:01 by JavaWoman [replies re: mysql_[real_]escape_string()]Additions:
~&This will be in version 1.1.6.0 - now avaliable as a [[HomePage public beta]]. --JavaWoman
~&The reason is that ##mysql_real_escape_string()## is more secure than ##mysql_escape_string()## so we want to take advantage of that; but as implemented this left users of older versions of PHP in the cold. A workaround for this will be in version 1.1.6.0 (see above) - now avaliable as a [[HomePage public beta]]. --JavaWoman
~&The reason is that ##mysql_real_escape_string()## is more secure than ##mysql_escape_string()## so we want to take advantage of that; but as implemented this left users of older versions of PHP in the cold. A workaround for this will be in version 1.1.6.0 (see above) - now avaliable as a [[HomePage public beta]]. --JavaWoman
Additions:
~~~~~&Mike, I for one would welcome your insights in using CVS. Both DarTar and I have some ideas about how we want it set up - but no experience in doing so (in CVS). May I suggest you join our [[http://lists.sourceforge.net/lists/listinfo/wikka-developers developers mailing list]]? For this type of thing I think that would be the best medium to discuss thoughs and methods. I like the idea of a commit mailing list. --JavaWoman
Additions:
~~&The most flexible and powerful way to support i18n is still Gettext which is supported by PHP. If we go in that direction (likely), manually creating a "language file" is needless work since Gettext does all that automatically for you. And it supports options for handling plurals and such which simple string-to-string language files cannot handle. The problem is that code needs to be written in a way to properly be able to use Gettext, so that translatable strings **do** contain whole phrases with punctuation and **do not** contain any HTML markup (actually this is true for simple laguage files as well). Currently our code is not "in shape" for i18n though, so that's the first job we'll have to tackle. --JavaWoman
Additions:
~& 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
~~&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
Deletions:
Additions:
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [[http://xcomic.sourceforge.net Xcomic]] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
Deletions:
Deletions:
%%php
%%php
Additions:
I actually hacked UserSettings.php to allow for non-wikinames. Just change lines such as 152 and 179 from:
%%php
if (!$this->IsWikiName($name)) $error = "User name must be WikiName formatted!";
to something like:
%%php
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:
%%php
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!
%%php
if (!$this->IsWikiName($name)) $error = "User name must be WikiName formatted!";
to something like:
%%php
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:
%%php
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!
Additions:
~~~~& Hi Nils. Actually, I did find Wikka's CVS repository at SF weeks ago, but I forgot to mention it in my above post. JavaWoman pretty much echoed my thoughts. We need to actively use CVS/update it constantly as changes are made. I run a project called [http://xcomic.sourceforge.net Xcomic] that uses Sourceforge's CVS a lot, so I have some experience with that. In addition, I recently set something up for my project that I think will be pretty cool if Wikka decides to really use CVS: a commit mailing list. Anytime someone makes a change to the CVS (modification, addition, or deletion), an automatically generated email will be sent to anyone on the suscribers list detailing the files changed and the areas changed (a diff). In any case, version 1.1.6.0-beta4 should be committed and access should be given to a few main developers. Then smaller contributors (like me) can send code changes to the main developers who subsequently commit. --MikeXstudios
Additions:
~&Look at DotMgs approach at WikkaInternationalization. But at least it should work for languages in the range of the "normal" (ascii?) code. If you are interested, you should start a page in where we can collected the hard-coded sentences (would wait for the .6 relase, anyway). --NilsLindenberg
~& 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
~& 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
Additions:
~~~& The "just was meant as an addition to existing ("Of course" would have been better, though :). I just wanted to point out the existing (or better non-existing ;) usage of sourceforge, in case Mike does not no. It is obviously to me that you have to integrate it into your development-process, otherwise it would not be out of date (*duck & run* ;) --NilsLindenberg
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Additions:
== Language file ==
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
I would be nice to see all phrases put into a single file. This would allow to translate the wiki in a few hours without changes every single file.
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Additions:
== 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.
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
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.
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
Additions:
~~&Actually, Nils, we need a lot more than "just updating" the CVS at Sourceforge. We need to integrate CVS in our development process - and develop a process for doing so. That requires a bit of planning... :) And while at least some of us have experience with source control systems, at the same time some of us **don't** have experience with CVS specifically, so a bit of study will be required before we can start planning. Help with learning how to use CVS //well// from someone who has experience with it would certainly be welcome, Mike! Thanks for the offer. --JavaWoman ''(reading manuals....)''
Additions:
~&There is a cvs version of wikka at [[http://sourceforge.net/projects/wikka/ sourceforge]]. Just has to be updated --NilsLindenberg
Revision [4836]
Edited on 2005-01-19 13:30:32 by JavaWoman [news about stopping indexing old pages etc.]Additions:
~&Both the "noarchive" addition and applying it to the Sandbox as well as old pages will be in Wikka version 1.1.6.0 - as you can see in the [[HomePage public beta]]! --JavaWoman
Additions:
~&Maybe the solution is [[http://www.google.com/googleblog/2005/01/preventing-comment-spam.html here]].
~&If a user is not registered, to all external links he creates on the wiki will be added the attribute rel="nofollow".
~&This technique is now adopted by Google, Yahoo and MSN. --DotMG
~~&Thanks, DotMG! This is great news - I had seen this technique being discussed as a proposed possible solution but had missed the news the proposal has actually been adopted now. (Should we worry about Altavista? Probably not too much - these SEs are the ones spammers will target primarily.) One possible hole I can see is that a spammer might write a script to quickly register and then post on a number of pages - but scripted registrations can be defended against with other means. Nothing will probably provide a 100% solution but this is a big step in the right direction. --JavaWoman
~&If a user is not registered, to all external links he creates on the wiki will be added the attribute rel="nofollow".
~&This technique is now adopted by Google, Yahoo and MSN. --DotMG
~~&Thanks, DotMG! This is great news - I had seen this technique being discussed as a proposed possible solution but had missed the news the proposal has actually been adopted now. (Should we worry about Altavista? Probably not too much - these SEs are the ones spammers will target primarily.) One possible hole I can see is that a spammer might write a script to quickly register and then post on a number of pages - but scripted registrations can be defended against with other means. Nothing will probably provide a 100% solution but this is a big step in the right direction. --JavaWoman
Deletions:
If a user is not registered, to all external links he creates on the wiki will be added the attribute rel="nofollow".
This technique is now adopted by Google, Yahoo and MSN.
Additions:
Maybe the solution is [[http://www.google.com/googleblog/2005/01/preventing-comment-spam.html here]].
If a user is not registered, to all external links he creates on the wiki will be added the attribute rel="nofollow".
This technique is now adopted by Google, Yahoo and MSN.
If a user is not registered, to all external links he creates on the wiki will be added the attribute rel="nofollow".
This technique is now adopted by Google, Yahoo and MSN.
Revision [4823]
Edited on 2005-01-19 02:53:21 by MikeXstudios [How Google suggests to stop spam links ...]Additions:
==Finally using CVS?==
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
I apologize since this idea has been suggested before, and I believe the developers are working to implement it already. However, with the beta of 1.1.6.0 released, I think it would be a good time now to start using CVS. This allows for better collaboration and as each bug fix or feature is implemented, developers and testers can grab new copies and work out further bugs. In addition, this allows more outsiders to participate in the code development process and not wait as long from the transition of releases.
Also, I am willing to help with the CVS migration process if needed and help anyone who is interested in learning how to use CVS.
-- MikeXstudios
Additions:
~~~~~~~~~& A spider will follow any redirect, whether it's local or through an internal redirect. Never mind the keywords, it's still a link //into// the spammed site; with a local redirect that won't make any difference, but with the Google redirect Google knows to **not** count it as an incoming link. It's not (just) about keywords but about **Page Rank** (PR) - and PR is highly dependent on incoming links (and where they come from). That much we know. But no one except some Google employees knows the exact algorithm that determines PR - not even Abakus ;-) --JavaWoman
Deletions:
Additions:
~~~~~~~&Nope, because an internal redirect //will// be followed by Google and //still// count for page rank - that's the problem; the Google redirect prevents this. --JavaWoman
~~~~~~~~~& A spider will follow any redirect, wether it's local or through an internal redirect. Never mind the keywords, it's still a link *into* the spammed site; with a local redirect that won't make any difference, but with the Google redirect Google knows to **not** count it as an incoming link. It's not (just) about keywords but about **Page Rank** (PR) - and PR is highly dependent on incoming links (and where they come from). That much we know. But no one except some Google employees knows the exact algorithm that determines PR - not even Abakus ;-) --JavaWoman
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
~~~~~~~~~& A spider will follow any redirect, wether it's local or through an internal redirect. Never mind the keywords, it's still a link *into* the spammed site; with a local redirect that won't make any difference, but with the Google redirect Google knows to **not** count it as an incoming link. It's not (just) about keywords but about **Page Rank** (PR) - and PR is highly dependent on incoming links (and where they come from). That much we know. But no one except some Google employees knows the exact algorithm that determines PR - not even Abakus ;-) --JavaWoman
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
JavaWoman
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Additions:
~~~~~~~&Nope, because an internal redirect //will// be followed by Google and //still// count for page rank - that's the problem; the Google redirect prevents this. --
JavaWoman
~~~~~~~~&I talked to Abakus, a German SEO expert and he said it does not count. There is no difference between an internal redirect oder a Google redirect. Keywords of the link (s. above) only count for the redirect site and not for link behind the redirect. And well, why should a spider follow an internal link (via exit.php?url=...), but not a Google redirect?
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
JavaWoman
~~~~~~~~&I talked to Abakus, a German SEO expert and he said it does not count. There is no difference between an internal redirect oder a Google redirect. Keywords of the link (s. above) only count for the redirect site and not for link behind the redirect. And well, why should a spider follow an internal link (via exit.php?url=...), but not a Google redirect?
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Additions:
~~~~~~~&Nope, because an internal redirect //will// be followed by Google and //still// count for page rank - that's the problem; the Google redirect prevents this. --JavaWoman
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Additions:
~~~~~~&Yeah, but you don't need Google to make this happen. A simple internal redirect is enough and looks better than a Google-Redirect ;)
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Additions:
~~~~~&Exactly - and using the Google redirect **prevents** the target page from getting a higher ranking from incoming (spam) links because it won't be counted at all. :) --JavaWoman
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Revision [4801]
Edited on 2005-01-18 13:00:44 by ReimerStegelmann [Replay: Stopping Spammers getting Google Juice]Additions:
~~~~&They follow, but that is not the point of spam. The main target of a spammer is the reach a high ranking in search engines. They post links which linktext contains important keywords (e.g. [[Keyword1 keyword2 http://domain.tld]]). So, if you enter keyword1 oder keyword2 to a search engine, you will see the homepage of the spammer. By using a simple redirect, spiders will follow the link, but they give a fuck about the keywords and so the spammer gives a fuck about the link.
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Additions:
~~~&Unfortunately, search engine robots these days mostly **do** follow URLs with parameters, and an "internal redirect" done that way would be retrieved by a bot; HTTP redirects are followed, too (which is what you'd have to use with that "internal redirect" method). **Meta** redirects mostly aren't but you cannot apply this as a general "redirect external links" (especially not since you cannot have any URL parameters in a meta redirect - and you want to allow all //valid// external links, merely have them not count towards page rank in search engines, mostly Google). Excluding a single file with robots.txt won't work since all of Wikka runs off the single wikka.php file. The Google redirect method gets around all of that (at least for Google's ranking mechanism - which is what spammers are mostly targeting). --JavaWoman
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Additions:
~~&I asked an export for SEO and he replied that it should be enough to use a simple internal redirect (e.g. exit.php?url=...) to create this effect. He also said that it might be helpful to disallow any spider access to that file (robots.txt). -- ReimerStegelmann
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Revision [4784]
Edited on 2005-01-17 18:34:32 by JavaWoman [adding a sig (minor) and reply about redirection suggestion]Additions:
[[http://simon.incutio.com/archive/2004/05/11/approved There is a technique]] to stop spammers from gaining any advantage of spamming, which is to redirect external links to stop them from affecting their PageRank. Great to stop the whole purpose of spamming, but this has the disadvantage that good sites lose their google juice too. Check the comments out on that page for more cons. I've noticed since I enabled this on the Opera 7 wiki that slowly spam volume has dropped out, but I'm not entirely happy at the price paid. Had you thought about this, maybe have it as an option during config? -- IanAndolina
~&Good point, Ian. I had thought about this, after having seen several Wikis and blogs that use the Google redirection... I do think it should be configurable though - not every Wiki installation may want to do this (in fact, some may welcome external links as long as spam is repaired fast enough). --JavaWoman
~&Good point, Ian. I had thought about this, after having seen several Wikis and blogs that use the Google redirection... I do think it should be configurable though - not every Wiki installation may want to do this (in fact, some may welcome external links as long as spam is repaired fast enough). --JavaWoman
Deletions:
No Differences
Additions:
~~&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
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Revision [4721]
Edited on 2005-01-17 12:35:32 by 81.168.101.105 [reply to JsnX and JavaWoman and new suggestion on external link redirection]Additions:
==Stopping Spammers getting Google Juice==
[[http://simon.incutio.com/archive/2004/05/11/approved There is a technique]] to stop spammers from gaining any advantage of spamming, which is to redirect external links to stop them from affecting their PageRank. Great to stop the whole purpose of spamming, but this has the disadvantage that good sites lose their google juice too. Check the comments out on that page for more cons. I've noticed since I enabled this on the Opera 7 wiki that slowly spam volume has dropped out, but I'm not entirely happy at the price paid. Had you thought about this, maybe have it as an option during config?
~~&Yes, nice idea. But the googlebot part is actually redundant, Google obeys the robots meta directives. (And that second meta tag isn't valid XHTML - it's unclosed.) I suggest we merely add the "noarchive". Apart from that, it would also be nice to stop indexing etc. from the SandBox page. --JavaWoman
~~~&The latest page check is important because wiki spammers don't really care if you delete their spam, as long as their links sit on an old archived page waiting to be indexed. The added googlebot directive (thanks for spotting typo btw) is just **extra paranoia on my part** :). And you are all doing an **excellent** job with Wikka - the only reason I haven't switched is that quite a lot on my Wakka is heavily customised and I don't have the time to redo that - especially as lots of pages would break without re-jigging of e.g. SafeHTML (my BookMarklets page for example). If I have time, I will eventually migrate...! -- IanAndolina
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
[[http://simon.incutio.com/archive/2004/05/11/approved There is a technique]] to stop spammers from gaining any advantage of spamming, which is to redirect external links to stop them from affecting their PageRank. Great to stop the whole purpose of spamming, but this has the disadvantage that good sites lose their google juice too. Check the comments out on that page for more cons. I've noticed since I enabled this on the Opera 7 wiki that slowly spam volume has dropped out, but I'm not entirely happy at the price paid. Had you thought about this, maybe have it as an option during config?
~~&Yes, nice idea. But the googlebot part is actually redundant, Google obeys the robots meta directives. (And that second meta tag isn't valid XHTML - it's unclosed.) I suggest we merely add the "noarchive". Apart from that, it would also be nice to stop indexing etc. from the SandBox page. --JavaWoman
~~~&The latest page check is important because wiki spammers don't really care if you delete their spam, as long as their links sit on an old archived page waiting to be indexed. The added googlebot directive (thanks for spotting typo btw) is just **extra paranoia on my part** :). And you are all doing an **excellent** job with Wikka - the only reason I haven't switched is that quite a lot on my Wakka is heavily customised and I don't have the time to redo that - especially as lots of pages would break without re-jigging of e.g. SafeHTML (my BookMarklets page for example). If I have time, I will eventually migrate...! -- IanAndolina
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Additions:
~&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
Additions:
~&Ian, thanks for the suggestion. Wikka has had something similar to this in place since the first release. See Mod033bRobotIndexing. But your suggestion expands the idea and adds the latest page check, "noarchive", and the googlebot part--which seem like good ideas. I'll add this to the upcoming release. By the way, when are you going to switch your site over to Wikka? ;) -- JsnX
~&Yes, nice idea. But the googlebot part is actually redundant, Google obeys the robots meta directives. (And that second meta tag isn't valid XHTML - it's unclosed.) I suggest we merely add the "noarchive". Apart from that, it would also be nice to stop indexing etc. from the SandBox page. --JavaWoman
~&Yes, nice idea. But the googlebot part is actually redundant, Google obeys the robots meta directives. (And that second meta tag isn't valid XHTML - it's unclosed.) I suggest we merely add the "noarchive". Apart from that, it would also be nice to stop indexing etc. from the SandBox page. --JavaWoman
Deletions:
Additions:
Ian, thanks for the suggestion. Wikka has had something similar to this in place since the first release. See Mod033bRobotIndexing. But your suggestion expands the idea and adds the latest page check, "noarchive", and the googlebot part--which seem like good ideas. I'll add this to the upcoming release. By the way, when are you going to switch your site over to Wikka? ;) -- JsnX
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Revision [4703]
Edited on 2005-01-17 00:09:29 by IanAndolina [idea to stop wiki spam milking archived pages]Additions:
==Don't let old pages get indexed==
To make absolutely sure old pages don't get archived (irrespective of your robots.txt) - essential to stopping WikiSpam from still getting juice from archived pages, why not make sure to add meta directives to those pages by adding something like:
<?php if ($this->GetMethod() != 'show' || $this->page["latest"] == "N") echo "<meta name=\"robots\" content=\"noindex, nofollow, noarchive\" />\n<meta name=\"googlebot\" content=\"noarchive, noindex, nofollow\">\n";?>%%
to header.php. This stops pages with handlers other than show or non current pages from any kind of archiving/cacheing.
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
To make absolutely sure old pages don't get archived (irrespective of your robots.txt) - essential to stopping WikiSpam from still getting juice from archived pages, why not make sure to add meta directives to those pages by adding something like:
<?php if ($this->GetMethod() != 'show' || $this->page["latest"] == "N") echo "<meta name=\"robots\" content=\"noindex, nofollow, noarchive\" />\n<meta name=\"googlebot\" content=\"noarchive, noindex, nofollow\">\n";?>%%
to header.php. This stops pages with handlers other than show or non current pages from any kind of archiving/cacheing.
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Revision [4691]
Edited on 2005-01-16 20:14:29 by JsnX [Removing Redirect request, implemented in 1.1.6.0]Deletions:
These are the default functions inside the //wikka.php//.
%%(php) function SetMessage($message) { $_SESSION["message"] = $message; }
function Redirect($url) { header("Location: $url"); exit; %%
I propose intergrating the Wakka::SetMessage($msg) function inside the Wakka::Redirect($msg) like the code below, it seems to be more efficient when composing actions. This will effectively discart the $this->SetMessage(...); $this->Redirect(...); classic occurancies ...
%%(php) function Redirect($url='', $message ='')
if ($message !== '') $_SESSION["message"] = $message;
$url = ($url == '' ) ? $this->Href() : $url;
header("Location: $url");
exit;
}%%
--GeorgePetsagourakis
Additions:
A complete reference list of all the special actions (e.g. ""{{nocomments}}"", ""{{Category}}"", etc.) would be really nice. --MovieLady
Deletions:
Additions:
==List of special actions?==
A complete reference list of all the special actions (e.g. ""{{nocomments}}"", ""{{Category}}"", etc. would be really nice. --MovieLady
A complete reference list of all the special actions (e.g. ""{{nocomments}}"", ""{{Category}}"", etc. would be really nice. --MovieLady
Revision [4596]
Edited on 2005-01-13 15:18:22 by JavaWoman ["Wikka markup inside tables": reference to TableAction (+ layout)]Additions:
~&Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
==Various suggestions==
==Other method to attach files==
~&Check out my proposal for an extended TableAction which does provide this. (TableAction is intended as a preliminary solution until we have table markup.) --JavaWoman
==Various suggestions==
==Other method to attach files==
Deletions:
Additions:
~& I would love to see Wikka adopt some type of template system. I think that its is sorely needed. Changing the look of Wikka requires tedious editing of php files, and alot of the time it is non-obvious where you need to go to edit such files. Another alternative to [[http://smarty.php.net Smarty]] could be [[http://http://wiki.ciaweb.net/yawiki/index.php?area=Savant Savant]]. --KickTheDonkey
Revision [4572]
Edited on 2005-01-12 23:54:52 by dsl-082-083-127-236.arcor-ip.net [added savant suggestion]Additions:
==Give control over HTML==
It would be nice to see a template engine in Wikka to give the users the full control over the HTML source. Smarty is always a good choice.
==Allow spaces in pagetitle==
Allow Spaces in the document title and replace it later with "-" to optimize it for search engines.
It would be nice to see a template engine in Wikka to give the users the full control over the HTML source. Smarty is always a good choice.
==Allow spaces in pagetitle==
Allow Spaces in the document title and replace it later with "-" to optimize it for search engines.
Additions:
... (Nils propsing a solution)
==Cookies and logging out==
This issue issue moved to StayingLoggedIn!
~&See also TableAction for a preliminary solution. --JavaWoman
==Page viewed counter==
==Code block formatting==
==Wikka markup inside tables==
==Installation problem - UTF-8?==
==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.
~- 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.
~& 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
==Using FPDF with Wikka==
==Cookies and logging out==
This issue issue moved to StayingLoggedIn!
~&See also TableAction for a preliminary solution. --JavaWoman
==Page viewed counter==
==Code block formatting==
==Wikka markup inside tables==
==Installation problem - UTF-8?==
==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.
~- 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.
~& 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
==Using FPDF with Wikka==
Deletions:
The issue about cookies and logging-out moved to StayingLoggedIn!
- 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.
- 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.
- 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
====Using FPDF with Wikka====
Revision [4528]
Edited on 2005-01-12 15:30:49 by JavaWoman [new suggestions moved to the top + added headings]Additions:
==User-defined formatting rules==
-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.
==Local links==
-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.
==Local links==
Deletions:
Revision [4524]
Edited on 2005-01-12 14:55:39 by NilsLindenberg [two section edit suggestions "merged"]Additions:
==Section Editing ==
- http://c2.com/cgi/wiki?SectionEditing
- It makes allows you to flow and edit much quicker.
- Each topic should have a corresponding edit button. This allows your to edit each section with out breaking your flow.
- http://www.splitbrain.org/dokuwiki/wiki:section_editing
- http://c2.com/cgi/wiki?SectionEditing
- It makes allows you to flow and edit much quicker.
- Each topic should have a corresponding edit button. This allows your to edit each section with out breaking your flow.
- http://www.splitbrain.org/dokuwiki/wiki:section_editing
Deletions:
http://c2.com/cgi/wiki?SectionEditing
It makes allows you to flow and edit much quicker.
==Section Editing==
Each topic should have a corresponding edit button. This allows your to edit each section with out breaking your flow.
http://www.splitbrain.org/dokuwiki/wiki:section_editing
Revision [4521]
Edited on 2005-01-12 14:04:42 by KickTheDonkey [two section edit suggestions "merged"]Additions:
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.
-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.
Additions:
- 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
Additions:
It would be nice if a link to the same host as the wikka install was not flagged as 'external'. I've added a 'hack' to my personal page: KickTheDonkey. Works fine here.
--KickTheDonkey
--KickTheDonkey
Additions:
moved to CategorySystemOverhaul, it is the better place, thanks DarTar
Deletions:
add the Categorie to the URL in front of the wiki name:
Example:
mod_rewrite url: http://www.example.com/Categorie-Wikiname (I left out Camelcase here for easier formatting)
real url: http://www.example.com/wikka.php?categorie=Categorie&wakka=Wikiname
Implementation:
Whenever a page is called with a categorie override the configs base_url with the url including the the categorie (+ minus sign when using mod_rewrite) . The browser will translate all urls on this page to the url including the current category.
Whenever you want to set a link to a different category use InterWiki links - or something simliar to distingish between Category and InterWiki links.
**Advantages:**
Whenever a new page is created by clicking on AnonExisting page, the new page will inherit in the category from the linking page.
I thinks it is easy to implement - did this already partially on my page.
**Disadvantages:**
A page can only exist in one single Category.
Additions:
~& ArpY, take a look at CategorySystemOverhaul for an open discussion on how to improve the category system -- DarTar
Additions:
==Idea for Category Support==
The Category Support is currently not perfect. Here is my suggestion:
add the Categorie to the URL in front of the wiki name:
Example:
mod_rewrite url: http://www.example.com/Categorie-Wikiname (I left out Camelcase here for easier formatting)
real url: http://www.example.com/wikka.php?categorie=Categorie&wakka=Wikiname
Implementation:
Whenever a page is called with a categorie override the configs base_url with the url including the the categorie (+ minus sign when using mod_rewrite) . The browser will translate all urls on this page to the url including the current category.
Whenever you want to set a link to a different category use InterWiki links - or something simliar to distingish between Category and InterWiki links.
**Advantages:**
Whenever a new page is created by clicking on AnonExisting page, the new page will inherit in the category from the linking page.
I thinks it is easy to implement - did this already partially on my page.
**Disadvantages:**
A page can only exist in one single Category.
--ArpY
The Category Support is currently not perfect. Here is my suggestion:
add the Categorie to the URL in front of the wiki name:
Example:
mod_rewrite url: http://www.example.com/Categorie-Wikiname (I left out Camelcase here for easier formatting)
real url: http://www.example.com/wikka.php?categorie=Categorie&wakka=Wikiname
Implementation:
Whenever a page is called with a categorie override the configs base_url with the url including the the categorie (+ minus sign when using mod_rewrite) . The browser will translate all urls on this page to the url including the current category.
Whenever you want to set a link to a different category use InterWiki links - or something simliar to distingish between Category and InterWiki links.
**Advantages:**
Whenever a new page is created by clicking on AnonExisting page, the new page will inherit in the category from the linking page.
I thinks it is easy to implement - did this already partially on my page.
**Disadvantages:**
A page can only exist in one single Category.
--ArpY
Revision [4097]
Edited on 2005-01-06 19:49:31 by ChristianBarthelemy [Comments on Group management through ACLs]Additions:
~& I tried to do something with ACLsWithUserGroups.
~& I tried to do something like this at ACLsWithUserGroups.
~& I tried to do something like this at ACLsWithUserGroups.
Deletions:
~& I tried to do sort of group management in the ACLs: check GroupManagement under "Another approach".
Revision [4081]
Edited on 2005-01-06 17:25:04 by ChristianBarthelemy [Comments on Group management through ACLs]Additions:
~& I tried to do something alike: check GroupManagement under "Another approach".
~& I tried to do sort of group management in the ACLs: check GroupManagement under "Another approach".
~& I tried to do sort of group management in the ACLs: check GroupManagement under "Another approach".
Additions:
==Improving $this->Redirect()==
These are the default functions inside the //wikka.php//.
%%(php) function SetMessage($message) { $_SESSION["message"] = $message; }
function Redirect($url) { header("Location: $url"); exit; %%
I propose intergrating the Wakka::SetMessage($msg) function inside the Wakka::Redirect($msg) like the code below, it seems to be more efficient when composing actions. This will effectively discart the $this->SetMessage(...); $this->Redirect(...); classic occurancies ...
%%(php) function Redirect($url='', $message ='')
if ($message !== '') $_SESSION["message"] = $message;
$url = ($url == '' ) ? $this->Href() : $url;
header("Location: $url");
exit;
}%%
--GeorgePetsagourakis
These are the default functions inside the //wikka.php//.
%%(php) function SetMessage($message) { $_SESSION["message"] = $message; }
function Redirect($url) { header("Location: $url"); exit; %%
I propose intergrating the Wakka::SetMessage($msg) function inside the Wakka::Redirect($msg) like the code below, it seems to be more efficient when composing actions. This will effectively discart the $this->SetMessage(...); $this->Redirect(...); classic occurancies ...
%%(php) function Redirect($url='', $message ='')
if ($message !== '') $_SESSION["message"] = $message;
$url = ($url == '' ) ? $this->Href() : $url;
header("Location: $url");
exit;
}%%
--GeorgePetsagourakis
Revision [3903]
Edited on 2005-01-02 23:24:31 by JavaWoman [layout (order) and request for adding header for new entries]Additions:
**Please help to keep this page readable: add new entries at the //top// (right below the form) and add a header!**
==Compile Category action==
==Section Editing ?==
==Compile Category action==
==Section Editing ?==
Deletions:
---
Section Editing ?
------
Additions:
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.
Revision [3868]
Edited on 2004-12-31 19:46:03 by S0106000d888febf5.vf.shawcable.net [suggestion for an action for an admin]Additions:
---
Section Editing ?
http://c2.com/cgi/wiki?SectionEditing
It makes allows you to flow and edit much quicker.
------
Section Editing ?
http://c2.com/cgi/wiki?SectionEditing
It makes allows you to flow and edit much quicker.
------
Additions:
==Compatibility with PHP 4.1.x==
//(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)//
with Debian GNU/Linux 3.0 (woody) are installed PHP 4.1.2 and this version don't support "mysql_real_escape_string" function.
temporary fix on wikka.php head:
%%(php)
if ( ! function_exists("mysql_real_escape_string") )
function mysql_real_escape_string($string)
{
return mysql_escape_string($string);
}
}%%
IMPORTANT: installer uses TOO MUCH "@" before all mysql calls...
-- 213-140-6-98.fastres.net
==Section Editing==
//(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)//
with Debian GNU/Linux 3.0 (woody) are installed PHP 4.1.2 and this version don't support "mysql_real_escape_string" function.
temporary fix on wikka.php head:
%%(php)
if ( ! function_exists("mysql_real_escape_string") )
function mysql_real_escape_string($string)
{
return mysql_escape_string($string);
}
}%%
IMPORTANT: installer uses TOO MUCH "@" before all mysql calls...
-- 213-140-6-98.fastres.net
==Section Editing==
Deletions:
Additions:
...
~Look at UserRegistration for the first version, or [[http://www.niehle.info/UserSettings try it]] --NilsLindenberg
~Look at UserRegistration for the first version, or [[http://www.niehle.info/UserSettings try it]] --NilsLindenberg
Deletions:
Ok, the following code let you allow or deny registration, based on a line added to ##wikka.config.php##:
%%(php)
'allow_registration' => 'Y',
any other value than Y won't show up the fields necessary for registration. So you have to add users to the database manually!
change in ##actions/usersettings.php##:
%%(php)
<tr>
<td align="right"></td>
<td width="500"><?php echo $this->Format("Stuff you only need to fill in when you're logging in for the first time (and thus signing up as a new user on this site)."); ?></td>
</tr>
<tr>
<td align="right">Confirm password:</td>
<td><input type="password" name="confpassword" size="40" /></td>
</tr>
<tr>
<td align="right">Email address:</td>
<td><input name="email" size="40" value="<?php if (isset($email)) echo $email; ?>" /></td>
</tr>
<tr>
<td></td>
<td><input type="submit" value="Register" size="40" /></td>
</tr>
to
%%(php)
<?php
$register = $this->GetConfigValue('allow_registration');
if ($register == 'Y')
{
echo '<tr><td align="right"></td><td width="500">Stuff you only need to fill in when you are logging in for the first time (and thus signing up as a new user on this site)</td></tr>';
print("<tr><td align='right'>Confirm password:</td><td><input type='password' name='confpassword' size='40' /></td></tr>\n");
print("<tr><td align='right'>Email address:</td><td><input name='email' size='40' value='$email' /></td></tr>\n");
print("<tr><td></td><td><input type='submit' value='Register' size='40' /></td></tr> \n");
}
?>
''probably not necessary'': and (add the line after the comment)
%%(php)
// is user trying to log in or register?
$register = $this->GetConfigValue('allow_registration');
''probably not necessary'': and change
%%(php)
// otherwise, create new account
else
to
%%(php)
// otherwise, create new account
elseif ($register == 'Y')
Any comments (especially on security) are welcome. --NilsLindenberg
The first changes hide the fields in which a user has to confirm the password and put in the e-mail-adress and the register-button. The last two changes are another check before inserting an account in the db. ''shouldn't be necessary'', just enhanced security ;-) --NilsLindenberg
~It took me longer then expected, so I won't post the code here today, needs a little bit clean-up first. But you can test it at http://www.niehle.info/UserSettings. The register-code is helloWorld . Merry Christmas :-) --NilsLindenberg
Additions:
~It took me longer then expected, so I won't post the code here today, needs a little bit clean-up first. But you can test it at http://www.niehle.info/UserSettings. The register-code is helloWorld . Merry Christmas :-) --NilsLindenberg
Revision [3638]
Edited on 2004-12-24 12:09:37 by JavaWoman [new entry to top plus request to do that!]Additions:
**Please add new entries at the //top// (below the form).**
==Section Editng==
==Section Editng==
Deletions:
Revision [3636]
Edited on 2004-12-24 04:56:04 by S0106000d888febf5.vf.shawcable.net [new entry to top plus request to do that!]Additions:
====Section Editng====
Deletions:
Revision [3635]
Edited on 2004-12-24 04:55:36 by S0106000d888febf5.vf.shawcable.net [new entry to top plus request to do that!]Additions:
====SectionEditng====
Each topic should have a corresponding edit button. This allows your to edit each section with out breaking your flow.
http://www.splitbrain.org/dokuwiki/wiki:section_editing
Each topic should have a corresponding edit button. This allows your to edit each section with out breaking your flow.
http://www.splitbrain.org/dokuwiki/wiki:section_editing
Revision [3633]
Edited on 2004-12-24 03:42:20 by GmBowen [further suggestion on user registration (nice contribution Nils!)]Additions:
A nice contribution Nils. If you want to go further with fiddling with the code for registration, I've thought it would be useful if there was a feature that required a password from an administrator to be able to register so that if you were going to register you put in your user info (as now) and a password you've obtained from the admin that allows you to register....for instance, in this way a teacher could set up a wikki with registration "on" and send a note to all of the parents with the registration password so that they could register....outsiders couldn't register, only those with the registration key. Possibly a quite useful feature to many potential user groups. -- GmBowen
Additions:
''probably not necessary'': and (add the line after the comment)
// is user trying to log in or register?
$register = $this->GetConfigValue('allow_registration');
''probably not necessary'': and change
// otherwise, create new account
else
// otherwise, create new account
elseif ($register == 'Y')
The first changes hide the fields in which a user has to confirm the password and put in the e-mail-adress and the register-button. The last two changes are another check before inserting an account in the db. ''shouldn't be necessary'', just enhanced security ;-) --NilsLindenberg
// is user trying to log in or register?
$register = $this->GetConfigValue('allow_registration');
''probably not necessary'': and change
// otherwise, create new account
else
// otherwise, create new account
elseif ($register == 'Y')
The first changes hide the fields in which a user has to confirm the password and put in the e-mail-adress and the register-button. The last two changes are another check before inserting an account in the db. ''shouldn't be necessary'', just enhanced security ;-) --NilsLindenberg
Additions:
Ok, the following code let you allow or deny registration, based on a line added to ##wikka.config.php##:
%%(php)
'allow_registration' => 'Y',
any other value than Y won't show up the fields necessary for registration. So you have to add users to the database manually!
change in ##actions/usersettings.php##:
%%(php)
<tr>
<td align="right"></td>
<td width="500"><?php echo $this->Format("Stuff you only need to fill in when you're logging in for the first time (and thus signing up as a new user on this site)."); ?></td>
</tr>
<tr>
<td align="right">Confirm password:</td>
<td><input type="password" name="confpassword" size="40" /></td>
</tr>
<tr>
<td align="right">Email address:</td>
<td><input name="email" size="40" value="<?php if (isset($email)) echo $email; ?>" /></td>
</tr>
<tr>
<td></td>
<td><input type="submit" value="Register" size="40" /></td>
</tr>
to
%%(php)
<?php
$register = $this->GetConfigValue('allow_registration');
if ($register == 'Y')
{
echo '<tr><td align="right"></td><td width="500">Stuff you only need to fill in when you are logging in for the first time (and thus signing up as a new user on this site)</td></tr>';
print("<tr><td align='right'>Confirm password:</td><td><input type='password' name='confpassword' size='40' /></td></tr>\n");
print("<tr><td align='right'>Email address:</td><td><input name='email' size='40' value='$email' /></td></tr>\n");
print("<tr><td></td><td><input type='submit' value='Register' size='40' /></td></tr> \n");
}
?>
Any comments (especially on security) are welcome. --NilsLindenberg
%%(php)
'allow_registration' => 'Y',
any other value than Y won't show up the fields necessary for registration. So you have to add users to the database manually!
change in ##actions/usersettings.php##:
%%(php)
<tr>
<td align="right"></td>
<td width="500"><?php echo $this->Format("Stuff you only need to fill in when you're logging in for the first time (and thus signing up as a new user on this site)."); ?></td>
</tr>
<tr>
<td align="right">Confirm password:</td>
<td><input type="password" name="confpassword" size="40" /></td>
</tr>
<tr>
<td align="right">Email address:</td>
<td><input name="email" size="40" value="<?php if (isset($email)) echo $email; ?>" /></td>
</tr>
<tr>
<td></td>
<td><input type="submit" value="Register" size="40" /></td>
</tr>
to
%%(php)
<?php
$register = $this->GetConfigValue('allow_registration');
if ($register == 'Y')
{
echo '<tr><td align="right"></td><td width="500">Stuff you only need to fill in when you are logging in for the first time (and thus signing up as a new user on this site)</td></tr>';
print("<tr><td align='right'>Confirm password:</td><td><input type='password' name='confpassword' size='40' /></td></tr>\n");
print("<tr><td align='right'>Email address:</td><td><input name='email' size='40' value='$email' /></td></tr>\n");
print("<tr><td></td><td><input type='submit' value='Register' size='40' /></td></tr> \n");
}
?>
Any comments (especially on security) are welcome. --NilsLindenberg
Revision [3534]
Edited on 2004-12-20 15:01:55 by JavaWoman [ypot in reference to htmlspecialchars solution]Additions:
//**Note:** Actually, with the 1.1.6.0 beta version running on this site, this demonstrates how the new htmlspecialchars_unicode() function is indeed buggy - as I pointed out on WikkaDevelopment. The solution is presented [[WikkaDevelopment there]] now (look for **htmlspecialchars_unicode()**).//
Deletions:
Revision [3533]
Edited on 2004-12-20 15:00:47 by JavaWoman [reference to solution for htmlspecialchars]Additions:
//**Note:** Actually, with the 1.1.6.0 beta version running on this site, this demonstrates how the new htmlspecialchars_unicode() function is indeed buggy - as I pointed out on WikkaDevelopment. The solution is resented [[WikkaDevelopment there]] now (look for **htmlspecialchars_unicode()**).//
Deletions:
Additions:
I'm working on a solution. --NilsLindenberg
Revision [3526]
Edited on 2004-12-20 11:18:15 by JavaWoman [adding note to Non-breaking space in forced links]Additions:
//**Note:** Actually, with a 1.1.6.0 beta version running on this site, this demonstrates how the new htmlspecialchars_unicode() function is indeed buggy - as I pointed out on WikkaDevelopment. I'll come up with a replacement function soon.//
Revision [3512]
Edited on 2004-12-20 06:07:00 by JavaWoman [edit in Non-breaking space in forced links]Additions:
It should be possible to either specify ## ## where needed and have it result in the actual character (i.e., keep the actual entity rather than "escaping" it), or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
Deletions:
Revision [3511]
Edited on 2004-12-20 06:04:48 by JavaWoman [ypot in Non-breaking space in forced links]Additions:
It should be possible to either specify ## ## where needed and have it result in the actual character, or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
Deletions:
Revision [3510]
Edited on 2004-12-20 05:26:34 by JavaWoman [adding Non-breaking space in forced links]Additions:
==Non-breaking space in forced links==
Sometimes a forced link has a phrase as link description with spaces for readability but where these spaces should **not** cause wrapping in the middle of the string - in other words, the spaces really should be non-breaking spaces. Unfortunately, specifying ## ## will (unlike here) result in the entity becoming visible as an entity instead of as the character it encodes.
I should be possible to either specify ## ## where needed and have it result in the actual character, or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
Sometimes a forced link has a phrase as link description with spaces for readability but where these spaces should **not** cause wrapping in the middle of the string - in other words, the spaces really should be non-breaking spaces. Unfortunately, specifying ## ## will (unlike here) result in the entity becoming visible as an entity instead of as the character it encodes.
I should be possible to either specify ## ## where needed and have it result in the actual character, or (less desirable) there should be another mechanism to indicate where link text should not be broken. It can't be automatic since non-breaking may not be desirable at every point either.
Additions:
=====Suggestion Box=====
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
>>{{feedback}}
>>=== Bugs vs. feature suggestions ===
Please post issues/bugs to the appropriate page:
>>{{feedback}}
Deletions:
{{feedback}}
=== Bugs vs. feature suggestions ===
<<Please post issues/bugs to the appropriate page:
<<::c::
Revision [3468]
Edited on 2004-12-19 15:15:25 by DarTar [Standard & configurable date format: good idea]Additions:
{{lastedit}}
~''Agreed -- DarTar''
~''Agreed -- DarTar''
Additions:
==Standard date and time format==
Although I'm all for using the ISO date/time format as we see in the timestamp of the footer of every page, I note that several other parts of Wikka use different date/time formats. I'd like to see an approach where this is standardized.
Proposal:
~-Define date-time format (or separately date and time, as well as a way to combine them) in the configuration; use the ISO format as a default (in the initial configuration, as well as when no format is defined in the config).
~-Use this format wherever date and/or time are formatted.
~-Make using the configured formats a requirement for every Wikka extension (that displays date/time information) to be included with the distribution.
I realize that in principle it's possible to pick up formats from a locale but for a Wikka targeted at an international audience this may not be the best approach, and for a Wikka with a "local" audience it may not be either if it's hosted on a (public) server outside that country - hence the idea to define a format in the configuration.
--JavaWoman
==User Control==
Although I'm all for using the ISO date/time format as we see in the timestamp of the footer of every page, I note that several other parts of Wikka use different date/time formats. I'd like to see an approach where this is standardized.
Proposal:
~-Define date-time format (or separately date and time, as well as a way to combine them) in the configuration; use the ISO format as a default (in the initial configuration, as well as when no format is defined in the config).
~-Use this format wherever date and/or time are formatted.
~-Make using the configured formats a requirement for every Wikka extension (that displays date/time information) to be included with the distribution.
I realize that in principle it's possible to pick up formats from a locale but for a Wikka targeted at an international audience this may not be the best approach, and for a Wikka with a "local" audience it may not be either if it's hosted on a (public) server outside that country - hence the idea to define a format in the configuration.
--JavaWoman
==User Control==
Deletions:
Revision [3456]
Edited on 2004-12-18 21:49:55 by JavaWoman [attribution added for User Control feature]Additions:
--BooYa
Revision [3454]
Edited on 2004-12-18 21:47:18 by JavaWoman [User Control moved here from WikkaBugs (not-a-bug)]Additions:
====User Control====
Is there an easy way to not allow registration? I would like to have it so that I can control the registration process, not let just anyone sign-up.
Is there an easy way to not allow registration? I would like to have it so that I can control the registration process, not let just anyone sign-up.
Additions:
''See also WikkaSecureConfig for a possible new appraoch. --JavaWoman''
Deletions:
Revision [3318]
Edited on 2004-12-16 15:58:22 by NilsLindenberg [moves cookies around *you want one?*]Additions:
The issue about cookies and logging-out moved to StayingLoggedIn!
Deletions:
The log-in information is stored in a cookie which expires after 90 days. This is quite comfortable but could be a security risk, if you forget to logout in a i-net caffè ort on a pc used by many people.
To be loged-out when you close the browser, change in ##wikka.php##
%%(php)
function SetUser($user) { $_SESSION["user"] = $user; $this->SetPersistentCookie("name", $user["name"]); $this->SetPersistentCookie("password", $user["password"]); }
to
%%(php)
function SetUser($user) { $_SESSION["user"] = $user; $this->SetSessionCookie("name", $user["name"]); $this->SetSessionCookie("password", $user["password"]); }
Perhaps that should be the default and the user should have an "always loged-in" setting?
NilsLindenberg
''This is much more secure yet I think that this should be the user decision to keep the cookie or not through the UserSettings: maybe another field in the wikka_users table?
--ChristianBarthelemy''
''I agree - it's quite common to give a (registered) user a choice between a session cookie and a permanent cookie; such a choice should of course be stored in the user profile in the database. For unregistered visitors only session cookies should be used. --JavaWoman''
- unregistered users need no cookie, because they neither have a username nor a password. :-) NilsLindenberg
I stuck some piece of code together. I know that stay_loged_in is a very uncreative name (loged-in with one or two g?), and the code needs someone to look over it. I am for example not sure if an enum in the table would be better. But to my great astonishment, it seems to work. :) --NilsLindenberg
1) adding field to user table:
SQL-query:
ALTER TABLE `wikka_users` ADD `stay_loged_in` TINYINT DEFAULT '0' NOT NULL ;
%%
2)adding a to show the status of the variable (to ##actions/usersettings.php## after the block with ""<td align="right">Page revisions list limit:</td>""):
%%(html)
<tr>
<td align="right">Stay loged-in:</td>
<td><input name="stay_loged_in" value="<?php echo htmlspecialchars($user["stay_loged_in"]) ?>" size="40" /></td>
</tr>
3) added the user-table-update in ##actions/usersettings.php##:
change:
%%(php)
$this->Query("update ".$this->config["table_prefix"]."users set ".
"email = '".mysql_real_escape_string($_POST["email"])."', ".
"doubleclickedit = '".mysql_real_escape_string($_POST["doubleclickedit"])."', ".
"show_comments = '".mysql_real_escape_string($_POST["show_comments"])."', ".
"revisioncount = '".mysql_real_escape_string($_POST["revisioncount"])."', ".
"changescount = '".mysql_real_escape_string($_POST["changescount"])."' ".
"where name = '".$user["name"]."' limit 1");
to
%%(php)
$this->Query("update ".$this->config["table_prefix"]."users set ".
"email = '".mysql_real_escape_string($_POST["email"])."', ".
"doubleclickedit = '".mysql_real_escape_string($_POST["doubleclickedit"])."', ".
"show_comments = '".mysql_real_escape_string($_POST["show_comments"])."', ".
"revisioncount = '".mysql_real_escape_string($_POST["revisioncount"])."', ".
"changescount = '".mysql_real_escape_string($_POST["changescount"])."', ".
"stay_loged_in = '".mysql_real_escape_string($_POST["stay_loged_in"])."' ".
"where name = '".$user["name"]."' limit 1");
4) replace the function SetUser in ##wikka.php## with the following one:
%%(php)
function SetUser($user)
{
$_SESSION["user"] = $user;
if ($user["stay_loged_in"])
{
$this->SetPersistentCookie("name", $user["name"]);
$this->SetPersistentCookie("password", $user["password"]);
}
else
{
$this->SetSessionCookie("name", $user["name"]);
$this->SetSessionCookie("password", $user["password"]);
}
}
Revision [3316]
Edited on 2004-12-16 15:47:23 by GmBowen [suggestion to move cookie discussion/code to own page]Additions:
''Might I suggest moving this code/topic to its own page and adding it to CodeContributions. I think it's a useful little add-in and should have its own place now that there's a bit of a solution for the issue. Well done Nils. -- Mike (GmBowen)''
Additions:
- unregistered users need no cookie, because they neither have a username nor a password. :-) NilsLindenberg
Deletions:
Additions:
- unregistered users ned no cookie, becuase they neither have a username nor a password. :-) NilsLindenberg
Additions:
4) replace the function SetUser in ##wikka.php## with the following one:
Deletions:
Revision [3310]
Edited on 2004-12-16 14:44:58 by 213.209.216.163 [added code for changing between auto-login and no auto-login]Additions:
I stuck some piece of code together. I know that stay_loged_in is a very uncreative name (loged-in with one or two g?), and the code needs someone to look over it. I am for example not sure if an enum in the table would be better. But to my great astonishment, it seems to work. :) --NilsLindenberg
1) adding field to user table:
SQL-query:
ALTER TABLE `wikka_users` ADD `stay_loged_in` TINYINT DEFAULT '0' NOT NULL ;
%%
2)adding a to show the status of the variable (to ##actions/usersettings.php## after the block with ""<td align="right">Page revisions list limit:</td>""):
%%(html)
<tr>
<td align="right">Stay loged-in:</td>
<td><input name="stay_loged_in" value="<?php echo htmlspecialchars($user["stay_loged_in"]) ?>" size="40" /></td>
</tr>
3) added the user-table-update in ##actions/usersettings.php##:
change:
$this->Query("update ".$this->config["table_prefix"]."users set ".
"email = '".mysql_real_escape_string($_POST["email"])."', ".
"doubleclickedit = '".mysql_real_escape_string($_POST["doubleclickedit"])."', ".
"show_comments = '".mysql_real_escape_string($_POST["show_comments"])."', ".
"revisioncount = '".mysql_real_escape_string($_POST["revisioncount"])."', ".
"changescount = '".mysql_real_escape_string($_POST["changescount"])."' ".
"where name = '".$user["name"]."' limit 1");
$this->Query("update ".$this->config["table_prefix"]."users set ".
"email = '".mysql_real_escape_string($_POST["email"])."', ".
"doubleclickedit = '".mysql_real_escape_string($_POST["doubleclickedit"])."', ".
"show_comments = '".mysql_real_escape_string($_POST["show_comments"])."', ".
"revisioncount = '".mysql_real_escape_string($_POST["revisioncount"])."', ".
"changescount = '".mysql_real_escape_string($_POST["changescount"])."', ".
"stay_loged_in = '".mysql_real_escape_string($_POST["stay_loged_in"])."' ".
"where name = '".$user["name"]."' limit 1");
4) replace the function GetUser in ##wikka.php## with the following one:
function SetUser($user)
{
$_SESSION["user"] = $user;
if ($user["stay_loged_in"])
{
$this->SetPersistentCookie("name", $user["name"]);
$this->SetPersistentCookie("password", $user["password"]);
}
else
{
$this->SetSessionCookie("name", $user["name"]);
$this->SetSessionCookie("password", $user["password"]);
}
}
1) adding field to user table:
SQL-query:
ALTER TABLE `wikka_users` ADD `stay_loged_in` TINYINT DEFAULT '0' NOT NULL ;
%%
2)adding a to show the status of the variable (to ##actions/usersettings.php## after the block with ""<td align="right">Page revisions list limit:</td>""):
%%(html)
<tr>
<td align="right">Stay loged-in:</td>
<td><input name="stay_loged_in" value="<?php echo htmlspecialchars($user["stay_loged_in"]) ?>" size="40" /></td>
</tr>
3) added the user-table-update in ##actions/usersettings.php##:
change:
$this->Query("update ".$this->config["table_prefix"]."users set ".
"email = '".mysql_real_escape_string($_POST["email"])."', ".
"doubleclickedit = '".mysql_real_escape_string($_POST["doubleclickedit"])."', ".
"show_comments = '".mysql_real_escape_string($_POST["show_comments"])."', ".
"revisioncount = '".mysql_real_escape_string($_POST["revisioncount"])."', ".
"changescount = '".mysql_real_escape_string($_POST["changescount"])."' ".
"where name = '".$user["name"]."' limit 1");
$this->Query("update ".$this->config["table_prefix"]."users set ".
"email = '".mysql_real_escape_string($_POST["email"])."', ".
"doubleclickedit = '".mysql_real_escape_string($_POST["doubleclickedit"])."', ".
"show_comments = '".mysql_real_escape_string($_POST["show_comments"])."', ".
"revisioncount = '".mysql_real_escape_string($_POST["revisioncount"])."', ".
"changescount = '".mysql_real_escape_string($_POST["changescount"])."', ".
"stay_loged_in = '".mysql_real_escape_string($_POST["stay_loged_in"])."' ".
"where name = '".$user["name"]."' limit 1");
4) replace the function GetUser in ##wikka.php## with the following one:
function SetUser($user)
{
$_SESSION["user"] = $user;
if ($user["stay_loged_in"])
{
$this->SetPersistentCookie("name", $user["name"]);
$this->SetPersistentCookie("password", $user["password"]);
}
else
{
$this->SetSessionCookie("name", $user["name"]);
$this->SetSessionCookie("password", $user["password"]);
}
}
Additions:
''I agree - it's quite common to give a (registered) user a choice between a session cookie and a permanent cookie; such a choice should of course be stored in the user profile in the database. For unregistered visitors only session cookies should be used. --JavaWoman''
Revision [3245]
Edited on 2004-12-15 19:03:54 by ChristianBarthelemy [comment about sessions/cookies]Additions:
''This is much more secure yet I think that this should be the user decision to keep the cookie or not through the UserSettings: maybe another field in the wikka_users table?
--ChristianBarthelemy''
--ChristianBarthelemy''
Deletions:
ChristianBarthelemy
Revision [3244]
Edited on 2004-12-15 19:02:50 by ChristianBarthelemy [comment about sessions/cookies]Additions:
~"This is much more secure yet I think that this should be the user decision to keep the cookie or not through the UserSettings: maybe another field in the wikka_users table?"
Deletions:
Revision [3242]
Edited on 2004-12-15 19:02:13 by ChristianBarthelemy [comment about sessions/cookies]Additions:
~This is much more secure yet I think that this should be the user decision to keep the cookie or not through the UserSettings: maybe another field in the wikka_users table?
Deletions:
Additions:
This is much more secure yet I think that this should be the user decision to keep the cookie or not through the UserSettings: maybe another field in the wikka_users table?
ChristianBarthelemy
ChristianBarthelemy
Additions:
==Staying logged-in==
The log-in information is stored in a cookie which expires after 90 days. This is quite comfortable but could be a security risk, if you forget to logout in a i-net caffè ort on a pc used by many people.
To be loged-out when you close the browser, change in ##wikka.php##
%%(php)
function SetUser($user) { $_SESSION["user"] = $user; $this->SetPersistentCookie("name", $user["name"]); $this->SetPersistentCookie("password", $user["password"]); }
to
%%(php)
function SetUser($user) { $_SESSION["user"] = $user; $this->SetSessionCookie("name", $user["name"]); $this->SetSessionCookie("password", $user["password"]); }
Perhaps that should be the default and the user should have an "always loged-in" setting?
NilsLindenberg
The log-in information is stored in a cookie which expires after 90 days. This is quite comfortable but could be a security risk, if you forget to logout in a i-net caffè ort on a pc used by many people.
To be loged-out when you close the browser, change in ##wikka.php##
%%(php)
function SetUser($user) { $_SESSION["user"] = $user; $this->SetPersistentCookie("name", $user["name"]); $this->SetPersistentCookie("password", $user["password"]); }
to
%%(php)
function SetUser($user) { $_SESSION["user"] = $user; $this->SetSessionCookie("name", $user["name"]); $this->SetSessionCookie("password", $user["password"]); }
Perhaps that should be the default and the user should have an "always loged-in" setting?
NilsLindenberg
Revision [3200]
Edited on 2004-12-14 22:25:14 by GeorgePetsagourakis [added a note about logging out]Additions:
maybe we could have a level switch on that feature, constituting it obligatory, optional, or off... an addittion to the conf will be neccessary thought.. --GeorgePetsagourakis
Revision [3187]
Edited on 2004-12-14 19:39:41 by JavaWoman [repairing conversation about %% in code block]Additions:
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. See: %%some text with %% embedded in it%%
Deletions:
Revision [3184]
Edited on 2004-12-14 19:28:20 by NilsLindenberg [moved user-feedback to IndependentWikkaReview]Additions:
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. Code: %%some text with %% embedded in it%%
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Deletions:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
== Kudos! Excellent software!==
I wanted to add some functionality to my WakkaWiki site, but found that they disappeared. Upgrading to Wikka gave me all the features that I wanted, and a bunch more.
Good job all!
-- [[http://wiki.gednet.com Jeff]]
- Wikka is the best ever. Keep up the good work! ;)
Additions:
==Handling the config==
I have three questions about the config. See HandlingWikkaConfig.
==Markup for code not to be shown==
I have three questions about the config. See HandlingWikkaConfig.
==Markup for code not to be shown==
Revision [2707]
Edited on 2004-11-30 22:42:35 by GmBowen [regex....yechh, blecchhh, gag......thanks for the hint JW.]Additions:
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
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
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
Deletions:
Additions:
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.
~''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''
~''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''
Deletions:
Revision [2700]
Edited on 2004-11-30 21:19:31 by GmBowen [reply to JW on wikka code for "hidden" comments]Additions:
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.
Revision [2698]
Edited on 2004-11-30 21:04:58 by JavaWoman [reply to Mike about hiding (commenting) text]Additions:
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''
~''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''
Deletions:
Revision [2690]
Edited on 2004-11-30 19:34:05 by GmBowen [reply to JW on why we need a "commenting" feature for wiki code]Additions:
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
Revision [2689]
Edited on 2004-11-30 19:15:16 by NilsLindenberg [moved discussion out of resolved actions]No Differences
Revision [2687]
Edited on 2004-11-30 19:06:13 by JavaWoman [reply to Mike and demo commenting out code]Additions:
~''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''
Revision [2685]
Edited on 2004-11-30 18:20:35 by GmBowen [reply to JW re: commenting code in wikka markup]Additions:
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
Additions:
~''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''
Revision [2667]
Edited on 2004-11-30 16:50:09 by GmBowen [suggestion for wiki markup code for non-showing comments]Additions:
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)
Deletions:
I suggest to change the RecentChanges action by adding information about the Wikipingserver(s). If the config value for the wikipingserver isn't empty, the URLS should be printed at the top or bottom of the recentchanges page, so that user are informed.
Additions:
==Online editing of mindmaps would be great==
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
I suggest to change the RecentChanges action by adding information about the Wikipingserver(s). If the config value for the wikipingserver isn't empty, the URLS should be printed at the top or bottom of the recentchanges page, so that user are informed.
(copied from Sourceforge.net --NilsLindenberg)
It would be great, if users should work together on mindmaps.
Maybe by downloading/ Open With FreeMind and then having a possiblity to save changes in FreeMind directly back to the online mindmap.
I suggest to change the RecentChanges action by adding information about the Wikipingserver(s). If the config value for the wikipingserver isn't empty, the URLS should be printed at the top or bottom of the recentchanges page, so that user are informed.
Deletions:
Additions:
==WikiPing==
I suggest to change the RechentChanges action by adding information about the Wikipingserver(s). If the config value for the wikipingserver isn't empty, the URLS should be printed at the top or bottom of the recentchanges page, so that user are informed.
I suggest to change the RechentChanges action by adding information about the Wikipingserver(s). If the config value for the wikipingserver isn't empty, the URLS should be printed at the top or bottom of the recentchanges page, so that user are informed.
Additions:
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
''The main problem with the € (euro) symbol is not that it's new, but that it's hard to type: most keyboards don't have the symbol. And it might occur in code as well (imagine a sample conversion routine). Wiki markup should be easy to type. So we need a symbol (or sumbol combination, maybe), that's:
~1) easy to type
~2) not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
The **exclamation mark** still seems to be "free", and although a single exclamation mark often is used for negation in programming languages (and in comments, of course) a double one isn't (just don't use rows off exclamation marks in your code comments); or else a combination of an exclamation mark with something else (that is not itself an "operator" in languages). Maybe we should do a search (Google?) to check whether **!!** or a combo is actually an operator in any language.
-- JavaWoman''
Deletions:
Additions:
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
// 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
Additions:
How about the € (euro) Symbol? Or is it to new? --NilsLindenberg
Additions:
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
====Using FPDF with Wikka====
Not so much a suggestion, more a request although it may be useful to others.
I have been using FPDF from [[http://www.fpdf.org FPDF ]] to export content from a database to pdf files.
I would like to extend my usage of FPDF to wikka by adding a hyperlink to the top of my wikka pages which would allow me to post the page tag or page id to the FPDF script for exporting the content into a pdf file.
The link would be in the form similar to
http://www.mysite.com/script.php?id=
Can anyone tell me how I can extract the page tag or page id from the wikka_pages table in order to do this.
====Using FPDF with Wikka====
Not so much a suggestion, more a request although it may be useful to others.
I have been using FPDF from [[http://www.fpdf.org FPDF ]] to export content from a database to pdf files.
I would like to extend my usage of FPDF to wikka by adding a hyperlink to the top of my wikka pages which would allow me to post the page tag or page id to the FPDF script for exporting the content into a pdf file.
The link would be in the form similar to
http://www.mysite.com/script.php?id=
Can anyone tell me how I can extract the page tag or page id from the wikka_pages table in order to do this.
Deletions:
Additions:
Just added a few thoughts [[WikkaFilters here]]
Deletions:
Additions:
==Wikka Exporting/Importing ==
Just added few thoughts [[WikkaFilters here]]
-- DarTar
==how to format code to get two % characters without space together?==
Just added few thoughts [[WikkaFilters here]]
-- DarTar
==how to format code to get two % characters without space together?==
Deletions:
===how to format code to get two % characters without space together?===
Additions:
''You could use % which is the numerical entity reference for the percent sign: % - but *within* a code block an entity is "escaped" - a problem by itself, and so it wouldn't help. Code: %%some text with %% embedded in it%%
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
But it should be possible to just plug in a piece of code without having to worry about which characters and strings to somehow escape - maybe the double percent isn't such a happy choice for Wiki markup of "code"; should we find a character combination that is less likely to be a syntactical meaning in an artificial language? (And how do you markup Wiki markup as **code**?) -- JavaWoman''
No Differences
Additions:
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with two percent characters like this here%%
Deletions:
Additions:
===how to format code to get two % characters without space together?===
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with %%
Is there a solution? I could not find a literal entity for "percent"
I want to produce a code sample page in wikka with DOS batch code. The code syntax requires two percent characters together to markup a variable. Example: % %variable% % (without the spaces). Wikka always tries to format the text as code, even if I format the DOS code inside a code block, even if I %% marked it as code with %%
Is there a solution? I could not find a literal entity for "percent"
Additions:
''I completed altering a script and modifying the wikka code for this.....go to GmBowenCounter for the php script and the necessary alterations'' --GmBowen
Deletions:
I don't know if this goes against the Wiki way of doing things, but it would be nice to configure a table in which users could enter data into and then 'submit' (click a submit button I suppose) and have it saved to the page without having to 'edit page'.
--ArisStathakis
''Can you post a link to a site where you can enter data without editing the page? I'm not sure what that would look like.'' - JsnX
''GmBowen had something related [[http://216.239.59.104/search?q=cache:yQ1M5p3RTfoJ:bowen4-srv.lakeheadu.ca/wikitxt/wakka.php%3Fwakka%3DHomePage+cejhsst&hl=en here]]. I can't seem to get his page to load, therefore I've linked it to its google-cache. Basically, it's a form input thing that allows you to create tables row by row and edit data cell by cell. Very tedious to initialise, but i suppose it could be handy just to click on celldata to edit it (and view data if the user has readonly access). This method is a lot more intuitive than the current method of creating tables, but it would involve flatdb (or a new/seperate mysql schema). Just adding to the discussion, I don't believe that this suggestion is the ultimate solution.'' -- Sam
The "spreadsheet" (or, interactive table if you want) script uses a MYSQL table with the spreadsheet assigned by default to the page name & owner (which has to match the logged in user), although the logged in user can "force" another table name. Another "action" script allows just showing the table without the interactive nature. So the user can enter the table components using the "spreadsheet", and then show it on the page using the "showtable name=" script. The spreadsheet script allows one to calculate sum, average, count, and frequency (at this point only on the columns) and is intended to provide simple on-line spreadsheet functions for kids working on science projects which they can then embed in a written report. I'm moving the server right now which is why it isn't up. It will be in the next week. The script is a (greatly) modified version of one available from this site...http://www.ka.sara.nl/home/boven/ .... Because it's intended for kids it is reasonably user friendly, although lacking many formatting abilities that "adult" users are used to -- Mike Bowen
''My 2 cents on tables. I think we should consider in the long run the possibility of a major refactoring of the syntax for tabular data. The current table action is extremely user-unfriendly (just have a look at the source of ConfigurationOptions). Moreover, the table action does not convert wikka-formatted strings, which in some cases is a little annoying. It think a nice idea would be to have tables directly handled in the formatter, instead of using an action. I like very much the [[http://wackowiki.com/WackoDocumentation/WackoFormatting?v=11ij#h7705-8 wacko approach]] to tables, maybe we could do even better and find a more intuitive syntax.'' -- DarTar
''I haven't checked this out yet, but doesn't UsingHTML pretty much solve the problem on table syntax? Now it's just figuring out how to edit a cell without editting a page.'' --Sam
If you want to work with individual cells, it sounds like you're thinking about something like this.... http://www.ycode.com/SpreadSheet/Latest/yCode_spreadSheet_simple.htm ... although it is not open source. Just providing the link for discussion purposes. -- Mike B
Tables were one of the biggest reasons for us wanting to go with Wikka over our existing WakkaWiki. However the syntax as it is right now is pretty unintuitive. Having one giant string of comma separated values just doesn't work for me. It would be nice to at least make it so you can add line breaks between rows. -- Justin F
[[http://flexwiki.com/ FlexWiki]]* has a rich table markup that seems fairly easy to use. See [[http://www.flexwiki.com/default.aspx/FlexWiki.FormattingRules FormattingRules]] for the basics and [[http://www.flexwiki.com/default.aspx/FlexWiki.TableFormattingRules TableFormattingRules]] for the details. I'd like us to adopt at least the basics, and maybe add some of the extended possibilities gradually.
* (MS open source! And with Ward Cunningham apparently working for MS now...)
--JavaWoman
''JW, an interesting syntax for tabular data is used by [[http://wiki.cs.cityu.edu.hk/CitiWiki/CitiWiki CitiWiki]] (adapted from [[http://comawiki.martignier.net/ ComaWiki]]): [[http://wiki.cs.cityu.edu.hk/CitiWiki/HelpMeTable HelpMeTable]] -- DarTar''
''DT, JW, JT etc....if you "like" the table format used by CitiWiki (and I personally think it's reasonably user friendly & a good alternative), I might suggest not looking at the code at all but trying to replicate the outcome using your own coding approach. Rightly or wrongly, ComaWiki is copyrighted...at least the "new" parts are....and not released to public domain (he charges for commercial use), so using (and, in legal cases, even looking at somebodies code makes you culpable is my understanding) the code as part of wikka might lead to problems. Just food for thought.'' --GmBowen
Hmmm - the ""CitiWiki"" syntax looks very much like [[http://flexwiki.com/ FlexWiki]] as far as the basic syntax is concerned - but the complete ""FlexiWiki"" table syntax is not only richer, but it's syntax "pattern" is more easily extensible, too. Do have a look and compare what they do with CitiWiki and you'll (probably) see what I mean. :) I like extensibility so I like the ""FlexiWiki"" syntax better. No problems with copyright either - it's open source.
In fact, since I expect I'll **need** tables for my (planned) Wiki I'd do my own mod for this if Wikka doesn't have one by the time I get may email stuff finished (hacking hard...). -- JavaWoman
Picking up on Sam's point....perhaps code written for wikka that does something like this.....
http://131.202.167.33/wiki/wakka.php?wakka=TableMaker -- GmBowen
''All that to generate a very basic HTML table (not even a data table)? A good Wiki syntax would probably be easier to understand as well as more efficient for the basics. -- JavaWoman''
Additions:
==Tables ==
For the discussion on tables in Wikka, take a look at WikkaTables.
For the discussion on tables in Wikka, take a look at WikkaTables.
Additions:
Hmmm - the ""CitiWiki"" syntax looks very much like [[http://flexwiki.com/ FlexWiki]] as far as the basic syntax is concerned - but the complete ""FlexiWiki"" table syntax is not only richer, but it's syntax "pattern" is more easily extensible, too. Do have a look and compare what they do with CitiWiki and you'll (probably) see what I mean. :) I like extensibility so I like the ""FlexiWiki"" syntax better. No problems with copyright either - it's open source.
In fact, since I expect I'll **need** tables for my (planned) Wiki I'd do my own mod for this if Wikka doesn't have one by the time I get may email stuff finished (hacking hard...). -- JavaWoman
''All that to generate a very basic HTML table (not even a data table)? A good Wiki syntax would probably be easier to understand as well as more efficient for the basics. -- JavaWoman''
In fact, since I expect I'll **need** tables for my (planned) Wiki I'd do my own mod for this if Wikka doesn't have one by the time I get may email stuff finished (hacking hard...). -- JavaWoman
''All that to generate a very basic HTML table (not even a data table)? A good Wiki syntax would probably be easier to understand as well as more efficient for the basics. -- JavaWoman''
Additions:
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.) --JavaWoman.
Deletions:
JavaWoman.
http://discount-phentermine.fastsearch.eu.com/
http://foreign-exchange-trading.fastsearch.eu.com/
http://las-vegas-hotel-casino.fastsearch.eu.com/
http://new-online-casinos.fastsearch.eu.com/
http://sports-book-gambling.fastsearch.eu.com/
http://zodiac-casino.fastsearch.eu.com/
http://at-home-business-opportunity.fastsearch.eu.com/
http://auto-shipping.fastsearch.eu.com/
http://bingo.fastsearch.eu.com/
http://buspar.fastsearch.eu.com/
http://carnival-cruise-line.fastsearch.eu.com/
http://drug-addiction-treatment.fastsearch.eu.com/
http://free-gambling.fastsearch.eu.com/
http://internet-poker-casino.fastsearch.eu.com/
http://online-loan.fastsearch.eu.com/
http://payment-processing.fastsearch.eu.com/
http://personal-credit-report.fastsearch.eu.com/
http://psychic-reading.fastsearch.eu.com/
http://repair-credit.fastsearch.eu.com/
http://spa.fastsearch.eu.com/
http://stock-pick.fastsearch.eu.com/
http://truck-rental.fastsearch.eu.com/
http://valtrex.fastsearch.eu.com/
http://cigar.fastsearch.eu.com/
http://artworks-strip-poker.fastsearch.eu.com/
http://poker-monkey.fastsearch.eu.com/
http://sets-poker-chips-wholesale.fastsearch.eu.com/
http://slot-repair.fastsearch.eu.com/
http://bad-credit-financing.fastsearch.eu.com/
http://blackjack-strategy.fastsearch.eu.com/
http://blackjack-tips.fastsearch.eu.com/
http://commodity-broker.fastsearch.eu.com/
http://credit-card-consolidation-loan.fastsearch.eu.com/
http://credit-card-consolidation.fastsearch.eu.com/
http://credit-counseling.fastsearch.eu.com/
http://free-online-casino.fastsearch.eu.com/
http://low-mortgage-rate.fastsearch.eu.com/
http://play-blackjack-online.fastsearch.eu.com/
http://refinance-car-loan.fastsearch.eu.com/
http://senior-life-insurance.fastsearch.eu.com/
http://travel-nurse.fastsearch.eu.com/
http://video-poker.fastsearch.eu.com/
http://addiction-drug.fastsearch.eu.com/
http://ameriquest-mortgage-company.fastsearch.eu.com/
http://buy-adipex-on-line.fastsearch.eu.com/
http://canadian-pharmacies-online.fastsearch.eu.com/
http://chapter-7.fastsearch.eu.com/
http://circus-circus-in-las-vegas.fastsearch.eu.com/
http://colon-cleanser.fastsearch.eu.com/
http://crm.fastsearch.eu.com/
http://domain-name.fastsearch.eu.com/
http://drug-addiction.fastsearch.eu.com/
http://faux-wood-blinds.fastsearch.eu.com/
http://financial-advice.fastsearch.eu.com/
http://foreign-pharmacies.fastsearch.eu.com/
http://foreign-pharmacy.fastsearch.eu.com/
http://free-credit-check.fastsearch.eu.com/
http://greenies.fastsearch.eu.com/
http://hard-money-lender.fastsearch.eu.com/
http://hotel-in-london.fastsearch.eu.com/
http://hotel-in-rome.fastsearch.eu.com/
http://las-vegas-vacation-package.fastsearch.eu.com/
http://london-hotels.fastsearch.eu.com/
http://mortgage-uk.fastsearch.eu.com/
http://moving-truck-rental.fastsearch.eu.com/
http://new-jersey-home-refinance.fastsearch.eu.com/
http://office-chair.fastsearch.eu.com/
http://online-marketing.fastsearch.eu.com/
http://pai-gow-poker.fastsearch.eu.com/
http://poker-cards.fastsearch.eu.com/
http://purchase-phentermine.fastsearch.eu.com/
http://rome-hotels.fastsearch.eu.com/
http://royal-caribbean.fastsearch.eu.com/
http://server-rack.fastsearch.eu.com/
http://thesis.fastsearch.eu.com/
http://ticket-broker.fastsearch.eu.com/
http://viagra-prescriptions.fastsearch.eu.com/
http://viagra-sale.fastsearch.eu.com/
http://video-surveillance.fastsearch.eu.com/
http://visa-credit-application.fastsearch.eu.com/
http://workbench.fastsearch.eu.com/
http://phone-system.fastsearch.eu.com/
http://offshore-trust.fastsearch.eu.com/
http://credit-card-debt-settlement.fastsearch.eu.com/
http://debt-help.fastsearch.eu.com/
http://south-lake-tahoe.fastsearch.eu.com/
http://toyota-dealer.fastsearch.eu.com/
http://web-traffic.fastsearch.eu.com/
http://online-investing.fastsearch.eu.com/
http://austin-hotel.fastsearch.eu.com/
http://business-education.fastsearch.eu.com/
http://canadian-on-line-pharmacy.fastsearch.eu.com/
http://canadian-pharmacy-on-line.fastsearch.eu.com/
http://canadian-pharmacy-online.fastsearch.eu.com/
http://car-insurance-quote.fastsearch.eu.com/
http://drivers-education.fastsearch.eu.com/
http://eliminate-credit-card-debt.fastsearch.eu.com/
http://european-cruise.fastsearch.eu.com/
http://foreclosure-listing.fastsearch.eu.com/
http://instant-online-loan.fastsearch.eu.com/
http://kauai-wedding.fastsearch.eu.com/
http://low-interest-credit-card.fastsearch.eu.com/
http://match.fastsearch.eu.com/
http://online-prescription-pharmacy.fastsearch.eu.com/
Revision [1848]
Edited on 2004-10-14 01:45:16 by host-148-244-150-58.block.alestra.net.mx [more table comments]Additions:
JavaWoman.
http://discount-phentermine.fastsearch.eu.com/
http://foreign-exchange-trading.fastsearch.eu.com/
http://las-vegas-hotel-casino.fastsearch.eu.com/
http://new-online-casinos.fastsearch.eu.com/
http://sports-book-gambling.fastsearch.eu.com/
http://zodiac-casino.fastsearch.eu.com/
http://at-home-business-opportunity.fastsearch.eu.com/
http://auto-shipping.fastsearch.eu.com/
http://bingo.fastsearch.eu.com/
http://buspar.fastsearch.eu.com/
http://carnival-cruise-line.fastsearch.eu.com/
http://drug-addiction-treatment.fastsearch.eu.com/
http://free-gambling.fastsearch.eu.com/
http://internet-poker-casino.fastsearch.eu.com/
http://online-loan.fastsearch.eu.com/
http://payment-processing.fastsearch.eu.com/
http://personal-credit-report.fastsearch.eu.com/
http://psychic-reading.fastsearch.eu.com/
http://repair-credit.fastsearch.eu.com/
http://spa.fastsearch.eu.com/
http://stock-pick.fastsearch.eu.com/
http://truck-rental.fastsearch.eu.com/
http://valtrex.fastsearch.eu.com/
http://cigar.fastsearch.eu.com/
http://artworks-strip-poker.fastsearch.eu.com/
http://poker-monkey.fastsearch.eu.com/
http://sets-poker-chips-wholesale.fastsearch.eu.com/
http://slot-repair.fastsearch.eu.com/
http://bad-credit-financing.fastsearch.eu.com/
http://blackjack-strategy.fastsearch.eu.com/
http://blackjack-tips.fastsearch.eu.com/
http://commodity-broker.fastsearch.eu.com/
http://credit-card-consolidation-loan.fastsearch.eu.com/
http://credit-card-consolidation.fastsearch.eu.com/
http://credit-counseling.fastsearch.eu.com/
http://free-online-casino.fastsearch.eu.com/
http://low-mortgage-rate.fastsearch.eu.com/
http://play-blackjack-online.fastsearch.eu.com/
http://refinance-car-loan.fastsearch.eu.com/
http://senior-life-insurance.fastsearch.eu.com/
http://travel-nurse.fastsearch.eu.com/
http://video-poker.fastsearch.eu.com/
http://addiction-drug.fastsearch.eu.com/
http://ameriquest-mortgage-company.fastsearch.eu.com/
http://buy-adipex-on-line.fastsearch.eu.com/
http://canadian-pharmacies-online.fastsearch.eu.com/
http://chapter-7.fastsearch.eu.com/
http://circus-circus-in-las-vegas.fastsearch.eu.com/
http://colon-cleanser.fastsearch.eu.com/
http://crm.fastsearch.eu.com/
http://domain-name.fastsearch.eu.com/
http://drug-addiction.fastsearch.eu.com/
http://faux-wood-blinds.fastsearch.eu.com/
http://financial-advice.fastsearch.eu.com/
http://foreign-pharmacies.fastsearch.eu.com/
http://foreign-pharmacy.fastsearch.eu.com/
http://free-credit-check.fastsearch.eu.com/
http://greenies.fastsearch.eu.com/
http://hard-money-lender.fastsearch.eu.com/
http://hotel-in-london.fastsearch.eu.com/
http://hotel-in-rome.fastsearch.eu.com/
http://las-vegas-vacation-package.fastsearch.eu.com/
http://london-hotels.fastsearch.eu.com/
http://mortgage-uk.fastsearch.eu.com/
http://moving-truck-rental.fastsearch.eu.com/
http://new-jersey-home-refinance.fastsearch.eu.com/
http://office-chair.fastsearch.eu.com/
http://online-marketing.fastsearch.eu.com/
http://pai-gow-poker.fastsearch.eu.com/
http://poker-cards.fastsearch.eu.com/
http://purchase-phentermine.fastsearch.eu.com/
http://rome-hotels.fastsearch.eu.com/
http://royal-caribbean.fastsearch.eu.com/
http://server-rack.fastsearch.eu.com/
http://thesis.fastsearch.eu.com/
http://ticket-broker.fastsearch.eu.com/
http://viagra-prescriptions.fastsearch.eu.com/
http://viagra-sale.fastsearch.eu.com/
http://video-surveillance.fastsearch.eu.com/
http://visa-credit-application.fastsearch.eu.com/
http://workbench.fastsearch.eu.com/
http://phone-system.fastsearch.eu.com/
http://offshore-trust.fastsearch.eu.com/
http://credit-card-debt-settlement.fastsearch.eu.com/
http://debt-help.fastsearch.eu.com/
http://south-lake-tahoe.fastsearch.eu.com/
http://toyota-dealer.fastsearch.eu.com/
http://web-traffic.fastsearch.eu.com/
http://online-investing.fastsearch.eu.com/
http://austin-hotel.fastsearch.eu.com/
http://business-education.fastsearch.eu.com/
http://canadian-on-line-pharmacy.fastsearch.eu.com/
http://canadian-pharmacy-on-line.fastsearch.eu.com/
http://canadian-pharmacy-online.fastsearch.eu.com/
http://car-insurance-quote.fastsearch.eu.com/
http://drivers-education.fastsearch.eu.com/
http://eliminate-credit-card-debt.fastsearch.eu.com/
http://european-cruise.fastsearch.eu.com/
http://foreclosure-listing.fastsearch.eu.com/
http://instant-online-loan.fastsearch.eu.com/
http://kauai-wedding.fastsearch.eu.com/
http://low-interest-credit-card.fastsearch.eu.com/
http://match.fastsearch.eu.com/
http://online-prescription-pharmacy.fastsearch.eu.com/
http://discount-phentermine.fastsearch.eu.com/
http://foreign-exchange-trading.fastsearch.eu.com/
http://las-vegas-hotel-casino.fastsearch.eu.com/
http://new-online-casinos.fastsearch.eu.com/
http://sports-book-gambling.fastsearch.eu.com/
http://zodiac-casino.fastsearch.eu.com/
http://at-home-business-opportunity.fastsearch.eu.com/
http://auto-shipping.fastsearch.eu.com/
http://bingo.fastsearch.eu.com/
http://buspar.fastsearch.eu.com/
http://carnival-cruise-line.fastsearch.eu.com/
http://drug-addiction-treatment.fastsearch.eu.com/
http://free-gambling.fastsearch.eu.com/
http://internet-poker-casino.fastsearch.eu.com/
http://online-loan.fastsearch.eu.com/
http://payment-processing.fastsearch.eu.com/
http://personal-credit-report.fastsearch.eu.com/
http://psychic-reading.fastsearch.eu.com/
http://repair-credit.fastsearch.eu.com/
http://spa.fastsearch.eu.com/
http://stock-pick.fastsearch.eu.com/
http://truck-rental.fastsearch.eu.com/
http://valtrex.fastsearch.eu.com/
http://cigar.fastsearch.eu.com/
http://artworks-strip-poker.fastsearch.eu.com/
http://poker-monkey.fastsearch.eu.com/
http://sets-poker-chips-wholesale.fastsearch.eu.com/
http://slot-repair.fastsearch.eu.com/
http://bad-credit-financing.fastsearch.eu.com/
http://blackjack-strategy.fastsearch.eu.com/
http://blackjack-tips.fastsearch.eu.com/
http://commodity-broker.fastsearch.eu.com/
http://credit-card-consolidation-loan.fastsearch.eu.com/
http://credit-card-consolidation.fastsearch.eu.com/
http://credit-counseling.fastsearch.eu.com/
http://free-online-casino.fastsearch.eu.com/
http://low-mortgage-rate.fastsearch.eu.com/
http://play-blackjack-online.fastsearch.eu.com/
http://refinance-car-loan.fastsearch.eu.com/
http://senior-life-insurance.fastsearch.eu.com/
http://travel-nurse.fastsearch.eu.com/
http://video-poker.fastsearch.eu.com/
http://addiction-drug.fastsearch.eu.com/
http://ameriquest-mortgage-company.fastsearch.eu.com/
http://buy-adipex-on-line.fastsearch.eu.com/
http://canadian-pharmacies-online.fastsearch.eu.com/
http://chapter-7.fastsearch.eu.com/
http://circus-circus-in-las-vegas.fastsearch.eu.com/
http://colon-cleanser.fastsearch.eu.com/
http://crm.fastsearch.eu.com/
http://domain-name.fastsearch.eu.com/
http://drug-addiction.fastsearch.eu.com/
http://faux-wood-blinds.fastsearch.eu.com/
http://financial-advice.fastsearch.eu.com/
http://foreign-pharmacies.fastsearch.eu.com/
http://foreign-pharmacy.fastsearch.eu.com/
http://free-credit-check.fastsearch.eu.com/
http://greenies.fastsearch.eu.com/
http://hard-money-lender.fastsearch.eu.com/
http://hotel-in-london.fastsearch.eu.com/
http://hotel-in-rome.fastsearch.eu.com/
http://las-vegas-vacation-package.fastsearch.eu.com/
http://london-hotels.fastsearch.eu.com/
http://mortgage-uk.fastsearch.eu.com/
http://moving-truck-rental.fastsearch.eu.com/
http://new-jersey-home-refinance.fastsearch.eu.com/
http://office-chair.fastsearch.eu.com/
http://online-marketing.fastsearch.eu.com/
http://pai-gow-poker.fastsearch.eu.com/
http://poker-cards.fastsearch.eu.com/
http://purchase-phentermine.fastsearch.eu.com/
http://rome-hotels.fastsearch.eu.com/
http://royal-caribbean.fastsearch.eu.com/
http://server-rack.fastsearch.eu.com/
http://thesis.fastsearch.eu.com/
http://ticket-broker.fastsearch.eu.com/
http://viagra-prescriptions.fastsearch.eu.com/
http://viagra-sale.fastsearch.eu.com/
http://video-surveillance.fastsearch.eu.com/
http://visa-credit-application.fastsearch.eu.com/
http://workbench.fastsearch.eu.com/
http://phone-system.fastsearch.eu.com/
http://offshore-trust.fastsearch.eu.com/
http://credit-card-debt-settlement.fastsearch.eu.com/
http://debt-help.fastsearch.eu.com/
http://south-lake-tahoe.fastsearch.eu.com/
http://toyota-dealer.fastsearch.eu.com/
http://web-traffic.fastsearch.eu.com/
http://online-investing.fastsearch.eu.com/
http://austin-hotel.fastsearch.eu.com/
http://business-education.fastsearch.eu.com/
http://canadian-on-line-pharmacy.fastsearch.eu.com/
http://canadian-pharmacy-on-line.fastsearch.eu.com/
http://canadian-pharmacy-online.fastsearch.eu.com/
http://car-insurance-quote.fastsearch.eu.com/
http://drivers-education.fastsearch.eu.com/
http://eliminate-credit-card-debt.fastsearch.eu.com/
http://european-cruise.fastsearch.eu.com/
http://foreclosure-listing.fastsearch.eu.com/
http://instant-online-loan.fastsearch.eu.com/
http://kauai-wedding.fastsearch.eu.com/
http://low-interest-credit-card.fastsearch.eu.com/
http://match.fastsearch.eu.com/
http://online-prescription-pharmacy.fastsearch.eu.com/
Deletions:
Additions:
Additions:
''DT, JW, JT etc....if you "like" the table format used by CitiWiki (and I personally think it's reasonably user friendly & a good alternative), I might suggest not looking at the code at all but trying to replicate the outcome using your own coding approach. Rightly or wrongly, ComaWiki is copyrighted...at least the "new" parts are....and not released to public domain (he charges for commercial use), so using (and, in legal cases, even looking at somebodies code makes you culpable is my understanding) the code as part of wikka might lead to problems. Just food for thought.'' --GmBowen
Additions:
''JW, an interesting syntax for tabular data is used by [[http://wiki.cs.cityu.edu.hk/CitiWiki/CitiWiki CitiWiki]] (adapted from [[http://comawiki.martignier.net/ ComaWiki]]): [[http://wiki.cs.cityu.edu.hk/CitiWiki/HelpMeTable HelpMeTable]] -- DarTar''
Additions:
Picking up on Sam's point....perhaps code written for wikka that does something like this.....
http://131.202.167.33/wiki/wakka.php?wakka=TableMaker -- GmBowen
http://131.202.167.33/wiki/wakka.php?wakka=TableMaker -- GmBowen
Additions:
[[http://flexwiki.com/ FlexWiki]]* has a rich table markup that seems fairly easy to use. See [[http://www.flexwiki.com/default.aspx/FlexWiki.FormattingRules FormattingRules]] for the basics and [[http://www.flexwiki.com/default.aspx/FlexWiki.TableFormattingRules TableFormattingRules]] for the details. I'd like us to adopt at least the basics, and maybe add some of the extended possibilities gradually.
* (MS open source! And with Ward Cunningham apparently working for MS now...)
--JavaWoman
* (MS open source! And with Ward Cunningham apparently working for MS now...)
--JavaWoman
Additions:
Tables were one of the biggest reasons for us wanting to go with Wikka over our existing WakkaWiki. However the syntax as it is right now is pretty unintuitive. Having one giant string of comma separated values just doesn't work for me. It would be nice to at least make it so you can add line breaks between rows. -- Justin F
Additions:
==User page==
If someone registers as a new user and chooses a Wikiname, his wikinamepage is empty. I think it would be nice, if the page whould be created from the wiki, containing a text with perhaps a welcome, some (Wiki)rules and usefull pages (this text should be stored somewhere so that it could be customized from the WikiAdmin). The page should automatically belong to the category user. Regards, NilsLindenberg
If someone registers as a new user and chooses a Wikiname, his wikinamepage is empty. I think it would be nice, if the page whould be created from the wiki, containing a text with perhaps a welcome, some (Wiki)rules and usefull pages (this text should be stored somewhere so that it could be customized from the WikiAdmin). The page should automatically belong to the category user. Regards, NilsLindenberg
Additions:
=== Bugs vs. feature suggestions ===
<<Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
<<::c::
---
<<Please post issues/bugs to the appropriate page:
~-General bugs/issues: WikkaBugs
~-CSS layout issues: WikkaCSS
<<::c::
---
Deletions:
I found that bits of code sometimes are rendered hard to understand, with both loss of original indents and line wrapping. The cause is 1) inheritance of the body's "justify" text alignment, and 2) the fact that lines are allowed to wrap (overflow: auto; doesn't prevent this).
My suggested solution is the following change for the code class in wikka.css:
.code {
color: black;
background: #ffffee;
border: 1px solid #888;
font: 11px "Bitstream Vera Sans Mono","Courier New", monospace;
width: 95%;
margin:auto;
padding: 3px;
text-align: left; /* override justify on body */
overflow: auto; /* allow scroll bar in case of long lines - goes together with white-space: nowrap! */
white-space: nowrap; /* prevent line wrapping */
}
(BTW, a formatter for css would be nice ;-)))
-- JavaWoman
== Alternate stylesheets ==
I really appreciate alternate stylesheets (classical one, more elaborated, aso). To allow them to be configured in WikkaWiki, you could just add :
* In wikka.config.php this line (for exampe just after "stylesheet" => "wikka.css", ) :
%% "alternates_stylesheets" => array("wikka1.css" => 'Wikka 1',
"wikka2.css" => 'Wikka 2',
"wikka3.css" => 'Wikka 3'),%%
* in header.php this two lines just after the last link and before the "style" box :
%%<?php
// Alternate links
foreach ($this->GetConfigValue("alternates_stylesheets") as $alternate_css => $alternate_name)
{
echo '<link rel="alternate stylesheet" type="text/css" href="' . $css_path . $alternate_css . '" media="screen" title="' . $alternate_name . '" />';
}
(I've too added a $css_path variable, %%$css_path = 'css/';%%)
I don't thing that various "media=print" CSS would be really usefull.
Of course you need a brower like FireFox / Mozilla to easily switch them, otherwise you have to take care of the stylesheets' switch directly in your pages [ see http://www.openweb.eu.org/ for example ].
--SergiO
Additions:
==Better code rendering==
I found that bits of code sometimes are rendered hard to understand, with both loss of original indents and line wrapping. The cause is 1) inheritance of the body's "justify" text alignment, and 2) the fact that lines are allowed to wrap (overflow: auto; doesn't prevent this).
My suggested solution is the following change for the code class in wikka.css:
.code {
color: black;
background: #ffffee;
border: 1px solid #888;
font: 11px "Bitstream Vera Sans Mono","Courier New", monospace;
width: 95%;
margin:auto;
padding: 3px;
text-align: left; /* override justify on body */
overflow: auto; /* allow scroll bar in case of long lines - goes together with white-space: nowrap! */
white-space: nowrap; /* prevent line wrapping */
}
(BTW, a formatter for css would be nice ;-)))
-- JavaWoman
I found that bits of code sometimes are rendered hard to understand, with both loss of original indents and line wrapping. The cause is 1) inheritance of the body's "justify" text alignment, and 2) the fact that lines are allowed to wrap (overflow: auto; doesn't prevent this).
My suggested solution is the following change for the code class in wikka.css:
.code {
color: black;
background: #ffffee;
border: 1px solid #888;
font: 11px "Bitstream Vera Sans Mono","Courier New", monospace;
width: 95%;
margin:auto;
padding: 3px;
text-align: left; /* override justify on body */
overflow: auto; /* allow scroll bar in case of long lines - goes together with white-space: nowrap! */
white-space: nowrap; /* prevent line wrapping */
}
(BTW, a formatter for css would be nice ;-)))
-- JavaWoman
Additions:
The "spreadsheet" (or, interactive table if you want) script uses a MYSQL table with the spreadsheet assigned by default to the page name & owner (which has to match the logged in user), although the logged in user can "force" another table name. Another "action" script allows just showing the table without the interactive nature. So the user can enter the table components using the "spreadsheet", and then show it on the page using the "showtable name=" script. The spreadsheet script allows one to calculate sum, average, count, and frequency (at this point only on the columns) and is intended to provide simple on-line spreadsheet functions for kids working on science projects which they can then embed in a written report. I'm moving the server right now which is why it isn't up. It will be in the next week. The script is a (greatly) modified version of one available from this site...http://www.ka.sara.nl/home/boven/ .... Because it's intended for kids it is reasonably user friendly, although lacking many formatting abilities that "adult" users are used to -- Mike Bowen
If you want to work with individual cells, it sounds like you're thinking about something like this.... http://www.ycode.com/SpreadSheet/Latest/yCode_spreadSheet_simple.htm ... although it is not open source. Just providing the link for discussion purposes. -- Mike B
If you want to work with individual cells, it sounds like you're thinking about something like this.... http://www.ycode.com/SpreadSheet/Latest/yCode_spreadSheet_simple.htm ... although it is not open source. Just providing the link for discussion purposes. -- Mike B
Deletions:
Additions:
The "spreadsheet" (or, interactive table if you want) script uses a MYSQL table assigned by default to the page name, although the logged in user can "force" another table name. Another "action" script allows just showing the table without the interactive nature. So the user can enter the table components using the "spreadsheet", and then show it on the page using the "showtable name=" script. The script allows one to calculate sum, average, count, and frequency (at this point only on the columns) and is intended to provide simple on-line spreadsheet functions for kids working on science projects which they can then embed in a written report. I'm moving the server right now which is why it isn't up. It will be in the next week. The script is a (greatly) modified version of one available from this site...http://www.ka.sara.nl/home/boven/ .... Because it's intended for kids it is reasonably user friendly, although lacking many formatting abilities that "adult" users are used to -- Mike
Deletions:
Additions:
It uses a MYSQL table assigned by default to the page name, although the logged in user can "force" another table name. Another "action" script allows just showing the table without the interactive nature. So the user can enter the table components using the "spreadsheet", and then show it on the page using the "showtable name=" script. I'm moving the server right now which is why it isn't up. It will be in the next few days. The script is a (greatly) modified version of one available from this site...http://www.ka.sara.nl/home/boven/ -- Mike
Additions:
''I haven't checked this out yet, but doesn't UsingHTML pretty much solve the problem on table syntax? Now it's just figuring out how to edit a cell without editting a page.'' --Sam
Additions:
''My 2 cents on tables. I think we should consider in the long run the possibility of a major refactoring of the syntax for tabular data. The current table action is extremely user-unfriendly (just have a look at the source of ConfigurationOptions). Moreover, the table action does not convert wikka-formatted strings, which in some cases is a little annoying. It think a nice idea would be to have tables directly handled in the formatter, instead of using an action. I like very much the [[http://wackowiki.com/WackoDocumentation/WackoFormatting?v=11ij#h7705-8 wacko approach]] to tables, maybe we could do even better and find a more intuitive syntax.'' -- DarTar
Deletions:
-- DarTar
Additions:
''My 2 cents on tables. I think we should consider in the long run the possibility of a major refactoring of the syntax for tabular data. The current table action is extremely user-unfriendly (just have a look at the source of ConfigurationOptions). Moreover, the table action does not convert wikka-formatted strings, which in some cases is a little annoying. It think a nice idea would be to have tables directly handled in the formatter, instead of using an action. I like very much the [[http://wackowiki.com/WackoDocumentation/WackoFormatting?v=11ij#h7705-8 wacko approach]] to tables, maybe we could do even better and find a more intuitive syntax"".
Deletions:
Additions:
''My 2 cents on tables. I think we should consider in the long run the possibility of a major refactoring of the syntax for tabular data. The current table action is extremely user-unfriendly (just have a look at the source of ConfigurationOptions). Moreover, the table action does not convert wikka-formatted strings, which in some cases is a little annoying. It think a nice idea would be to have tables directly handled in the formatter, instead of using an action. I like very much the [[http://wackowiki.com/WackoDocumentation/WackoFormatting?v=11ij#h7705-8 wacko approach]] to tables, maybe we could do even better and find a more intuitive syntax.
-- DarTar
-- DarTar
Deletions:
Additions:
''My 2 cents on tables. I think we should consider in the long run the possibility of a major refactoring of the syntax for tabular data. The current table action is extremely user-unfriendly (just have a look at the source of ConfigurationOptions). It think a nice idea would be to have tables directly handled in the formatter, instead of using an action. I like very much the [[http://wackowiki.com/WackoDocumentation/WackoFormatting?v=11ij#h7705-8 wacko approach]] to tables, maybe we could do even better and find a more intuitive syntax.'' -- DarTar
Additions:
''GmBowen had something related [[http://216.239.59.104/search?q=cache:yQ1M5p3RTfoJ:bowen4-srv.lakeheadu.ca/wikitxt/wakka.php%3Fwakka%3DHomePage+cejhsst&hl=en here]]. I can't seem to get his page to load, therefore I've linked it to its google-cache. Basically, it's a form input thing that allows you to create tables row by row and edit data cell by cell. Very tedious to initialise, but i suppose it could be handy just to click on celldata to edit it (and view data if the user has readonly access). This method is a lot more intuitive than the current method of creating tables, but it would involve flatdb (or a new/seperate mysql schema). Just adding to the discussion, I don't believe that this suggestion is the ultimate solution.'' -- Sam
Additions:
''Can you post a link to a site where you can enter data without editing the page? I'm not sure what that would look like.'' - JsnX
Additions:
I don't know if this goes against the Wiki way of doing things, but it would be nice to configure a table in which users could enter data into and then 'submit' (click a submit button I suppose) and have it saved to the page without having to 'edit page'.
Deletions:
Additions:
==Editable tables==
I don't know if this goes agains the Wiki way of doing things, but it would be nice to configure a table in which users could enter data into and then 'submit' (click a submit button I suppose) and have it saved to the page without having to 'edit page'.
--ArisStathakis
I don't know if this goes agains the Wiki way of doing things, but it would be nice to configure a table in which users could enter data into and then 'submit' (click a submit button I suppose) and have it saved to the page without having to 'edit page'.
--ArisStathakis
Additions:
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'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)
Additions:
''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
Additions:
==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)
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)
Additions:
Right. I see it does work. ;) Somewhat, um, counterintuitive, though. So I guess my suggestion then becomes that when a user configuration is changed, this change should immediately be stored in the user session/cookie so it's active right from that moment (without closing the browser). That would, I think, be more in line with expected behavior. Possible? (I haven't looked at that area of the code yet.)
JavaWoman.
JavaWoman.
Revision [1374]
Edited on 2004-09-23 22:40:22 by JsnX [comments by default works.... non-intuitively]Additions:
It does work.... just not as might be expected. Comment preference is stored for each page as you browse the wiki. So, if you browse a few pages with comments not showing, it remembers this. Then if you update your preferences and return to the same pages, it still remembers that your previous preference was not to see comments on those pages.
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Try this:
- Browse to UserSettings and check off "Show comments by default" and click "Update Settings".
- Now **close all browser windows**
- Open back up your browser and go to the same pages......
- Comments are now showing by default, right?
- JsnX
Revision [1370]
Edited on 2004-09-23 10:38:39 by JavaWoman [comments by default works.... non-intuitively]Additions:
==showing comments==
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
Working on a test installation, I found the user setting "Show comments by default" did not work. Testing it here, I found it doesn't work here, either.
Haven't dug in the code yet to find where this should happen (but will).
I'm quite happy with Wikka's capabilities out of the box - good starting point! :) I'll likely stay with it - but I'll probably make some extensions... (such as an option to require confirmation of a registration before allowing edit access - validates email).
Great work! JavaWoman
Revision [1344]
Edited on 2004-09-21 03:34:04 by 69-172-39-3.frdrmd.adelphia.net [comments by default works.... non-intuitively]Additions:
==Language support==
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
I was searching almost whole site to check what kind of languages are supported by this wiki. I was unsuccessful. Is it possible to put somewhere (main page, release note, futures section…) some information about languages they are supported?
Thanks MDD
Revision [1278]
Edited on 2004-09-17 00:04:26 by karren-goodnough.educ.unb.ca [comments by default works.... non-intuitively]Additions:
It occurs to me that some kind of "counter" for how many times the wikipage has been viewed might be a useful "action" for somebody to be able to use...this way a page author would know how often somebody has gone to the page & this might help focus development (especially for those keeners that have multiple pages/projects). [and I agree with the contributor below....Wikkawiki is great software]
Deletions:
Revision [1277]
Edited on 2004-09-17 00:04:11 by karren-goodnough.educ.unb.ca [comments by default works.... non-intuitively]Additions:
It occurs to me that some kind of "counter" for how many times the wikipage has been viewed might be a useful "action" for somebody to be able to use...this way a page author would know how often somebody has gone to the page & this might help focus development (especially for those keeners that have multiple pages/projects). [[and I agree with the contributor below....Wikkawiki is great software]]
Deletions:
Revision [1276]
Edited on 2004-09-17 00:03:34 by karren-goodnough.educ.unb.ca [comments by default works.... non-intuitively]Additions:
It occurs to me that some kind of "counter" for how many times the wikipage has been viewed might be a useful "action" for somebody to be able to use...this way a page author would know how often somebody has gone to the page & this might help focus development (especially for those keeners that have multiple pages/projects).
Revision [1150]
Edited on 2004-09-08 11:09:37 by pcp03216073pcs.elkton01.md.comcast.net [comments by default works.... non-intuitively]Additions:
== Kudos! Excellent software!==
I wanted to add some functionality to my WakkaWiki site, but found that they disappeared. Upgrading to Wikka gave me all the features that I wanted, and a bunch more.
Good job all!
-- [[http://wiki.gednet.com Jeff]]
I wanted to add some functionality to my WakkaWiki site, but found that they disappeared. Upgrading to Wikka gave me all the features that I wanted, and a bunch more.
Good job all!
-- [[http://wiki.gednet.com Jeff]]
Additions:
this note is shown in some lists like the RecentChanges and the page revisions. it's just a little helper to keep the wiki organized and has no effect on the page itself. use it whenever you can to drop a short abstract of what has changed, even if you have corrected some typos to let others know that no essential changes were made. it is a really useful feature --DreckFehler
Additions:
== 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 ... ;-)
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
== Question: PHP 4.3. and "mysql_escape_string()"? ==
== Problem: Five Line Breaks ==
Not worth to mention but now I am here I write it. Text in the search field is a little bit scrollable. Again ... ;-)
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work.
== Question: PHP 4.3. and "mysql_escape_string()"? ==
== Problem: Five Line Breaks ==
Deletions:
== PHP 4.3. ==
== Five Line Breaks Problem ==
Additions:
For the Wikka Wakka Wiki 1.1.4.0 you need at least PHP 4.3 because the "mysql_real_escape_string()" in wakka.php is only available in PHP 4.3. A lot of hoster just offering PHP 4.1 or 4.2. Then you have to replace "mysql_real_escape_string()" with "mysql_escape_string()". What was the reason for the replacement in the new release? Again: Keep on the good work.
Deletions:
Additions:
For the Wikka Wakka Wiki 1.1.4.0 you need at least PHP 4.3 because the "mysql_real_escape_string()" in wakka.php is only available in PHP 4.3. A lot of hoster just offering PHP 4.1 or 4.2. Then you have to replace "mysql_real_escape_string()" with "mysql_escape_string()". What was the reason for the replacement in the new Release? Again: Keep on the good work.
Deletions:
Additions:
== Question: note? ==
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work. ;-)
-- SkyWalk
-- SkyWalk
-- SkyWalk
It is me again! What is the function of the "Please add a note on your edit" - field? Again and again: Keep on the good work. ;-)
-- SkyWalk
-- SkyWalk
-- SkyWalk
Deletions:
-- Skywalk
Additions:
For the Wikka Wakka Wiki 1.1.4.0 you need at least PHP 4.3 because the "mysql_real_escape_string()" in wakka.php is only available in PHP 4.3. A lot of hoster just offering PHP 4.1 or 4.2. Then you have to replace "mysql_real_escape_string()" with "mysql_escape_string()". Again: Keep on the good work.
== Five Line Breaks Problem ==
== Five Line Breaks Problem ==
Deletions:
Again: Keep on the good work
==Five Line Breaks Problem==
Additions:
== PHP 4.3. ==
For the Wikka Wakka Wiki 1.1.4.0 you need at least PHP 4.3 because the "mysql_real_escape_string()" in wakka.php is only available in PHP 4.3. A lot of hoster just offering PHP 4.1 or 4.2. Then you have to replace "mysql_real_escape_string()" with "mysql_escape_string()". Then Wikka Wakka Wiki 1.1.4.0 works.
Again: Keep on the good work
-- Skywalk
-- Skywalk
For the Wikka Wakka Wiki 1.1.4.0 you need at least PHP 4.3 because the "mysql_real_escape_string()" in wakka.php is only available in PHP 4.3. A lot of hoster just offering PHP 4.1 or 4.2. Then you have to replace "mysql_real_escape_string()" with "mysql_escape_string()". Then Wikka Wakka Wiki 1.1.4.0 works.
Again: Keep on the good work
-- Skywalk
-- Skywalk
Revision [1080]
Edited on 2004-08-30 08:34:49 by p508183A9.dip0.t-ipconnect.de [note on the input field "note"]Additions:
==Five Line Breaks Problem==
Just a small problem i found. If you insert five line breaks at the end of a site, the footer jumps into the box.
Just a small problem i found. If you insert five line breaks at the end of a site, the footer jumps into the box.
Deletions:
Just a small problem i found. If you insert three line breaks at the end of a site, the footer jumps into the box.
Revision [1079]
Edited on 2004-08-30 08:32:31 by p508183A9.dip0.t-ipconnect.de [note on the input field "note"]Additions:
====Suggestion Box====
Feedback is welcomed and appreciated. Use the form or edit this page.
{{feedback}}
----
==Three Line Breaks Problem==
Just a small problem i found. If you insert three line breaks at the end of a site, the footer jumps into the box.
After all a nice wikki. Keep on the good work.
----
== 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
----
== Alternate stylesheets ==
I really appreciate alternate stylesheets (classical one, more elaborated, aso). To allow them to be configured in WikkaWiki, you could just add :
* In wikka.config.php this line (for exampe just after "stylesheet" => "wikka.css", ) :
%% "alternates_stylesheets" => array("wikka1.css" => 'Wikka 1',
"wikka2.css" => 'Wikka 2',
"wikka3.css" => 'Wikka 3'),%%
* in header.php this two lines just after the last link and before the "style" box :
%%<?php
// Alternate links
foreach ($this->GetConfigValue("alternates_stylesheets") as $alternate_css => $alternate_name)
{
echo '<link rel="alternate stylesheet" type="text/css" href="' . $css_path . $alternate_css . '" media="screen" title="' . $alternate_name . '" />';
}
?>%%
(I've too added a $css_path variable, %%$css_path = 'css/';%%)
I don't thing that various "media=print" CSS would be really usefull.
Of course you need a brower like FireFox / Mozilla to easily switch them, otherwise you have to take care of the stylesheets' switch directly in your pages [ see http://www.openweb.eu.org/ for example ].
--SergiO
----
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**
%%
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
%%
// $body = str_replace(" ", "\t", $body);
%%
----
- Wikka is the best ever. Keep up the good work! ;)
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
''//Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX//''
- See MarkHissinkMuller for things I would like to see in Wakka/Wacko/Wikka. Feel free to add/discuss.
- 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
----
- 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
----
- 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.
- 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.
----
====Resolved Suggestions====
**Mod rewrite and a problem**
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough?
''Good catch. Adding the end slash should be fine. It will be added by default in the next Wikka release. -- Jsnx''
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. -- JockeAndersson
''Jocke, in the style sheet [wikka.css by default], add "text-decoration: none;" to the smallprint style. Or am I not understanding the problem? -- JsnX''
~~~.smallprint a {
~~~color: #987;
~~~text-decoration: none;
~~~}
It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
The reason the above addition to smallprint doesn't work is that the links are visited meaning the pseudo-class a:visited must be defined as well with "text-decoration: none" in it. There is no definition for a:visited in the css by default. Perhaps this should be added to Wikka's code? -- JockeAndersson
Sure, I'll add it. Just curious though, what web browser are you using? Internet Explorer does not show underlined links as you have described...at least not for me. -- JsnX
I'm currently using Mozilla Firefox, but I'm testing pages in IE as well. The underlines were only visible in Firefox. IE is usually the one to screw up page rendering, not being fully standards-compliant and all. Oh, and the code could use an a:active definition as well. Be sure to define them in correct order though: a visited hover active. W3C were specific about that for some reason. -- JockeAndersson
Thanks for the tip. By the way, your site looks awesome. -- JsnX
You really think so? Thanks!! :) Much of the general layout comes from A List Apart's site, but adapted to my needs. I've had a site running for a while but can't find the time to update it properly. I believe Wikka will change all that and am seriously thinking of replacing my ordinary site with a Wikka wiki. The forum will still be phpbb, but the site itself could really benefit from the pros of Wikka. I second [[MarkHissinkMuller MarkHissinkMullers]] suggestions for improvement. Especially the possibility to manage ACLs based on user groups as well as individual users, would be great. -- JockeAndersson
----
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action (LOL) if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}""). -- Mike Bowen
----
I use stylesheet for xml, I don't know anything about compatibility to validators :
Add this to, for example handler/page/revisions.xml.php:
%%(php)<?php
$xml = "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n";
$xml .= '<?xml-stylesheet href="' . $this->GetConfigValue("base_url") .'/css/xml.css" type="text/css"?' .">\n";
?>%%
Add a file named xml.css in css/, the content is like XmlStyleSheet
--DotMG
----
CategoryWikka
Feedback is welcomed and appreciated. Use the form or edit this page.
{{feedback}}
----
==Three Line Breaks Problem==
Just a small problem i found. If you insert three line breaks at the end of a site, the footer jumps into the box.
After all a nice wikki. Keep on the good work.
----
== 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
----
== Alternate stylesheets ==
I really appreciate alternate stylesheets (classical one, more elaborated, aso). To allow them to be configured in WikkaWiki, you could just add :
* In wikka.config.php this line (for exampe just after "stylesheet" => "wikka.css", ) :
%% "alternates_stylesheets" => array("wikka1.css" => 'Wikka 1',
"wikka2.css" => 'Wikka 2',
"wikka3.css" => 'Wikka 3'),%%
* in header.php this two lines just after the last link and before the "style" box :
%%<?php
// Alternate links
foreach ($this->GetConfigValue("alternates_stylesheets") as $alternate_css => $alternate_name)
{
echo '<link rel="alternate stylesheet" type="text/css" href="' . $css_path . $alternate_css . '" media="screen" title="' . $alternate_name . '" />';
}
?>%%
(I've too added a $css_path variable, %%$css_path = 'css/';%%)
I don't thing that various "media=print" CSS would be really usefull.
Of course you need a brower like FireFox / Mozilla to easily switch them, otherwise you have to take care of the stylesheets' switch directly in your pages [ see http://www.openweb.eu.org/ for example ].
--SergiO
----
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**
%%
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
%%
// $body = str_replace(" ", "\t", $body);
%%
----
- Wikka is the best ever. Keep up the good work! ;)
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
''//Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX//''
- See MarkHissinkMuller for things I would like to see in Wakka/Wacko/Wikka. Feel free to add/discuss.
- 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
----
- 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
----
- 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.
- 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.
----
====Resolved Suggestions====
**Mod rewrite and a problem**
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough?
''Good catch. Adding the end slash should be fine. It will be added by default in the next Wikka release. -- Jsnx''
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. -- JockeAndersson
''Jocke, in the style sheet [wikka.css by default], add "text-decoration: none;" to the smallprint style. Or am I not understanding the problem? -- JsnX''
~~~.smallprint a {
~~~color: #987;
~~~text-decoration: none;
~~~}
It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
The reason the above addition to smallprint doesn't work is that the links are visited meaning the pseudo-class a:visited must be defined as well with "text-decoration: none" in it. There is no definition for a:visited in the css by default. Perhaps this should be added to Wikka's code? -- JockeAndersson
Sure, I'll add it. Just curious though, what web browser are you using? Internet Explorer does not show underlined links as you have described...at least not for me. -- JsnX
I'm currently using Mozilla Firefox, but I'm testing pages in IE as well. The underlines were only visible in Firefox. IE is usually the one to screw up page rendering, not being fully standards-compliant and all. Oh, and the code could use an a:active definition as well. Be sure to define them in correct order though: a visited hover active. W3C were specific about that for some reason. -- JockeAndersson
Thanks for the tip. By the way, your site looks awesome. -- JsnX
You really think so? Thanks!! :) Much of the general layout comes from A List Apart's site, but adapted to my needs. I've had a site running for a while but can't find the time to update it properly. I believe Wikka will change all that and am seriously thinking of replacing my ordinary site with a Wikka wiki. The forum will still be phpbb, but the site itself could really benefit from the pros of Wikka. I second [[MarkHissinkMuller MarkHissinkMullers]] suggestions for improvement. Especially the possibility to manage ACLs based on user groups as well as individual users, would be great. -- JockeAndersson
----
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action (LOL) if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}""). -- Mike Bowen
----
I use stylesheet for xml, I don't know anything about compatibility to validators :
Add this to, for example handler/page/revisions.xml.php:
%%(php)<?php
$xml = "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n";
$xml .= '<?xml-stylesheet href="' . $this->GetConfigValue("base_url") .'/css/xml.css" type="text/css"?' .">\n";
?>%%
Add a file named xml.css in css/, the content is like XmlStyleSheet
--DotMG
----
CategoryWikka
Deletions:
Feedback is welcomed and appreciated. Use the form or edit this page.
{{feedback}}
----
== 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
----
== Alternate stylesheets ==
I really appreciate alternate stylesheets (classical one, more elaborated, aso). To allow them to be configured in WikkaWiki, you could just add :
* In wikka.config.php this line (for exampe just after "stylesheet" => "wikka.css", ) :
%% "alternates_stylesheets" => array("wikka1.css" => 'Wikka 1',
"wikka2.css" => 'Wikka 2',
"wikka3.css" => 'Wikka 3'),%%
* in header.php this two lines just after the last link and before the "style" box :
%%<?php
// Alternate links
foreach ($this->GetConfigValue("alternates_stylesheets") as $alternate_css => $alternate_name)
{
echo '<link rel="alternate stylesheet" type="text/css" href="' . $css_path . $alternate_css . '" media="screen" title="' . $alternate_name . '" />';
}
?>%%
(I've too added a $css_path variable, %%$css_path = 'css/';%%)
I don't thing that various "media=print" CSS would be really usefull.
Of course you need a brower like FireFox / Mozilla to easily switch them, otherwise you have to take care of the stylesheets' switch directly in your pages [ see http://www.openweb.eu.org/ for example ].
--SergiO
----
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**
%%
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
%%
// $body = str_replace(" ", "\t", $body);
%%
----
- Wikka is the best ever. Keep up the good work! ;)
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
''//Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX//''
- See MarkHissinkMuller for things I would like to see in Wakka/Wacko/Wikka. Feel free to add/discuss.
- 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
----
- 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
----
- 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.
- 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.
----
====Resolved Suggestions====
**Mod rewrite and a problem**
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough?
''Good catch. Adding the end slash should be fine. It will be added by default in the next Wikka release. -- Jsnx''
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. -- JockeAndersson
''Jocke, in the style sheet [wikka.css by default], add "text-decoration: none;" to the smallprint style. Or am I not understanding the problem? -- JsnX''
~~~.smallprint a {
~~~color: #987;
~~~text-decoration: none;
~~~}
It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
The reason the above addition to smallprint doesn't work is that the links are visited meaning the pseudo-class a:visited must be defined as well with "text-decoration: none" in it. There is no definition for a:visited in the css by default. Perhaps this should be added to Wikka's code? -- JockeAndersson
Sure, I'll add it. Just curious though, what web browser are you using? Internet Explorer does not show underlined links as you have described...at least not for me. -- JsnX
I'm currently using Mozilla Firefox, but I'm testing pages in IE as well. The underlines were only visible in Firefox. IE is usually the one to screw up page rendering, not being fully standards-compliant and all. Oh, and the code could use an a:active definition as well. Be sure to define them in correct order though: a visited hover active. W3C were specific about that for some reason. -- JockeAndersson
Thanks for the tip. By the way, your site looks awesome. -- JsnX
You really think so? Thanks!! :) Much of the general layout comes from A List Apart's site, but adapted to my needs. I've had a site running for a while but can't find the time to update it properly. I believe Wikka will change all that and am seriously thinking of replacing my ordinary site with a Wikka wiki. The forum will still be phpbb, but the site itself could really benefit from the pros of Wikka. I second [[MarkHissinkMuller MarkHissinkMullers]] suggestions for improvement. Especially the possibility to manage ACLs based on user groups as well as individual users, would be great. -- JockeAndersson
----
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action (LOL) if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}""). -- Mike Bowen
----
I use stylesheet for xml, I don't know anything about compatibility to validators :
Add this to, for example handler/page/revisions.xml.php:
%%(php)<?php
$xml = "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n";
$xml .= '<?xml-stylesheet href="' . $this->GetConfigValue("base_url") .'/css/xml.css" type="text/css"?' .">\n";
?>%%
Add a file named xml.css in css/, the content is like XmlStyleSheet
--DotMG
----
CategoryWikka
Additions:
I use stylesheet for xml, I don't know anything about compatibility to validators :
Add this to, for example handler/page/revisions.xml.php:
%%(php)<?php
$xml = "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n";
$xml .= '<?xml-stylesheet href="' . $this->GetConfigValue("base_url") .'/css/xml.css" type="text/css"?' .">\n";
Add a file named xml.css in css/, the content is like XmlStyleSheet
--DotMG
Add this to, for example handler/page/revisions.xml.php:
%%(php)<?php
$xml = "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n";
$xml .= '<?xml-stylesheet href="' . $this->GetConfigValue("base_url") .'/css/xml.css" type="text/css"?' .">\n";
Add a file named xml.css in css/, the content is like XmlStyleSheet
--DotMG
Additions:
== 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
--SergiO
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
--SergiO
Revision [950]
Edited on 2004-08-10 02:37:25 by ppp15.adsl89.pacific.net.au [note on the input field "note"]Additions:
- 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.
- 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.
- 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.
- 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.
Additions:
Of course you need a brower like FireFox / Mozilla to easily switch them, otherwise you have to take care of the stylesheets' switch directly in your pages [ see http://www.openweb.eu.org/ for example ].
Additions:
== Alternate stylesheets ==
I really appreciate alternate stylesheets (classical one, more elaborated, aso). To allow them to be configured in WikkaWiki, you could just add :
* In wikka.config.php this line (for exampe just after "stylesheet" => "wikka.css", ) :
%% "alternates_stylesheets" => array("wikka1.css" => 'Wikka 1',
"wikka2.css" => 'Wikka 2',
"wikka3.css" => 'Wikka 3'),%%
* in header.php this two lines just after the last link and before the "style" box :
%%<?php
// Alternate links
foreach ($this->GetConfigValue("alternates_stylesheets") as $alternate_css => $alternate_name)
{
echo '<link rel="alternate stylesheet" type="text/css" href="' . $css_path . $alternate_css . '" media="screen" title="' . $alternate_name . '" />';
}
?>%%
(I've too added a $css_path variable, %%$css_path = 'css/';%%)
I don't thing that various "media=print" CSS would be really usefull.
I really appreciate alternate stylesheets (classical one, more elaborated, aso). To allow them to be configured in WikkaWiki, you could just add :
* In wikka.config.php this line (for exampe just after "stylesheet" => "wikka.css", ) :
%% "alternates_stylesheets" => array("wikka1.css" => 'Wikka 1',
"wikka2.css" => 'Wikka 2',
"wikka3.css" => 'Wikka 3'),%%
* in header.php this two lines just after the last link and before the "style" box :
%%<?php
// Alternate links
foreach ($this->GetConfigValue("alternates_stylesheets") as $alternate_css => $alternate_name)
{
echo '<link rel="alternate stylesheet" type="text/css" href="' . $css_path . $alternate_css . '" media="screen" title="' . $alternate_name . '" />';
}
?>%%
(I've too added a $css_path variable, %%$css_path = 'css/';%%)
I don't thing that various "media=print" CSS would be really usefull.
Additions:
Feedback is welcomed and appreciated. Use the form or edit this page.
{{feedback}}
{{feedback}}
Deletions:
Proposal of an action for sending feedback to the administrator: FeedbackAction
--DarTar
I moved [[DarTar here]] my modifications/feature suggestions (**logged user homepage**, **hidden referrer link**, **automatic login/logout redirection**): feel free to edit/comment this page.
-- DarTar
Additions:
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.
Deletions:
Additions:
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 ;) ). 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
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
Additions:
- 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.
Sorry if this was the wrong place for posting this, and feel free to move it to a more appropriate one.
Deletions:
Additions:
- Not a suggestion, but problems: with installing 1.1.3 on a Win32 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 ...) Birgit Kellner (birgit.kellner@univie.ac.at) Sorry if this was the wrong place for posting this, and feel free to move it to a more appropriate one.
Deletions:
Additions:
Hi, I'm having problems with installing 1.1.3 on a Win32 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 ...) Birgit Kellner (birgit.kellner@univie.ac.at) Sorry if this was the wrong place for such detailed installation problems.
Additions:
Proposal of an action for sending feedback to the administrator: FeedbackAction
--DarTar
-- DarTar
--DarTar
-- DarTar
Additions:
I moved [[DarTar here]] my modifications/feature suggestions (**logged user homepage**, **hidden referrer link**, **automatic login/logout redirection**): feel free to edit/comment this page.
Deletions:
Feel free to edit/comment this page.
Additions:
I moved my modifications/feature suggestions to DarTar.
Feel free to edit/comment this page.
Feel free to edit/comment this page.
Deletions:
Here's what can you can do to create two distinct homepages, the first for anonymous visitors, the second for registered users:
~-Add the following line to ##wakka.config.php##: %%(php)"logged_in_homepage" => "IntraNet",%%
~-Make the following modification in ##header.php##:
**original:**
%%(php)<?php echo $this->Link($this->config["root_page"]); ?> ::
**modified:**
%%(php)<?php echo ($this->GetUser() ? $this->Link($this->config["logged_in_homepage"]) :
$this->Link($this->config["root_page"])); ?> ::
You will then need to setup the appropriate ACLs for the ""IntraNet"" page
--DarTar
===Hide referrer link to prevent spam===
A simple workaround discussed with DreckFehler (See comments in: WakkaWiki) to avoid massive linking from spambots. The link to the referrers page is only visible to registered users (and not to search engines). Make the following modification in ##footer.php##:
**original:**
%%(php)<a href="<?php echo $this->href("referrers") ?>"
title="Click to view a list of URLs referring to this page.">Referrers</a> ::
**modified:**
%%(php)<?php echo ($this->GetUser() ? "<a href='".$this->href("referrers")."'>Referrers</a> :: " : "") ?>
--DarTar
===Login/logout redirection===
Here's a small suggestion for the login/logout page.
The idea came while hacking a previous version of wikka to create a content management system with a public, read-only area (with a limited number of visible pages) and a registered-users area giving read&write access to all the pages.
I thought it might be useful to give the site administrator the possibility to automatically redirect logged users to a specific page immediately after the login. Two possible suggestions:
~a)[//Homepage for logged users//] Add a line to ##wakka.config.php##: %%(php)"logged_in_homepage" => "IntraNet",%% and modify the ##usersetting.php## action so as to redirect logged users to ##logged_in_homepage##.
~b)[//Back to original page//] Keep track of the referrer from which the user accesses the login page and redirect her to the page she came from.
Perhaps these options, together with the default one [//Stay on login page//], might be added in ##wakka.config.php##: %%(php)"login_redirect" => "1"
/*
"0" : redirection disabled (stay on UserSetting after login);
"1" : redirect to original page;
"2" : redirect to logged_in_homepage;
*/%%
Same for the logout screen: once I've logged out, I'd like to be redirected to the public version of the page I was editing as a logged user (or to ##root_page##)
%%(php)"logout_redirect" => "1"
/*
"0" : redirection disabled (stay on UserSetting after logout);
"1" : redirect to original page;
"2" : redirect to root_page;
*/%%
Does this interest anyone? Does it raise major security issues?
-- DarTar
Additions:
"0" : redirection disabled (stay on UserSetting after logout);
Additions:
A simple workaround discussed with DreckFehler (See comments in: WakkaWiki) to avoid massive linking from spambots. The link to the referrers page is only visible to registered users (and not to search engines). Make the following modification in ##footer.php##:
Deletions:
Additions:
===Logged Users Homepage===
Here's what can you can do to create two distinct homepages, the first for anonymous visitors, the second for registered users:
~-Add the following line to ##wakka.config.php##: %%(php)"logged_in_homepage" => "IntraNet",%%
~-Make the following modification in ##header.php##:
**original:**
%%(php)<?php echo $this->Link($this->config["root_page"]); ?> ::
**modified:**
%%(php)<?php echo ($this->GetUser() ? $this->Link($this->config["logged_in_homepage"]) :
$this->Link($this->config["root_page"])); ?> ::
You will then need to setup the appropriate ACLs for the ""IntraNet"" page
--DarTar
===Hide referrer link to prevent spam===
A simple workaround discussed with DreckFehler (See comments in: WakkaWiki) to avoid massive linking from spambots. The link to referrer page is only visible to registered users. Make the following modification in ##footer.php##:
**original:**
%%(php)<a href="<?php echo $this->href("referrers") ?>"
title="Click to view a list of URLs referring to this page.">Referrers</a> ::
**modified:**
%%(php)<?php echo ($this->GetUser() ? "<a href='".$this->href("referrers")."'>Referrers</a> :: " : "") ?>
--DarTar
===Login/logout redirection===
~a)[//Homepage for logged users//] Add a line to ##wakka.config.php##: %%(php)"logged_in_homepage" => "IntraNet",%% and modify the ##usersetting.php## action so as to redirect logged users to ##logged_in_homepage##.
Perhaps these options, together with the default one [//Stay on login page//], might be added in ##wakka.config.php##: %%(php)"login_redirect" => "1"
%%(php)"logout_redirect" => "1"
Here's what can you can do to create two distinct homepages, the first for anonymous visitors, the second for registered users:
~-Add the following line to ##wakka.config.php##: %%(php)"logged_in_homepage" => "IntraNet",%%
~-Make the following modification in ##header.php##:
**original:**
%%(php)<?php echo $this->Link($this->config["root_page"]); ?> ::
**modified:**
%%(php)<?php echo ($this->GetUser() ? $this->Link($this->config["logged_in_homepage"]) :
$this->Link($this->config["root_page"])); ?> ::
You will then need to setup the appropriate ACLs for the ""IntraNet"" page
--DarTar
===Hide referrer link to prevent spam===
A simple workaround discussed with DreckFehler (See comments in: WakkaWiki) to avoid massive linking from spambots. The link to referrer page is only visible to registered users. Make the following modification in ##footer.php##:
**original:**
%%(php)<a href="<?php echo $this->href("referrers") ?>"
title="Click to view a list of URLs referring to this page.">Referrers</a> ::
**modified:**
%%(php)<?php echo ($this->GetUser() ? "<a href='".$this->href("referrers")."'>Referrers</a> :: " : "") ?>
--DarTar
===Login/logout redirection===
~a)[//Homepage for logged users//] Add a line to ##wakka.config.php##: %%(php)"logged_in_homepage" => "IntraNet",%% and modify the ##usersetting.php## action so as to redirect logged users to ##logged_in_homepage##.
Perhaps these options, together with the default one [//Stay on login page//], might be added in ##wakka.config.php##: %%(php)"login_redirect" => "1"
%%(php)"logout_redirect" => "1"
Deletions:
~a)[//Homepage for logged users//] Add a line to ##wakka.config.php## specifying %%"logged_in_homepage" => "IntraNet"%% and modify the ##usersetting.php## action so as to redirect logged users to ##logged_in_homepage##.
Perhaps these options, together with the default one [//Stay on login page//], might be added in ##wakka.config.php##: %%"login_redirect" => "1"
%%"logout_redirect" => "1"
Additions:
~a)[//Homepage for logged users//] Add a line to ##wakka.config.php## specifying %%"logged_in_homepage" => "IntraNet"%% and modify the ##usersetting.php## action so as to redirect logged users to ##logged_in_homepage##.
Same for the logout screen: once I've logged out, I'd like to be redirected to the public version of the page I was editing as a logged user (or to ##root_page##)
Same for the logout screen: once I've logged out, I'd like to be redirected to the public version of the page I was editing as a logged user (or to ##root_page##)
Deletions:
Same for the logout screen: once I've logged out, I'd like to be redirected to the public version of the page I was editing as a logged user (or to the root_page)
Additions:
I thought it might be useful to give the site administrator the possibility to automatically redirect logged users to a specific page immediately after the login. Two possible suggestions:
Deletions:
Additions:
~b)[//Back to original page//] Keep track of the referrer from which the user accesses the login page and redirect her to the page she came from.
Deletions:
Additions:
~a)[//Homepage for logged users//] Add a line to ##wakka.config.php## specifying %%"logged_in_homepage" => "IntraNet"%% and modify the ##usersetting.php## action so as to redirect logged users to ""IntraNet"".
~b)[//Back to original page//] Keep track of the referrer from which the user access the login page and redirect her to the page she came from.
Perhaps these options, together with the default one [//Stay on login page//], might be added in ##wakka.config.php##: %%"login_redirect" => "1"
~b)[//Back to original page//] Keep track of the referrer from which the user access the login page and redirect her to the page she came from.
Perhaps these options, together with the default one [//Stay on login page//], might be added in ##wakka.config.php##: %%"login_redirect" => "1"
Deletions:
~b)''[Back to original page]'' Keep track of the referrer from which the user access the login page and redirect her to the page she came from.
Perhaps these options, together with the default one ''[Stay on login page]'', might be added in ##wakka.config.php##: %%"login_redirect" => "1"
Additions:
==Login/logout redirection==
Here's a small suggestion for the login/logout page.
The idea came while hacking a previous version of wikka to create a content management system with a public, read-only area (with a limited number of visible pages) and a registered-users area giving read&write access to all the pages.
I thought it might be useful to give the site administrator the possibility to automatically redirect logged user to a specific page immediately after the login. Two possible suggestions:
~a)''[Homepage for logged users]'' Add a line to ##wakka.config.php## specifying %%"logged_in_homepage" => "IntraNet"%% and modify the ##usersetting.php## action so as to redirect logged users to ""IntraNet"".
~b)''[Back to original page]'' Keep track of the referrer from which the user access the login page and redirect her to the page she came from.
Perhaps these options, together with the default one ''[Stay on login page]'', might be added in ##wakka.config.php##: %%"login_redirect" => "1"
/*
"0" : redirection disabled (stay on UserSetting after login);
"1" : redirect to original page;
"2" : redirect to logged_in_homepage;
*/%%
Same for the logout screen: once I've logged out, I'd like to be redirected to the public version of the page I was editing as a logged user (or to the root_page)
%%"logout_redirect" => "1"
/*
"0" : redirection disabled (stay on UserSetting after login);
"1" : redirect to original page;
"2" : redirect to root_page;
*/%%
Does this interest anyone? Does it raise major security issues?
-- DarTar
Here's a small suggestion for the login/logout page.
The idea came while hacking a previous version of wikka to create a content management system with a public, read-only area (with a limited number of visible pages) and a registered-users area giving read&write access to all the pages.
I thought it might be useful to give the site administrator the possibility to automatically redirect logged user to a specific page immediately after the login. Two possible suggestions:
~a)''[Homepage for logged users]'' Add a line to ##wakka.config.php## specifying %%"logged_in_homepage" => "IntraNet"%% and modify the ##usersetting.php## action so as to redirect logged users to ""IntraNet"".
~b)''[Back to original page]'' Keep track of the referrer from which the user access the login page and redirect her to the page she came from.
Perhaps these options, together with the default one ''[Stay on login page]'', might be added in ##wakka.config.php##: %%"login_redirect" => "1"
/*
"0" : redirection disabled (stay on UserSetting after login);
"1" : redirect to original page;
"2" : redirect to logged_in_homepage;
*/%%
Same for the logout screen: once I've logged out, I'd like to be redirected to the public version of the page I was editing as a logged user (or to the root_page)
%%"logout_redirect" => "1"
/*
"0" : redirection disabled (stay on UserSetting after login);
"1" : redirect to original page;
"2" : redirect to root_page;
*/%%
Does this interest anyone? Does it raise major security issues?
-- DarTar
Additions:
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action (LOL) if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}""). -- Mike Bowen
Deletions:
Additions:
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action (LOL) if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}"").
Deletions:
Additions:
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work like this. You can see it in action if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}"").
Deletions:
Additions:
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work. You can see it in action if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to any single available letter if you wish by adding a parameter, e.g., ""{{pageindex start="C"}}"").
Deletions:
Additions:
I've provided the php code for a modification of the pageindex.php action which will improve showing the index in high-use sites. You can see the code at GmBowen. I'm not a programmer myself, but have one working for me and he modified the code to have it work. You can see it in action if you go to http://bowen4-srv.lakeheadu.ca/wikitxt/wakka.php?wakka=PageIndex (as it's set up it's defaulting to show "all", but you can set that to a single letter if you wish).
Additions:
''Noted. Try commenting out that line for a temporary workaround.'' -- JsnX
// $body = str_replace(" ", "\t", $body);
// $body = str_replace(" ", "\t", $body);
Additions:
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**
%%
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
%%
----------------------------------------------------------------
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**
%%
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
Additions:
- 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
Deletions:
Additions:
You really think so? Thanks!! :) Much of the general layout comes from A List Apart's site, but adapted to my needs. I've had a site running for a while but can't find the time to update it properly. I believe Wikka will change all that and am seriously thinking of replacing my ordinary site with a Wikka wiki. The forum will still be phpbb, but the site itself could really benefit from the pros of Wikka. I second [[MarkHissinkMuller MarkHissinkMullers]] suggestions for improvement. Especially the possibility to manage ACLs based on user groups as well as individual users, would be great. -- JockeAndersson
Additions:
CategoryDevelopment
Additions:
Thanks for the tip. By the way, your site looks awesome. -- JsnX
Additions:
I'm currently using Mozilla Firefox, but I'm testing pages in IE as well. The underlines were only visible in Firefox. IE is usually the one to screw up page rendering, not being fully standards-compliant and all. Oh, and the code could use an a:active definition as well. Be sure to define them in correct order though: a visited hover active. W3C were specific about that for some reason. -- JockeAndersson
Deletions:
Additions:
I'm currently using Mozilla Firefox, but I'm testing pages in IE as well. The underlines were only visible in Firefox. IE is usually the one to screw up page rendering, not being fully standards-compliant and all. -- JockeAndersson
Additions:
Sure, I'll add it. Just curious though, what web browser are you using? Internet Explorer does not show underlined links as you have described...at least not for me. -- JsnX
Additions:
The reason the above addition to smallprint doesn't work is that the links are visited meaning the pseudo-class a:visited must be defined as well with "text-decoration: none" in it. There is no definition for a:visited in the css by default. Perhaps this should be added to Wikka's code? -- JockeAndersson
Additions:
====Suggestion Box====
====Resolved Suggestions====
====Resolved Suggestions====
Deletions:
=====Resolved Suggestions=====
Additions:
=====Resolved Suggestions=====
''Good catch. Adding the end slash should be fine. It will be added by default in the next Wikka release. -- Jsnx''
''Good catch. Adding the end slash should be fine. It will be added by default in the next Wikka release. -- Jsnx''
Additions:
It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
Deletions:
Additions:
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. -- JockeAndersson
- It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
- It doesn't really do it. I tried it before, and I added the code snippet again, but without the wanted result. Where in the code is the underlining set? The header link also has it's text underlined and I can't find where this is set. The stylesheet doesn't contain any such tags, and I can't seem to find them in the other files. -- JockeAndersson
Deletions:
Additions:
''Jocke, in the style sheet [wikka.css by default], add "text-decoration: none;" to the smallprint style. Or am I not understanding the problem? -- JsnX''
Deletions:
Additions:
''Jocke, in your style sheet, add "text-decoration: none;" to the smallprint style. Or am I not understanding the problem? -- JsnX''
~~~.smallprint a {
~~~color: #987;
~~~text-decoration: none;
~~~}
~~~.smallprint a {
~~~color: #987;
~~~text-decoration: none;
~~~}
Additions:
**Mod rewrite and a problem**
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough?
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. --JockeAndersson
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough?
Another thing. I feel a bit stupid for asking, but how do I remove the underline from the links in the footer. This is not set in the style sheet nor added in footer.php. Ot not in a place where I see at least. --JockeAndersson
Deletions:
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough? --JockeAndersson
Additions:
=Mod rewrite and a problem=
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough? --JockeAndersson
Hi there. First, I'd like to thank you all for your work with Wikka -- it's just great! I have some problems though. On my [[www.bronzeworks.org/Wikka/ experimental wikka site]] I'm not able to use mod_rewrite, which is annoying by itself, but when I set the rewrite parameter in the config file to "0", the scripts add an <input> tag to the code at the beginning of the footer (which is a form if I'm correct). This input tag gets no close tag so I added a "/" at the end. Will this screw up things somehow or is this little fix enough? --JockeAndersson
Additions:
- 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.)
Additions:
- See MarkHissinkMuller for things I would like to see in Wakka/Wacko/Wikka. Feel free to add/discuss.
Additions:
''//Richard, thanks for the feedback. It is on my agenda to look at another solution for tables. My plan is to allow straight HTML table syntax after running it through the "safehtml" checker. But I need to check that there are no security risks with this first. Also, I'll take a peak at your suggestion too. -- JsnX//''
Additions:
- I think it would be nice if you could use wikka markup (""**bold**, //italics//, __underline__, etc."") inside of tables. - RichardTerry
Deletions:
Additions:
.
Additions:
- Wikka is the best ever. Keep up the good work! ;)
CategoryWikka
