Revision [4877]

This is an old revision of SuggestionBox made by JavaWoman on 2005-01-19 20:42:21.

 

Suggestion Box

Last edited by JavaWoman:
reply to Mike re: CVS
Wed, 19 Jan 2005 20:42 UTC [diff]

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:

Fill in the form below to send us your comments:








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.


User names

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

I also agree with Nils that it would be really wonderful if some sort of default user page was created when a person creates an account.

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

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


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



Stopping Spammers getting Google Juice
There is a technique to stop spammers from gaining any advantage of spamming, which is to redirect external links to stop them from affecting their PageRank. Great to stop the whole purpose of spamming, but this has the disadvantage that good sites lose their google juice too. Check the comments out on that page for more cons. I've noticed since I enabled this on the Opera 7 wiki that slowly spam volume has dropped out, but I'm not entirely happy at the price paid. Had you thought about this, maybe have it as an option during config? -- IanAndolina



Don't let old pages get indexed
To make absolutely sure old pages don't get archived (irrespective of your robots.txt) - essential to stopping WikiSpam from still getting juice from archived pages, why not make sure to add meta directives to those pages by adding something like:
<?php if ($this->GetMethod() != 'show' || $this->page["latest"] == "N") echo "<meta name=\"robots\" content=\"noindex, nofollow, noarchive\" />\n<meta name=\"googlebot\" content=\"noarchive, noindex, nofollow\">\n";?>

to header.php. This stops pages with handlers other than show or non current pages from any kind of archiving/cacheing.



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



Give control over HTML
It would be nice to see a template engine in Wikka to give the users the full control over the HTML source. Smarty is always a good choice.



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:
--KickTheDonkey


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


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





Compatibility with PHP 4.1.x
(Copied from comment on WikkaInstallation, I support this proposal - and agree that @ in front of a statement should generally be avoided, unless any errors are actually dealt with. (Layout slightly adapted.) --JavaWoman)
with Debian GNU/Linux 3.0 (woody) are installed PHP 4.1.2 and this version don't support "mysql_real_escape_string" function.
temporary fix on wikka.php head:

if ( ! function_exists("mysql_real_escape_string") )
{
    function mysql_real_escape_string($string)
    {
        return mysql_escape_string($string);
    }

}


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


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 &nbsp; 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 &nbsp; 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


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:

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


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 propsing a solution)

A nice contribution Nils. If you want to go further with fiddling with the code for registration, I've thought it would be useful if there was a feature that required a password from an administrator to be able to register so that if you were going to register you put in your user info (as now) and a password you've obtained from the admin that allows you to register....for instance, in this way a teacher could set up a wikki with registration "on" and send a note to all of the parents with the registration password so that they could register....outsiders couldn't register, only those with the registration key. Possibly a quite useful feature to many potential user groups. -- GmBowen

Look at UserRegistration for the first version, or try it --NilsLindenberg


Cookies and logging out
This issue issue moved to StayingLoggedIn!


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.


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.


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


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


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
11:     // replace 4 consecutive spaces with tab character
12:     $body = str_replace("   ", "\t", $body);

Is there any way to make the edit handler leave the spaces alone inside of code blocks?
Thanks! -RichardTerry

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



Wikka markup inside tables
- I think it would be nice if you could use wikka markup (**bold**, //italics//, __underline__, etc.) inside of tables. - RichardTerry


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


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


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

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

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

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






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