Future plans for the wikitools module
cwgordon7 - February 25, 2008 - 23:37
| Project: | Wikitools |
| Version: | 6.x-1.0 |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
While I was maintaining wikitools by myself, I came up with a bunch of plans for future expansion of the wikitools module that I kept to myself, hoping to implement later. Now that rötzi is back to co-maintaining, though ( :D ), thought I'd just post some of my ideas here so we can collaborate.
- Allow multiple wiki paths. This would have the advantage, say, of making freelinking/blah redirect to the wikitools page without having to have a "hijack freelinking tools" checkbox. There are likely many more advantages not yet thought of.
- Wikitools "toolbox" block with useful wiki options, e.g. permanent link, page history, etc.
- Ability to move content into and out of the wiki. This could be achieved without any database tables of its own, and could be a completely optional feature, thus maintaining lightweightedness.
So, tell me what you think of these ideas :D.
#1
Multiple wiki paths: Apart from 'freelinking' I don't see the benefit of multiple wiki paths. The input formats can only link to one path anyway. So every wikilink will point to the same wikipath (e.g. freelinking always to 'freelinking' and pearwiki_filter to whatever your wikipath is). If you have multiple wikipaths this is more confusing in my opinion.
Toolbox: Good idea.
Moving content in and out of wiki: How would you do this without an additional database table?
#2
@Multiple wiki paths: just thought it was a good idea not to try to specifically hack the freelinking module, a more generic solution is possible; plus in the future other modules may want to integrate as well. But I can deal without this.
@Toolbox: awesome, I'll start a patch.
@Moving content in and out of the wiki: I'm not sure if this can be achieved with the nodequeue module, but I think it can. It would definitely be an awesome integration feature. Of course, this would have to be 5.x only until the nodequeue module is ported.
Another idea, a taxonomy term (or group of terms) that puts content in the wiki if it's tagged with it, out of the wiki otherwise.
Of course, it may be easier just to (gasp) provide our own table. ;)
#3
What about merging in a filter of some kind so that this becomes a more complete wiki solution? It'd be great if freelinking merged with this, providing a nice filter and then no hijacking would be required. It'd also simplify setting up a wiki for users.
#4
I had another idea about simplifying wiki setup: A module which gives a high-level interface on various other modules which form a wiki. I made a skeleton lately and put it in my sandbox now. It would be a central place where you can change all settings related to wiki functionality without the need to go into every settings page of other modules. This should be a greatly simplified view of the other settings with the intention that if you needs a more elaborate setup you go back to change individual settings of all related modules.
About a filter in wikitools: I would rather not have one in wikitools. The idea of the module was about providing what other modules didn't do and trying to tie them together. An easy setup should be achieved with better documentation or by automatically setting up the other modules (the basic idea of the "wiki" module in my sandbox).
About grouping wiki pages: Using nodequeue or taxonomy or organic groups would work (you need a database table, but if we can use one of another module I would prefer that ;). I would probably go with taxonomy, but it doesn't make a big difference. The main advantage being that taxonomy uses revisions which neither og nor nodequeue does.
When you start grouping wiki pages, a basic idea would also be to have wikilinks inside one group point into the same group (e.g having different wiki paths for each group of wiki pages). At the moment this is not possible (See #226963: Context-aware filters). What we could do at the moment would be to have just one group of wiki pages and for example provide the possibility to select a taxonomy term and only if that term is present a node is considered to be inside the wiki and "wiki/Page" will then only consider these nodes when resolving names.
#5
I like the idea of further modularizing wikitools— this would go with its philosophy of being as lightweight as possible. Perhaps each of the options wikitools provides (unique titles, delete protection, etc) should be provided as a sub-module of the wikitools module, with a core module providing the settings page?
#6
It would be nice to have an option for multiple wikis.