=====Suggestion Box=====
""
New Wikka Tracker available
We are happy to announce that Wikka has just opened a dedicated issue tracker. We are currently migrating open issues, bugs and feature requests from this site to the new server but this migration isn't complete yet.
Meanwhile, if you have something to report:
First check if your feature suggestion is already being discussed on this page:
- If so: check if it has a link to a tracker ID:
- If so: follow that link and add your comment there
- If not: add your comment to the issue on this page
- If not: please use the issue tracker to report your new feature suggestion.
Thanks for your understanding.
""
::c::
**Issues often asked for**
~-[[CategorySystemOverhaul Categories]]
~-[[WikkaFolksonomy (Technorati) tags & related]]
~-[[WikkaInternationalization Internationalization/Localisation]]
~-[[DateAndTimeFormat Date/Time]]
~-[[WikkaFilters Wikka Exporting/Importing]], [[WikkaToPdf PDF-Export]]
~-[[WikkaOptimization Optimization]]
~-[[TableofcontentsAction Table of contents (TOC)]]
~-[[SectionEditing Section Editing]]
~-[[WikkaSpamFighting Spam (and related issues)]]
~-[[WikkaTables Tables]]
~-TemplateSystem
~-[[WikkaWorkarounds Workarounds for uncommon problems]]
**see also:**
~-UserMap
----
===Language support===
[[Ticket:340]]
----
===Highlight text searched in a page ===
[[Ticket:281]]
----
==Wikka markup inside tables==
[[Ticket:230]]
----
===Is There a way to consolidate a bunch of page updates (the actual content that is) onto one page?===
[[Ticket:259]]
----
===Static HTML for offline browsing===
[[Ticket:177]]
----
===Link en- and disabling in respect to user rights===
[[Ticket:175]]
----
===Edit comments displayed by user rights===
[[Ticket:180]]
----
===Please provide a way to add formatters, that don't get placed in ''===
[[Ticket:176]]
----
===Note on edit, mandatory field===
== Question: note? ==
[[Ticket:114]]
----
===Order of comments===
[[Ticket:115]]
----
===Own comments editing===
[[Ticket:116]]
----
===versioning of attachments===
[[Ticket:118]]
----
===Making PageIndex go faster===
[[Ticket:117]]
----
===Single-click restore of previous versions===
[[Ticket:119]]
----
===Signature===
[[Ticket:121]]
----
===Preview===
[[Ticket:123]]
----
===Generate ID in forms; allow class===
[[Ticket:21]]
----
===Accesskeys for the footer functions===
[[Ticket:73]]
----
===Exclude certain CamelCase words from formatting===
[[Ticket:191]]
----
===Import WikiPedia database===
[[Ticket:192]]
----
===Color Formatting===
[[Ticket:193]]
----
===Separation of Wakka class from wikka.php===
[[Ticket:161]]
----
===Save Pages to PDF Format===
[[Ticket:190]]
----
===showing comments===
[[Ticket:195]]
----
===Local links===
[[Ticket:196]]
----
=== RSS options ===
[[Ticket:197]]
----
===wikiwyg===
[[Ticket:44]]
----
===Google Sitemap===
[[Ticket:210]]
----
===Clearing ACLs===
[[Ticket:211]]
----
===Online editing of mindmaps would be great===
[[Ticket:212]]
----
===""%%"" in code blocks: a possible workaround===
===How to format code to get two % characters without space together?===
[[Ticket:213]]
----
===Robot Friendly Pages===
===Sending 403 headers===
(related to the //Search engine results inflation// item below)
[[Ticket:258]]
----
===The access-key for "re-edit ===
[[Ticket:234]]
----
===LinkTails===
[[Ticket:35]]
----
===Search within the textbox===
[[Ticket:578]] (see also WikkaEdit)
----
===Numbers as page names?===
[[Ticket:8]]
----
===Improved code for error messages in Action() method===
[[Ticket:202]]
----
=== Language files ===
[[Ticket:340]]
----
===mod_rewrite idea (.htaccess)===
[[http://wush.net/trac/wikka/ticket/604 Ticket: 604]]
----
=== Create rewrite rules on install ===
[[http://wush.net/trac/wikka/ticket/604 Ticket: 604]]
----
=====Suggestions to be checked/migrated to the tracker=====
====making user uploaded images more useful====
have a look at my suggestion at FilesAction
----
=== Automatic conversion from HTML to WakkiWiki syntax ===
Does such thing exist? For a number of other Wikies, it does.
It should be nice (one could say, essential) to have this here, too.
--CsillagKristof
~&Try out http://diberri.dyndns.org/html2wiki.html (Won't work with tables yet). --NilsLindenberg
----
===Files Management===
//copied from FilesManagementSolution --JW//
**Link** to files, rather than upload? Would it be possible to add the functionality so that rather than store the files within the Wikki, there was an option box for 'link' as well as upload. This would be useful on internal wikki deployments where you want to avoid file duplication by allowing users to point at the file to create a link to that file on a separate internal server. - RogerD
----
===Automatic summary===
//copied from [[http://sourceforge.net/tracker/index.php?func=detail&aid=1150914&group_id=118997&atid=682795 Sourceforge]] --NilsLindenberg//
Is it possible to display through an action a little summary of the categories and sub categories available from the page we are in ?
----
===Improving Wikka===
A nice list of suggestions can be found at: [[http://smackaroo.net/by-blood-and-bone/MyNextWiki By Blood and bone]].
----
===Login using retrieved password===
The password retrieved from forgotten password does not work for me. Is there some setting in php4 or mysql that would allow ""md5(md5(password)) == md5(password)"" to return true? Since the password sent is the hash of the clear-text password, the current line in usersettings.php compares a hash of the hashed password to the hashed password, I think. I've found the correct code elsewhere in usersettings.php.
%%(php)
// usersettings.php line 130 fixed
if ($existingUser["password"] == md5($_POST["password"]) || $existingUser["password"]==$_POST["password"])
%%
This is the current version:
%%(php)
// usersettings.php current line 130
if ($existingUser["password"] == md5($_POST["password"]))
%%
The first one works for me. Is there a problem with security in using that version?
-CharlotteFischer
~&Charlotte, you are correct in that the code doesn't work as is. We are working on splitting up the whole (confusing) login/usersettings form into separate actions and forms; logging in with a "temporary" password should then not only be separate, but also force the user to immediately choose a new password since sending a password by email is inherently insecure. Until we have that in place in a future release, your workaround is a good one (I came up with the same ;-)); but it's up to you to decide how acceptable it is in your application to let the user continue to login with an emailed password. --JavaWoman
----
===Hiding anonymous host/IP from non-administrators===
On the Wiki I run, it is not desireable for the IP/hostname of anonymous users to be displayed to just anyone. I've made a small modification to hide the IP/hostname of anonymous users to users that (a) Are not administrators, and (b) not themselves. In handlers/page/show.php, around line 80 you can find: %%(php)print("\t
This page doesn't exist yet. Maybe you want to Href("edit")."\">create it?
"); print $this->Action("backlinks")."\\2
"; $text=preg_replace($pattern2,$replace2,$text); $pattern1 = "/^(\040|\t)*(<(?!hr|(\/|)h[1-6]|br|(\/|)li|(\/|)[uo]l|(\/|)div|(\/|)p).*)$/m"; //matches any\\2
"; $text=preg_replace($pattern1,$replace1,$text);%% I don't know how that will affect wikka (it was designed for my formatting which is different to wikka slightly), and there is probably a much better way to do it (call a post-formatter?), but it is possible using a small modification at least... --IanAndolina ~& The above code places paragraph tags throughout the page, including //within// code blocks, which seems undesirable. If ##\n## were treated as markup which wakka.php needs to transform into paragraph tags, code blocks wil not be changed, I think. I'll try it and post the code changes if it works. --PaulP ~~& No, that doesn't completely work either. It leaves code blocks unchanged, but keeps text from returning to left margin after indented paragraphs. --PaulP ---- E-mail this page facility --JamesMcl ---- ===Usergroups=== (copied from WikkaDevelopment --Nils) Yet another idea from me: ~Usergroups. So i can create a group of users, and just write that group into the ACLs... ~GregorLindner - Take a look at GroupManagement (which doesn't seem to be finished) - or at ACLsWithUserGroups. ---- ==="In work" for Wikka-pages=== (copied from WikkaDevelopment --Nils) Add a page property, 'Status' [?] that can be used to facilitate code development within Wikka. Imagine a very basic CVS system. A user can change the status to "In use' while considering improvements to the code, and then change it to 'Available' when done. This may prevent this scenario: - Multiple users see the same code and concurrently start working on changes. - One user posts his changes. - Another user posts his changes without realizing that the code had been updated. OR - Another user has to go back through his code and incorporate the changes made by the first user. ~&Comments: ~&''**Dangerous!** Consider the following scenario: user has been hard at work all week, now it's Friday afternoon and there's some time to do an edit or three. User opens each page in a browser tab, marking all three as "in use" and starts to edit them. Clickety-click. Suddenly user realises he has to run to catch the train home. Run! On the train, user realises the three pages are still open in the browser and "in use". "No matter", thinks our user, "it's always quiet during the weekend and I'll get back to it first thing Monday morning. On Sunday afternoon, user plays soccer, as he always does, and breaks a leg, which he usually doesn't do. User is transported to hospital where he has to stay for four weeks. ... A bit exceptional maybe - but what **do** you do with "dangling in uses" and when (how) are they considered "dangling" in the first place? --JW'' ~~&Good point, but this modification would be only an informational resource to facilitate user communication. Techically, users could still update the page any time they wanted. It would just be a courtesy to hold back if you saw that a page was 'in use.' I didn't mention it above, but I planned to also add a field that would timestamp when the status was last changed. So in your scenario, we would see that the page had been marked as 'in use' for several days and feel free to ignore it. However, this does bring up the idea that it would be good to also have a 'note' box available for updating the page status -- used for comments such as, "should have the code updated within a few hours." Better now? -- JsnX ~&I've got code/table changes done that indicate if anybody (other than oneself) opened the page to "edit" in the last 15 minutes. It's on an iteration that isn't "live" right now (it's part of an earlier installation of wikka that we just haven't brought the code forward from yet), but I can make it that way so you can test out the functionality if you want. Since much of our site will be geared towards small teams doing collaborative editing, it was designed so that editing conflicts would not occur. Let me know if you want me to get it installed at a test site. -- GmBowen ~&''I agree, it's an important issue (some Wakka forks have already addressed the problem of concurrent editing) -- DarTar'' ~&''JsnX: If it's purely informational, that's better; I thought the intention was some kind of locking. So you'd have something like: ~~&-state: in use | available ~~&-timestamp: in use since ~~&-note: applies to the in use state only ~&Then - would the state apply to the logical page or to a particular version? If the latter, what happens if a page is reverted to that version? What happens to the state when another user goes ahead and edits the page anyway? ~&And I still think you'd need some kind of admin function to "clear" dangling in use states that are older than xx minutes/hours/days. ~&GmBowen: is yours completely automatic or user-initiated? What happens in the run off to catch the train scenario? -- JavaWoman'' ~&(i) it's purely informational, not a "lock"...it sets a red exclamation mark beside the page name at the top if the "edit" link (or double click) has been used in the last 15 minutes by anybody other than yourself (ii) it's automatic (iii) the "train scenario" can't happen. It doesn't check if "saved" or not, just whether an edit was started in the last 15 minutes. This means that if the person doing the edit hasn't saved in the last 15 minutes when editing then the exclamation mark isn't activated for another user. But, people should save edits every 15 minutes anyways methinks. It's not "foolproof", but was meant to avoid many sorts of common editing conflicts on collaborative documents. It's not a very "big" edit of the wikka code actually. The edit.php script timestamps the most recent version of the page when it is activated, and there's a small addition to header.php that checks when the page is loaded to see if the current time is < 15 minutes from that timestamp & if so shows an exclamation mark. Finally, there's a small linked graphic that "refreshes" the page beside "homepage" and the "edit" link (essentially, it's just a link to the page itself) so a user can check the edit status before deciding to edit it themselves. For server load reasons I decided to not have an automatic check (once every 5 minutes for example) since most people read & don't edit much of the time so it made sense more to encourage people to check edit status themselves. Of course, it would also be possible to have edit.php check to see if the file was edited in last 15 minutes and if so, ask the user if they wanted to continue with their own edit. Hmmm...I'll have to think about that. As it sits it worked pretty well when tested (but remember, I'm into small group collaborative writing tasks....I'm not sure how it would work if the pages were "open" to everyone). It originally took me several hours to write the code myself, but I'm sure it would take JW or DarTar or Jason maybe 30 minutes....and the code would probably be more efficient (I'm not a real coder remember :-( ) -- GmBowen (aka Mike) (I've now provided my code & mods @ [GmBowenRecentEditCheck] for people to play with) ---- ===Searching (in) comments=== //(copied from WikkaDevelopment --Nils)// Add the ability to 'search for all comments by user X'. How this might be useful: I want to find a comment by JavaWoman ''//(really?)//'', but I can't remember which page it was on -- she's quite prolific! -- ''//(I admit I'm easily distracted. What am I doing here, now!? :))//'' so I use this new function to list all of her comments. ~&Yes. And related: an extension of this or the general search function to search by //comments content// (in addition to page name or page content) would, I think, be also useful. --JW ~~&Agreed. -- JsnX ~&Nice idea :). For //comments by user X// (and, why not, //mods by user X//) we could imagine something similar to Google syntax for site-restricted queries. E.g.: ##I18n user:""JavaWoman""##. The scope of the query (pages, mods, comments, anywhere) should be settable as a radio button (similar to Google's restrict search options). FYI, //Comments by user X//, //Pages owned by user X// and //Changes done by user X// were already partially addressed by the following action proposals: UserCommentsAction, UserPagesAction, UserChangesAction -- DarTar ~~&In general....given the complexity (and utility) of some of the conversations now happening in the comments, I think that we should consider either (i) the current textsearch being expanded to include the comments, or (ii) a separate action be written directed at searching the comments table (possibly an easier route). The latter might mean we consider renaming the search pages to ""SearchText"", ""SearchTextExtended"" & ""SearchComments"". [I now realize that this "search comments" feature is a **"lost"** feature. I realize now that //earlier// versions of this wiki had the comments stored in the pages table and were therefore searched. When they were moved to a separate table, the ability to search comments was lost. (Update: See my GmBowen directory for a (temporary) solution for this....even separates results for comments & pages into two columns) A separate action to list all comments by a user would also be useful. In a related comment on the comments, and given my arguments about the complexity of conversations in some of the comment threads now, I suggest that we also consider developing code for threaded discussions in the comments....which I think will considerably enrich collaborative efforts (such as we engage in). -- GmBowen ---- ===Order of the text-search=== //(copied from WikkaDevelopment --Nils)// It would be good if the text-search would be sorted in some way. If I search for example for "GmBowen", a page with the exact match (his userpage) should be on the top of the results. The next results perhaps in alphabetical order? --NilsLindenberg ---- ===Highlight unseen Recentchanges=== //(copied from WikkaDevelopment --NilsLindenberg)// Add fields to the 'users' table [?] to track when RecentChanges and RecentlyCommented were last viewed. Then RecentChanges and RecentlyCommented can by modified to highlight new items since the user last viewed the page. ~&If it's only for **highlighting**, OK, but I'm not waiting for that. If it's for **filtering**, please no. I quite often trace back several days to re-review pages or comments --JW ~~&OK. Point taken. I was considering doing some form of filtering, but will now only consider higlighting, as requested. -- JsnX ~~&I totally agree with JW's point -- DarTar ~~~&Actually, I //could// imagine separate functionality with filtering being useful on a busy site, but then as, say, UnseenChanges and UnseenComments - **in addition to** the current "Recent" functionality; that way the semantics of "recent" would not be changed. But I agree it's low priority. --JavaWoman ---- ==="target=" in external links?=== Is there a way to include a target in a link, so that the Link opens in a new window? ~& Yeap, use this directly within the wikka page you are working on ~& %%(htmlstrict) Google %% ~& It will show up a normal link "" Google "" ~& In this case the **TARGET="_blank"** bit is what does the trick. ~& Assuming this is what you were originally after, it has the advantage of no code changes. NickDamoulakis ~~& I assume you meant the above code to be put in double quotes like this: ~~& %%(htmlstrict) ""Google"" %% ~~& Since I use Wikka inside an iframe I need to use target a lot, so I modified the forced links section in wakka.php from: ~~& %%(php)//if ($url!=($url=(preg_replace("/@@|££||\[\[/","",$url))))$result=""; if (!$text) $text = $url; //$text=preg_replace("/@@|££|\[\[/","",$text); return $result.$wakka->Link($url, "", $text);%% ~~& To this: ~~& %%(php)//if ($url!=($url=(preg_replace("/@@|££||\[\[/","",$url))))$result=""; if (!$text) $text = $url; if ($pos=stripos($text, ' target=')) { $target = substr($text, $pos); $text = substr($text, 0, strlen($text)-strlen($target)); } //$text=preg_replace("/@@|££|\[\[/","",$text); return $result.$wakka->Link($url, "", $text);%% ~~& I can now do forced links like this: ~~& %%[[http://www.google.com Google target="_top"]]%% ~~& What I don't like is target within imagelinks, the way it is now you have to write like this: ~~& %%{{image url="whatever.gif" link="http://www.google.com" target="target='_top'"}}%% ~~& This would have been better looking: ~~& %%{{image url="whatever.gif" link="http://www.google.com" target="_top"}}%% ~~& /AndreasHeintze --GregorLindner ---- === Easy way of adding links === Most wikis I have set up have the need for a page containing a list of links. It would be great if Wikka could support this in some way - such as providing an easy way of adding links to a configured page. One way of doing this could be a simple Java Scriptlet that you configure with the address of the link page. Then, you mark a link in a web-page, click on the scriptlet, enter a short description and bang - the link is added to the wiki page. The del.icio.us [[http://del.icio.us/doc/about page]] offers some user contributed hacks which may be a starting point. -- MatthewLangham ~& MatthewLangham, I propose AddLinkAction as solution for adding links on a page in a structured way. I also added (under the Beta section at the end) a ""JavaScript""-link that you need to bookmark to fast add a link in two mouse clicks... (Works with Firefox and IE under XP, still needs testing with other browsers) -- OnegWR ---- === Image dimensions === The [[Docs:AddingImages image]] action really needs the ability to specify image height and width. :) --MovieLady ~&I agree that it would be better to have defined width and height in the resulting img element: faster output, and no "jumping" pages. However, PHP can easily derive these dimensions by itself - would that be sufficient or do you think it's also necessary to be able to override the actual dimensions of the image file? --JavaWoman ~~&There surely will be users which want to do that. My suggestion (if possible): allow height and width as optional input. If nothing the variables should be filled with the values of the image. --NilsLindenberg ~~~&Noted. More //easy// suggestions like this, please. :) --JavaWoman ~~~~& Yes, that exactly, Nils. LOL Lemme get my list, JW. ;) Seriously, though, I really like what you all have done with this wikki, and the multitude of suggestions are only because I'm getting invested in it. *g* I've been sick or I would've worked on the DeleteSpamAction changes sooner so I could feel like I was actually doing more than "I want it to do this!" ;) --MovieLady Dear all: see my proposal at EnhancedImageAction ~& That's great, Christian, thank you! --MovieLady ---- == User registration control == now available as URUniqueEMailModule ---- === Embed a blurb from a news page into another page? === I currently have no idea how one would approach this, but thought I'd toss it out there for others to think over. I would find it really useful to have an announcement action (maybe ""{{news}}""?) that I could use which displays only the most recent (configurable) number (e.g. ""{{news show="2"}}"" would show the most recent two entries from the page) of entries from a specific (configurable or static?) page. Right now I do this by hand, adding the current announcement to both the front page and the news archive page (so I'll have a history of the announcements), and boy, what a pita! What I'd like to be able to do is just edit the news page and have it automatically update what displays in the news area on the front page. Possible, or am I smoking something I need to share? ;) --MovieLady ~& I am doing this using the IncludeAction - at least you only update one page (TheNews). --ChristianBarthelemy ~~& Thanks, I'll try that out. --MovieLady ~~~& Did you do anything to get it to add only part of the page being included (for example, down to the first horizontal line)? --MovieLady ~~~~& Nope. I just only keep the news updated in TheNews page so that the whole page is displayed when included. --ChristianBarthelemy ~~~~~& Ah well, I'll keep working on trying to figure out a way to do it. *g* Thanks! :) --MovieLady ---- ===Logging-out=== Perhaps the installer should tell the user that he will be logged-out (because of the new cookie-names). Would be nicer. Btw, the /setup directory needs an update (or better the files in it). --NilsLindenberg ---- === Backlinks === It would be wonderful to have the option to display the results of the ""{{backlinks}}"" action in columns, similar to what ""{{Category col="3"}}"" allows you to do. --MovieLady ~&Noted - good suggestion. --JavaWoman backlinks.php %%(php) if ($pages = $this->LoadPagesLinkingTo($this->getPageTag())) { foreach ($pages as $page) { $links[] = $this->Link($page["tag"]); } // #MW:commented print(implode("\n", $links)); // #MW: Ja, här ska jag fixa stöd för kolumner via parametern col if (!isset($col)) $col=1; $out = "
...tag; since we actually know the timestamp of the change, add that in the **##datetime##** attribute (properly formatted); ~-mark up an insertion with the ... tag; same recipe for the timestamp ~-then use the stylesheet to render those two in whatever font/coloring you like (even as done now) - but note that most browsers have a default rendering anyway See [[http://www.w3.org/TR/html401/struct/text.html#edef-del 9.4 Marking document changes: The INS and DEL elements]] for all the details (HTML 4.01 since that's where all the semantics are). --JavaWoman (standards junkie) ''This is related - I found that the diff engine and page history sometimes forgot to close tags. With a list of lists, the indents would get carried forward. Check out my [[http://wiki.samuelooi.com/wikka.php?wakka=Mod03HistoryAndRevisions hack]]. Not CSS compliant by any means, but then again, your suggestion isn't either (list tags are not closed etc etc). I reckon you would probably have to parse each addition/deletion through the SafeHTML checker.'' -- Sam Assuming you mean XHTML compliant (sorry) my suggestion certainly is (believe me, I would //never// suggest anything that //isn't// XHTML compliant) - I just forgot to mention that closing tags properly is a prerequisite... although I did point to the actual standard which indicates how **##ins##** and **##del##** must maintain proper tag nesting. You're right though, I did notice that lists don't seem to be closed properly. I think that should be fixed first (it's a bug, not sure it's recorded as such yet) - **then** you can do more semantic markup. -- JavaWoman (standards junkie) You mean something like that?: %% // deletions else if ($thing == ""¥¥") { $timestamp = $wakka->GetPageTime(); //hopefully this function returns the right format? return (++$trigger_deleted % 2 ? "" : ""); } %% (naturely the rest has to be changed too) --NilsLindenberg ---- === Problem: Scrolling in the search - field === Not worth to mention but now I am here I write it. Text in the search field is a little bit scrollable. Again ... ;-) -- SkyWalk ---- === Problem: Five Line Breaks === Just a small problem i found. If you insert five line breaks at the end of a site, the footer jumps into the box. After all a nice wikki. Keep on the good work. -- SkyWalk ---- === DB Export === ExportDB : as i'm discovering Wikki (and WikkaWiki) and playing with it on my main server and on my laptop (which too runs an Apache installation), I was needing a quickly way of making export of my database. So I wrote a quick (and dirty ...) export page to get all the replace SQL commands to populate an instance. I too may use this in the future to quickly backup an online Wikki site. See this additionnal page for the code : CodeExportdb -- SergiO ---- ===Code block formatting=== I was converting a document to Wikka markup format, and I was trying to display ""MySQL"" (Console) Table output using the "Code" formatters ""%%"". Everything that appears in a code block is formatted using a monospace font (as I expect), however, since the Edit page handler converts every instance of 4 spaces to a tab, the spacing is thrown off. Below is an example (Select some of the whitespace with your mouse to see the tabs): %% ---------------------------------------------------------------- OBJECT_TYPE COUNT(*) ------------------ ---------- FUNCTION 12 INDEX 55 LOB 4 PACKAGE 2 PACKAGE BODY 2 SEQUENCE 9 TABLE 37 TRIGGER 6 VIEW 1 9 rows selected no rows selected -------------------------------------------------------------------- %% The edit page handler seems to convert spaces to tabs throughout the entire document, including Code blocks. **From edit.php** %%(php) 11: // replace 4 consecutive spaces with tab character 12: $body = str_replace(" ", "\t", $body); %% Is there any way to make the edit handler leave the spaces alone inside of code blocks? Thanks! -RichardTerry ''Noted. Try commenting out that line for a temporary workaround.'' -- JsnX %%(php) // $body = str_replace(" ", "\t", $body); %% ---- ===Various suggestions=== - See MarkHissinkMuller for things I would like to see in Wakka/Wacko/Wikka. Feel free to add/discuss. ---- ===Other method to attach files=== - I'd like a way to attach files to a page without having to include the ""{{files}}"" action. I like using the action to //link// to attachments, but I'd rather click a link at the bottom of each page to reach the attach form or to see which files are attached to the page. (I'm a PHP newbie, so It would probably take me some time to make a handler to do what I want.) //Actually, now I'm kind of used to having all of my attached images displaying at the bottom of the screen, so this isn't a big deal. If I really don't want the attachment list (usually a bunch of images) to display I just remove the ""{{files}}"" from the page.// -RichardTerry ---- ===Installation problem - UTF-8?=== - Not a suggestion, but problems: with installing 1.1.3 on a Win 32 Apache 2, with Php 4.3.8 and Mysql 4.1.3. Upgrading from wakka 0.1.2 didn't work (ended with: "creating comment table - failed - hmm"). So I thought I'd do a fresh install. Everything went fine, but there seems to be some problem with utf8. Even when I set the charset in header.php to utf-8, the page is all scrambled. However, in phpMyAdmin, the text in the pages table shows up fine. Any clues? (I need utf-8, by the way ...) BirgitKellner. Sorry if this was the wrong place for posting this, and feel free to move it to a more appropriate one. wikka don't support utf-8 yet. this issue is discussed here: WikkaInternationalization (and should be moved from there to its own page, 'cause it's not a trivial problem ;) --moved to HandlingUTF8 ). anyway, i'm afraid you won't find comprehensive help in that discussion. it's not enough to change the meta-tag. that only tells the browser to assume a charset, which in fact isn't used. i haven't spent much time on that issue, although i am (or should be) interested in it. but be assured that it's not a simple config-value to be squeezed to solve the problem. i hope the discussion mentioned above will get more precise in the next days, as i would appreciate any hint how to start to despair of it ;) i think in long terms it's **a must** to support different charsets. -- DreckFehler ---- ===Add page link & other suggestions=== ~- It would be Really Nice to be able to have an **Add Page** link that allows a user to create a new page without having to edit an existing one. (I don't belive this is currently possible, I'm a newbie however) Perhaps this could be achieved via a simple HTML Form that prompts the user for a Page Name, and Category. It would be even better if the Category was selectable (dropdown list) from existing categories. And to top the whole thing off, it would be perfect if it was possible to define Template files (eg. per Category) where by when a user creates a new page of category ABC, the template file for ABC is used as the default page text. This would aid in keeping some kind of consistancy between pages of the same category. (ie. for one thing the correct category definition could be placed in the appropriate location/style). An **Add Page** link would posssibly be usefull on the standard Category pages, especially as the Category is already known. ~- It would be nice if ACLs were somehow inheiritable from their creating pages (Created either the current way or via the above described method) ~- Is it possible to define User Groups to simplify editing ACLs also. ~& I tried to do something with ACLsWithUserGroups. ~- Finally, (although I think I can possibly do this one myself) , On the Editor Page a link to the standard FormattingRules page would be most useful. Especially if it opened in a different window. Regards Simon H. ~& I like the **Add Page** link idea. It would be really simple to implement, too. Perhaps a text form where you'd enter the page name, which would take you to ""http://some.host.com/wikka.php?wakka=NewPage/edit"", where you would actually create the content. I like it! --KickTheDonkey ---- ===Disable CamelCase=== While I understand the arguments in favor of CamelCase, I prefer not to use it. Given how incredibly simple it is to modify Wikka for non CamelCase use (remove one line in formatters/wakka.php, and replace a regex in wikka.php, wouldn't it be simple just to add an admin option to turn it on and off? ---- ===Rename Pages=== It would be nice to be able to rename pages and automatically update all backlinks to point to the right page. Example: I have a ""HomePage"" which has a link to ""MyIdeas"" on it. Let's say I realized that all these ideas are Wikka related, so I want to rename the page to ""MyWikkaIdeas"". Any link to ""MyIdeas"" (such as that on ""HomePage"") should now be changed to point to ""MyWikkaIdeas"". - JonathanMitchem ~& Yeah, so I found this... RefactorWiki which supposedly does exactly that (I haven't tested it personally) - JonathanMitchem ---- ===Star Rating System=== I think that maybe usefull a star rating system for a page or for an image or other . ~& LuxiO, what criteria would you suggest for such a ranking system? --BrianKoontz ~~& BrianKoontz, first i think that the rating system should have an extra table in the main database so that every item we want rate should have a unique identification number. Then we manipulate this extra table from an internal action... maybe? --LuxiO ~~~& That sounds like a suitable approach...but my question is, how would users be expected to "rank" a page? Are we looking for a measure of suitability, quality or aesthetics, or maybe popularity? Is it really possible to assign a relative ranking to pages with dissimilar content? --BrianKoontz ~~~~&It would depend on the use of the wikki... for example, [[http://www.RantThisSpace.com Rant This Space!]] is purely for entertainment and therefore people would be encouraged to vote based on how entertaining the page was. In a corporate setting it might denote importance, or relevance to the project. Then the home page could display a list of all pages with 5 stars, and new members would know to read them first. Icons other than stars could also be used. I have found this simple javascript for page rating: %%(javascript) %% but i don't know how implement single file rating --LuxiO CategoryDevelopmentSuggestions