Revision [3241]

This is an old revision of SuggestionBox made by ChristianBarthelemy on 2004-12-15 19:00:56.

 

Suggestion Box


Feedback is welcomed and appreciated. Use the form or edit this page.

Fill in the form below to send us your comments:








Bugs vs. feature suggestions


Please post issues/bugs to the appropriate page:
 




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

function SetUser($user) { $_SESSION["user"] = $user; $this->SetPersistentCookie("name", $user["name"]); $this->SetPersistentCookie("password", $user["password"]); }


to

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

Handling the config
I have three questions about the config. See HandlingWikkaConfig.
--NilsLindenberg

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.

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 &#37; 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 &#37&#37 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
  1. 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:

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 == ""&yen;&yen;") 
{
$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:

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


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


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

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


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



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





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


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


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


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
$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
CategoryDevelopment
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki