Revision [7030]
This is an old revision of SuggestionBox made by TimoK on 2005-03-31 11:06:12.
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
- WikkaSpamFighting for spam-related issues
- WikkaWorkarounds for specific platforms
Fill in the form below to send us your comments:
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
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
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 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
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
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
User map
I have copied the proposal for a user map form Category Users to UserMap. --NilsLindenbergPages 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:
- 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:
-- 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 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 personal website. Everything works fine, except that the TextSearch link in the page header (which I masked through CSS - I don't want to hack the code) produces dozens of search results that I really don't want to be cached on Google. Same story applies to the revisions and history links that are cached on search engines: this is what happens in the case of our main server. I'd also would like to avoid default wiki pages (like SandBox, MyPages, UserSettings etc.) to be crawled and cached (simply setting ACLs to !*-!*-!* won't do the job). Maybe we should think of a way to allow the user to decide what kind of content of her Wikka-powered site should be spidered by SE and what content should not. -- DarTar- I think I've suggested before that the SandBox should not be indexed - the way to avoid this would be to add the appropriate meta tag to the page's head. That concept could easily be extended by allowing a WikiAdmin (not the WikiUser!) to define a list of pages where such a meta tag would be inserted. Generating a little text note to the effect for all these pages could also go some way to discourage spammers. --JavaWoman
For Better Overview
1. It often takes too much time to check if a wiki has changed and what has changed. In the case of wikkawiki one has to check RecentChanges as well as RecentlyCommented. A combined page would be more convenient - RicharD- 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 ./.htaccessRewriteCond %{REQUEST_URI} !=/favicon.ico RewriteCond %{REQUEST_URI} !=/robots.txt RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L]
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. -KarmaTesterCategory Icons
Create a table which maintains a mapping between wikka categories and an associated predefined icon graphic. When the directive {category_icon} is used the category's icon is dropped into the page at the location of invocation. -KarmaTester- Karma, we are actually considering the possibility of integrating a set of GPL'ed icons (and the relevant actions/formatters) in Wikka. Stay tuned... -- DarTar
- You're more than welcome to use our icon action and icons: WikiIcons which were copyleft from here. The icons were auto-generated from the SVG versions at various sizes, you can take what you want. Only problem is they are PNG's -great in ANY browser but IE!!! --IanAndolina
- 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:
- open a /raw version of the page;
- 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);
- open a text editor;
- copy the code block;
- paste it in the text editor;
- 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 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 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 wikis from a number of sources.
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
Paragraph instead of line-breaks
(copied from WhatsNew -- DarTar)Why is it that the formatter creates line breaks instead of paragraphs? I've been trying to figure out a way to get Wikka to do this, but it may be nice for there to be some sort of option in a future release. Paragraphs tend to be more useful for doing CSS formatting.
-- ScumBle
+1 — semantically, Wikka's current lack of proper paragraphs and liberal sprinkling of line breaks is really undesirble. I made a hack-mod on my wakka some time ago in formatter/wakka.php (just after the preg_replace_callback):
$pattern2 = "/^(\040|\t)*(?!<|\040)(.+)$/m"; //matches any line with no <element> (and variable leading space) - assume a paragraph
$replace2 = "<p>\\2</p>";
$text=preg_replace($pattern2,$replace2,$text);
$pattern1 = "/^(\040|\t)*(<(?!hr|(\/|)h[1-6]|br|(\/|)li|(\/|)[uo]l|(\/|)div|(\/|)p).*)$/m"; //matches any <element>text lines not considered block formatting
$replace1 = "<p>\\2</p>";
$text=preg_replace($pattern1,$replace1,$text);
$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...
- 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 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 page offers some user contributed hacks which may be a starting point.
MatthewLangham
Create rewrite rules on install
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
- 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)
{
$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:
to
else if (strlen($password) < 5) $error = "Password too short.";
else if ($this->ExistsEmail($email)) $error = "You already have a username.";
- 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. Here and 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 inaccessible 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). --NilsLindenbergBacklinks
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 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 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 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 Smarty could be 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.
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
- 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.
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 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. 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 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 Imarked 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:
- easy to type
- not likely to occur in any programming code (note "likely" - you can never completely exclude it; think of APL!)
-- 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 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 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
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);
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. -RichardTerryInstallation 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 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:
if ( ! function_exists("mysql_real_escape_string") )
{
function mysql_real_escape_string($string)
{
return mysql_escape_string($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, NilsLindenbergNon-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
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
CategoryDevelopment