Please Note

All FeatureRequests should be made on the SourceForgeFeatureRequestTracker, not here.

Before making a feature request, please read FlexWikiFAQ.

Table of Contents:

• Please Note
• The Big Features List
• Unknown Priority
• Medium Priority
• Low Priority

The information below this line is obsolete, but is being preserved until all feature requests can be moved to SourceForge.

The Big Features List

• AbstractContentBase - (unknown topic name: AbstractContentBase)
• LinkedFederation - LinkedFederations would allow a federation to include ContentBases that it can't reach via the local file system. This would likely be SOAP-based and would allow two people, each running a federation to include each other's ContentBases.
• SharePointIntegrationEnhancement - FlexWiki would be great if it were integrated more with SharePoint. People who are used to using SharePoint would be faster to start using wiki if it were (better) integrates
• BLiki - (unknown topic name: BLiki)
• FlexWikiEditor - FlexWikiEditor is a Windows Forms client for FlexWiki that communicates with FlexWiki using the FlexWikiWebService.
• FlexWikiWebService - FlexWikiWebService is a WebService that exposes APIs for retrieving and modifying content on a FlexWiki instance.
• FlexWikiMetaWeblogAPI - the MetaWebLogAPI is a popular blogging API that many applications support. The FlexWikiMetaWeblogAPI will wrap the FlexWikiWebService and expose some of the functions in the BloggerAPI and the MetaWeblogAPI allowing existing blogging implimentations to post/edit TopicNames.

Unknown Priority

• How about using valid XHTML and a valid DOCTYPE so that FlexWiki doesn't get rendered in Quirks Mode? Quirks Mode is much more difficult to debug when it comes to styling HTML with CSS. Also I noticed that many HTML attributes are used instead of their CSS equivalents. Separation of content and presentation would be really nice. -- Travis
• I second this, and would even go as far as to not include any HTML layout in the rendered pages, so that the Wiki can really have its appearance drastically altered through CSS skinning (as in CSS Zen Garden). Right now, the HTML code of the pages is very dirty, with Javascript hanging around anywhere, hard-coded HTML attributes and values, etc. This is a big drawback for web designers.
• Extract the HTML formatter that converts the Wiki syntax to HTML code so that different formatter plug-ins can be developped. For example, I'd like to only use strict Textile syntax. Right now, the syntax is a bit messy.
• It would very nice to insert line breaks. This feature is important when writing lists (like this one here) and want to insert a break in order to format the list entry a little.
• Example 1 <br!!> The example 1 is an example for showing how incredible import a line break is.
• Example 2 <br!!> The list would be much more nicer if I could separate the header in the list entry from the content of the list entry.
• Line breaks within table cells without using @[[ notation and concatenation; if the table cell understood a line break the same way as the rest of the document.

• Edit Summaries. Most wiki software allows users to (optionally) fill in a summary of their page edit. This short text then appears on the RecentChanges, and page version histories, making this a much more useful audit trail . Without this feature a flexwiki doesn't set the scene for proper peer review of edits. In practice this means for example it is very difficult for a user to despam a wiki, since they can't get any idea of when the latest legitimate edit ocurred on a page. See also This note on chongqed.org -- Halz

• A nice feature would be if the link to this page from the homepage actually worked! (note the weird DHTML doesn't work at all in firefox, but what's that pop-up all about anyway?)

• Hyperlink blacklist should allow blacklisting of entire domains as well as just prefixes.
• Allow custom page headers. Right now the DoPage() method writes the body tag. It would be great to get this tag out into Default.aspx so the page header could be customised/branded to match the hosting website and integrated with the hosting website section navigation. I'd rather have this and lose the "double-click body to edit function" -- IanWij
• Ability to define template pages that can be chosen from when creating a new page. These templates would be defined per namespace. -- JamesBerry
• Ability to post code chunks and have FlexWiki colorize them -- JamesBerry
• It would be nice if the textile format for making links to external pages (the one like this: " text to link " : url ), allowed you to use the wiki protocol, instead of just http. This would allow you to make friendly-looking links to weirdly-named pages, which can be handy sometimes. -- CraigAndera
• Pocket PC support (Mobile Windows 2003). It could be usefull to allow users to interact (read & write)with the wiki from a PDA. Presently I use a modified (intranet) version of openWiki with a WinMobile 2003 Phone Edition PDA over GPRS... it is very usefull to me. -- A.Busetti
• this is just a logical extension of the FlexWikiEditor concept which is already on the test
• Change the CSS so that when you have nested page properites (see ExamplePropertyPage) that if fieldsets are embedded in each other that they will nest better visually. -- ChristopherAllen
• Minor Edits: Allow users --perhaps only authenticated ones or those at certain IP addresses-- to mark certain editions as "minor edit" so that changes do not appear in RecentChanges and clog up the system with spelling, formatting, grammar, and other trivial changes. -- KorbyParnell
• Allow the About text and Wikibase descriptions that show up on the right side to be wiki text.
• A warning dialog, if someone does not enter an email address when editing a page. -- UrsMuff
• When people edit a page using a long email address, the sidebar gets very wide because of the Versions drop-down list box. Not sure what to do about that... Options:
• Munge the string if it gets too long and put "..." in it
• Let the sidebar have a horizontal scroll bar (yuck!)
• Remove the revision history from each page and move it to another page. This could also allow for display of any comments written during editing, if FlexWiki were expanded to capture such comments. All of these would bring FlexWiki in line with more of the other existing wiki packages.
• Move the revision history (and perhaps other potentially wide sidebar elements) from the sidebar to some other part of the page or into a pop-up or fly-out of some kind
• Change the revision history to show IP address 'or' attribution text but not both
• Add encoding-option to InterWiki, for example, google query string usually UTF-8?just like. http://www.google.co.jp/search?num=100&hl=ja&ie=UTF-8&oe=UTF-8&q=%E3%82%A6%E3%82%A3%E3%82%AD&lr= -- YoshihiroKawabata
• Normalize the way default.aspx gets the topic name to use a more traditional URL with a query string. The current syntax makes some servers and systems unhappy (e.g., cassini web server).
• Or use URL-rewriting and paths more like /WikiNamespace/TopicName/. Then we completely avoid issues with periods appearing in various places in the names, with indexing and proxy caching of pages that take querystrings, and with strange and unnecessary file extensions like ".wiki". From there, its easy to envision expansions that create good links (CoolUrisDontChange) for such things as previous revisions eg. /WikiNamespace/TopicName/20040407T212400Z/
• Security enhancements. Specifically:
• The ability to use ASP.NET Forms authentication. If I want to set up a Wiki that me and twenty of my friends can edit, it's not necessarily kosher for me to set up domain passwords for all of them. I realize that this is possible now, but not when combined with my next requirement: (-- CraigAndera)
• support form authentication (for View, for Edit) --- YoshihiroKawabata
• The ability to define View and Edit permissions on a per-namespace (higher priority) or per-topic (lower priority) basis by user or by role. Since the individual Wiki files aren't processed by the ASP.NET engine, using a < location > tag to restrict access to specific namespaces or topics. Also, ASP.NET doesn't really have a concept of "view" and "edit" actions. (-- CraigAndera)
• The ability to define accounts on the system for users with the possible ability to give these users a home page for themselves (such as what WikiPedia does). See http://en2.wikipedia.org/wiki/User:The_Cunctator for an example. (-- AlBillings)
• support Trackback, and Add Trackback informations to Pages --- YoshihiroKawabata
• Add list of available WikiNewsletters to the Subcriptions page (that, right now, only shows RSS feeds)
• Figure out how the newsletter subscriptions could work without exposing people's email addresses to search engines (which then produce SPAM!)
• Feedback: this might be the wrong way to go about it - simply use a mailing list address instead. FlexWiki is unlikely to ever be a good list server. - CraigAndera
• An approach to solving this would be to have a property 'Email:" on user pages that is stored as a proper email address, but when displayed in html is munged into either a graphic or by using a javascript technique to obscure the robts like www.hiveware.com/enkoder_form.php does. Then you list the user pages in the Subscribers: property. -- ChristopherAllen
• WYSIWYG Editor (e.g. FreeTextBox)
• Database backend instead of file store-
• See DatabaseBackedContentBase
• It would be nice to have a IWikiData interface that would be supported by both a file store backend and a database backend and make it configurable via the config file.-
• See AbstractContentBase
• SharePointIntegrationEnhancement - Integration with SharePoint (This might be another project altogether. Maybe the suggestion is to refactor out the wiki 'engine' as something redistributable.) -- JasonDossett (in discussion with MattWright about this).
• See AbstractContentBase
• AutomationEnhancement = Web services and\or automation API to programmatically modify the Wiki -- JasonDossett
• See ProtocolBackedContentBase and FlexWikiWebService
• Not allow _ContentBaseDefinition files to show up in search. -- JohnMorales
• Modularize the Wiki into more Assemblies (And maybe a few ASXC files) to allow easier customization
• support relative urls
• Can you be more specific? What do you mean? -- DavidOrnstein
• It would be nice to enter links to other documents on my server that are relative to the WikiRootFolder. Example /wikifiles/XmlToLinkInAPage.xml -- MariusF
• This might not be what the original poster meant, but I'd like a way to embed images without having to put in the full URL (so I can move my wiki to a new host). Or is there a way to do that now? -- JohnSands
• Does EasyMediaLibrary do what you're thinking of? It's not here yet, but it's in planning. -- TommyWilliams
• Yes. My wiki is currently local and I copied an image into the wikibase directory and wanted a way to display it in the wiki with a relative path so I can move the whole wiki to a server soon. But you're right - the ability to edit the site without FTP or other file access and hassles is the point of a wiki. Copying a file with the file system or FTP is not a good way to get a new image to the web site. So a potential solution is EasyMediaLibrary as a way to upload the image and a new formatting code for displaying an image from the library without the need to change it if the whole wiki is moved. Of course, even without EasyMediaLibrary, if I have FTP access and can copy the new image, I'd still like to refer to it with a relative path, just like using a Wiki Word for a page link. -- JohnSands
• Oops. Never mind! I just found ImageBehavior and it works with a relative URL. -- JohnSands
• Relative ULS in \@\@Image works for me in preview mode only, then changes URL after "Save" to include deafault.aspx and ends up a bad link -- JohnHarris
• Great news! I wrote ImageBehavior and didn't even think about using it for what you were talking about. Makes perfect sense, of course. Duh! -- TommyWilliams
• Add a Plug In architecture for custom WikiBehaviors. This will allow others to write custom code for thier own WikiBehaviors.
• Looks like this is done. See PlugInOverview
• Three more site properties: Next, Previous & Index. So it would be easy to implement a basic navigation within the wiki. -- TobiasMueller
• Within a Namespace, heirarchical structure. Parent/child relationship of pages would facilitate navigation. Then "next", "back", and "up" would be useful navigation terms, and much namespace naming cleaner (e.g. Wikiname.HomePage.MyPage.BigJointProject.MyIntroduction, and Wikiname.HomePage.YourPage.BigJointProject.MyIntroduction). -- YarkoT
• Currently, the last URI:" specification on a page us used for wiki://-styled links. Would be nice to have them stack. That way, for example, current charts could be drawn first from a primary source (URI{2}{1}URI{3}""). Also, people could build their libraries while building up content, which later could be transfered to a central server - without need for editing source, nor worrying about lots of people having "upload" access somewhere. -- YarkoT
• Support for acceptance testing in C# (http://www.fitnesse.org/).
• Have the NUnit code in a seperate class, so I can leave it out of the CompactFramework port -- SteveMakofsky
• Have all the web specific ASP.NET and rendering code for HTML go into the FlexWiki.Web project. Create a codebehind class for each .aspx page and place all rendering there. Free FlexWikiEngine of all ASP.NET dependancies. -- OmarShahine
• Provide a simple layout without the framed content and the edit features below the content. If your users are viewing more than they are editing the ratio of content real estate to function real estate is less than 1 to 1. Try sizing to the browser window to about 640 pixels wide to see this.
• Allow more control over Tables like ColSpan or RowSpan. Implement more of the features at Textism. -- MariusF
• A tool that would faciliate the importation of word documents directly into FlexWiki beyond simple back linking like WikiBlade. I would really like to see what you could do with this in native MSWord. Something based on XML perhaps...the cross referencing and backlinking between business domains would be incredible! -- EricCotter
• Add a WikiMap document for each wiki. This would be a wiki page that is an outline of content in the wiki (similar to Word's document map). The map can be optionally displayed on the LHS of each wiki page in a treeview mode for each navigation. Optionally the map can drill down into WikiPageMap which is a TOC outline of the page. The WikiPageMap can also be implemented as a WikiBehavior allowing placement at the top of a wiki page to serve as the TOC of that page. The WikiMap can display the WikiPageMap in the treeview. -- IssamElbaytam
• I rather see some sort of SiteMap that displays the TopicNames and the relations between them -- IvoDiepstraten
• Allow specification of both presentation and edition sidebars, so that they can be customized in style and language, on a namespace basis. Specifically:
• Read content to be included in them from external files (could be HTML fragments, so that customization would be unlimited)
• Define ContentBase properties to allow for positioning and size, such as DisplaySideBarPosition (top, down, left, right) and DisplaySideBarSize (with fixed or maximum values) and their corresponding properties for the edit sidebars.
• Allowing multiple sidebars would be even better; a single property for each of them would do (such as LeftEditBarSize). -- LuisCanteiro
• Community Wiki has an interesting Portrait: page property, which if it exists on your home page is used in a variety of places, for instance for threaded discussions. I'm not sure that it is absolutely needed here, but it shows some interesting potential of having page properties on user pages, or having page properties that refer to URLs. See http://www.emacswiki.org/cgi-bin/community/DenotingAuthor for an example. -- ChristopherAllen
• When editing, ask for user confirmation before closing the browser window if changes have not been saved, to prevent losing them all. -- LuisCanteiro
• I've seen this done by a javascript on onclick of the textarea, which sets some type of hidden value, a javascript on submit that clears it, and then other javascript on other signals that signify that the user is moving the page, and if the hidden value is set, it will warn the user. I'll try to find an example page that does this. -- ChristopherAllen
• I've been looking at abstracting the WikiOutput class to allow extentions for other formats (e.g. XHTML, XML, Text, PDF). The main one for me would be PDF (using the iTextSharp library) so that I can document progress on a project on an internal wiki and then produce a snapshot to PDF for a Topic Tree. I would expect to be able to remove all HTML from the current Formatter object and have the WikiOutput derived objects witre to their own streams. The main problem at the moment is how to deal with behaviours as they currently return complex HTML specific to their task. The Wiki markup should stay very simple to foster mainstream user adoption. An initial thought is to simplify the current behaviours and extend some of the current markup to meet at some middle point. This seems, at the moment, an absolute requirement to provide extensible output formats. ( AdamStraughan )
• Tool tip text isn't displayed long enough to read - it should linger for a time proportional to the length and complexity of the content -- GG
• I would like the side panels to be customizable throught the NamespaceMap.xml file. The panels would be tacked around the outside of the wiki pages in the order that that they appear in the xml file (much like how docking controls works in the .NET Framework). These panels would not be editable by individual users, but panels could have custom data (setup by the administrator) which would display common wiki links (such as to the home page, newsletters, or other commonly needed info) and other data. Also, each of the existing panels ("Seach", "History", etc.) could be put wherever the administrator wants. These panels would be the same for all pages viewed at that website. - StarTether

Medium Priority

• An 'index' feature that just lists all the pages would be nice. You can do a search with no search string, but that returns page content and not just a nice neat list of titles. This is WikiMap.
• Changing the title of a WikiPage - accept a property Title: with the rest set to the new title of the page
• SendPageByMail - a cool feature idea
• Links within a page - Add the ability to link to another section within the same page.
• Useful when the page is long and you want a table of contents at the top. -- MikeLinnen
• Maybe we could continue with teh dotted syntax and have TopicName.HeadingName act as a link to a specific heading within a Topic. -- HoopSomuah
• Actually, I think the URL fragment syntax is prior art, so it probably makes sense to use that. You're going to need to emit the anchor tags anyway - might as well let the browser do all the work. -- CraigAndera
• why not add a way to generate a table of contents based on the bang headers in the page, that way the TOC wouldn't have to be updated when the rest of the page is, just add TableOfContents: to the top of the page and it is automatically generated.
• Add impersonation to allow file-system security to shine through (including read-only UI changes)
• LinkedFederations -- DavidOrnstein
• Perhaps allow the ability to FreeLink be configurable on a per-server if not a per-WikiBase level. -- JeremyGray
• Fix the "delete" processing to be more robust WRT casing and whitespace; today, it only works if there is only "delete" in the topic, case-sensitive with no whitespace (yes, Virginia, delete followed by a CR fails to work).
• Change the template page layout to use something other than a Div -- when using browser history to back up through pages, the returned-to page is always back at the top, rather than scrolled down to where it was when we left it. I didn't see NoScrollbarRule in WikiLore to indicate that content under a TopicName should be kept to a single screenful.
• InterWiki macros
• Add a delete button to the edit page, this would make it easier and more discoverable to delete a page. Covered by SourceForge Tracker Feature Request 1044265.
• Include core FlexWiki pages, perhaps a small FlexWiki ContentBase, in the install package. These pages should be things that all wikis will have: FormattingRules, OneMinuteWiki, VisitorWelcome, etc. -- JohnMorales
• Add a feature to restore a deleted page. - This is already possible, see DeleteATopic. It could be more discoverable, though...
• Add a Stylesheet keyword to the _ContentBaseDefinition for a namespace. This allows an end user of a namespace to override the stylesheet for that specific namepsace withou modifying Web.Config. -- OmarShahine
• FlexWikiTemplates
• Support the outlook protocol for external links. Currently "outlook:< public folder path >" is not parsed as a link so there is no way to link to an item published in an Exchange Public Folder.

Low Priority

• Want users to be able to set their preferences (especially, their prefered home namespace); this is the final step in eliminating the reason to actually run the software just to have your own wiki
• Another reason: Disconnected operation sync'ed through a version control system like CVS or Subversion.
• Should be able to move a page (to a different namespace)
• Should namespaces have a visual identity (icon, colors, etc.)?
• All topics list (want to be able to see all topics) -- should include descriptions and keywords - and other properties? Would be nice to have this unified for search, all topics and recent changes.
• map windows user aliases to wiki full-names
• WikiClassPages -- Support for documenting classes.
• A place to add optional comments when editing a page. These comments would only show up in the meta data associated with the change, not on the page its self. -- GearyEppley
• It would be helpful if there were a "Cancel" button in edit mode. Back is not always easy if you have pushed preview a couple of times. -- GearyEppley Can we get this one moved up on the priority list? It seems pretty easy to implement and not having it is confusing to new users. -- RayDixon
• XML Color coding. Recoginze XML blocks w/o indenting. -- GearyEppley
• Some of these "macros" would be nice: http://fox.wikis.com/wc.dll?Wiki~WikiMacros. I particularly like the fading New tag. -- GearyEppley
• Get all request throught ASP.NET ISAPI and rewrite urls so that http://wikiserver/topic/subtopic/page is equivalent to http://wikiserver/default.aspx/topic.subtopic.page -- JoseAS
• Another fun "feature" of using Div here is that the width of the content pane varies based on the type of markup in the content. Makes it fun to watch the kinetic contrast of the white content pane adjacent to the black menu bar.
• Export selected topics to a Word document. I picture an embedded WinForm control that allows you to drag/drop sort and indent all of the wiki topics (or selected ones) and then export to a Word Document. This could possibly turn into a collaboration with SharePoint Portal Server. -- DavidCornelson
• Shouldn't spaces work for lists? I noticed you have to use tabs in here. -- DavidCornelson
• The ability to customize the default template when creating a new page.
• Implement default behaviour when leaving the search textbox, after filling in a string to search for. So without pushing te search button
• Support a list of escaped-by-default words. If my company name is MacroSoft, I don't necessarily want to have to escape it every time I type it. -- KevinD
• 03.06.2004 - mechanism to convert CSV formatted records into a table. Perhaps by enclosing the comma delimited content in specialized tags/format characters: [|| < comma separated fields in rows > ||] I've created a little foxpro routine to convert my data into the || formatted tables but then it's hard to re-convert the data back into something I could use in excel, etc. Why not just keep it in CSV format and be able to copy the data back out to other formats, rather that parsing the || characters. -- ChrisJefferies