Hi everybody,
I'm developing a new Wiki Engine for Drupal under project name Liquid (name suggestions are appreciated) and would like to hear if you had some suggestions on features that should be included. ANY suggestions are welcome, but please read the rest of the post to verify that the feature has not yet been implemented ;) .
The engine is currently built up of three modules:
- Liquid Core: Handles basic wiki funktionality.
- Liquid Node: A simple wiki node type.
- Liquid Filter: A package of wiki filters.
Liquid Core
The main feature of the core module is the implementation of wiki name binding, which allows insertion of arbitrary Drupal nodes into the wiki. A node is inserted into the wiki by binding a unique wiki name to the node. When inserted, the node can be accessed on the uri /wiki/{wikiname}. The uri binding is implemented using either the path module or redirects depending on your settings.
There are basically two ways to insert a node into the wiki. If the node already exists, select the tab named "wiki" while viewing the node (assuming that you have permission "administer wiki"), enter a wiki name and press insert. Otherwise, you can surf to the page "/wiki/{wikiname}". Provided that no page has been inserted with the given wiki name, Liquid will show a page with the text (There is currently no text in this page) and two tabs: "view" and "edit". Selecting "edit" will then bring you to an add node page (with node type set by the default wiki type setting) and as you submit the form, the new node will be inserted into the wiki under the appropriate name.
Apart from insertion, the "wiki" tab mentioned above also allows the user to move the page to a new wiki name and to remove the page from the wiki (this will not delete the node, just the wiki name binding).
The Liquid Core currently support the following settings:
- Default Wiki Page. The wiki name of the default page in the wiki. This is the page to which requests to
/wikiare redirected. This is especially important when using breadcrumbs. - Default Wiki Type. This is the content type used when new wiki content is created as described above
- Set Breadcumbs. If checked, Liquid will set breadcrumbs to
Home >> eikiwhen viewing nodes in the wiki. Home will point to/and wiki will point to/wiki. - Use Path Module. If checked, Liquid will use the path module to bind the
/wiki/{wikiname}uri's to the appropriate nodes.
Moreover, for each content type you can select:
- Enable Liquid Wiki. This must be checked before you can insert/move/remove the node to/in/from the wiki.
- Tie title to wiki name. When checked, the title of the node will be tied to the wiki name (provided that the node has been inserted into the wiki). This means that title field will be disabled when editing the node and the title can only be changed by moving the page in the wiki. The binding between title and wiki name is implemented by a encode/decode function pair that replaces _ with space.
Liquid Node
Implements a simple node type named wikipage. Currently the only diferense between wikipage and page is a new permission named "edit wiki page" which does not require you to be the author of the page to edit it.
Liquid Filter
The module is intended to contain a selection of the most common wiki formats around. Currently, the module supports a rather large subset of the MediaWiki format (used by Wikipedia).
Things I plan to do:
- Add a content type setting named "Force into wiki" which forces new nodes of the type to be inserted into the wiki, using either the title (if tie to title is enabled) or textfield indata as wiki name.
- Create a more detailed permission system for inserting/moving/removing nodes. At the moment only "administer wiki" exists and pages can be inserted on creation as long as you are allowed to create content (which is a security problem).
- When choosing to edit a non-existent wiki page, there should be an option to display a list of possible wiki content types (those for which wiki is enabled) for the user to choose between instead of just selecting the default wiki type.
Well, I think that's about it. PLEASE help with suggestions
Comments
Maybe add the posibility to
Maybe add the posibility to make wiki pages directly from Create Content ?
Be smart, Think Free, Choose OpenSource
I believe this is already possible, depending on what you mean
Thankyou for your suggestion Cool_Goose!
Wiki page nodes (the Liquid Node module) are just ordinary nodes and as such are listed in the create content menu. However, creating a wiki page node will not automaticly insert it into the wiki. The "force into wiki" feature I was talking about would probably solve this problem in 99% of the cases since it would require the user to provide a wiki name at creation and insert the node into the wiki.
There might however be situations where you would like to insert a newly created node into the wiki without the huzzle of first creating and then inserting, so I will add a "insert into wiki with name" feature in the create node form to the todo list.
Regards, Sören
good idea
Treate wiki page as normal node would make it more flexibility.
Could you explain, please?
The term "wiki page" could refer to two things: nodes (of any type) that has been inserted into the wiki (will use the term "wiki content" for this) or nodes of the specific type "wiki page" (not nescesarily inserted into the wiki).
It is also hard to guess what you mean by "treat wiki page as normal node". In what sense? All wiki content is drupal nodes that have been inserted into the wiki so I fail to see how it could be treated more like "normal" nodes. If you are refering to the content type "wiki page", this is just "any" content type, with the exception of the extra "edit wiki page" permission (which might be considered obsolete with the new "edit wiki content" permission from the liquid base module). Also, if you believe something to be more flexible. Take your time to explain in what way (provided that it aint obvious).
Finally, note that you are responding to a rather old post. Many things have changed in liquid since I wrote this. Take your time to read through the thread and try out the released ALPHA of liquid. The things you are missing might already be implemented...
Regards,
Soren
Is this module suitable for my needs?
I want to build a page that has several sections. Some sections are mandatory while others are optional. User need to give content for each mandatory section. And on submit it should go to approval queue. Once publish, there should be index links on top of the page, clicking on these links will take user to that section of the page listed below.
This page can be edited by group of people who are authorised to do so.
Now each section should have a edit link that is displayed only to users who are authorised to edit the page. Clicking on this link should open only that section for editing.
Will your module allow me to have above wiki-like functionality?
Thanking you, in anticipation.
Demo Site?
Over the past few weeks I've been searching for a CMS and a wiki. I have Joomla setup with MamboWiki. Unfortunately, I'm having serious problems with Joomla because of their session management and am confident if I choose a different CMS it will work.
I would like to try Drupal next. Is there a site I can see this module in action?
Availabe here...
A CVS version of this is availabe here:
drupal.org/node/53517
Also, still early on enough to add to so if you notice features you want then they may make it into the final version.
No Demo Site Currently Available
I'm sorry to say that I'm currently not running a demo site for Liquid. A demo of Drupal (without Liquid) can be found at the Open Source CMS site. If you want to try Liquid I suggest that you download and install Drupal and Liquid on your local machine/server.
Please note that Liquid is ALPHA software and poorly documented. There should be no problem installing liquid, but the access sytem is somwhat hard to understand if your not used to how drupal handles node permissions and access grants.
I whish you good luck!
Regards,
Soren
Have you had a look at the
Have you had a look at the PEAR Text_Wiki package?
http://pear.php.net/package/Text_Wiki/
It's good written, modular, and it supports different wiki dialects. If you plan to add support for more dialects, you could improve the package itself, providing a more general contribution. I already modified the existing wiki module to integrate the Text_Wiki package: it's very easy, it would take you only few hours.
Ciao. Mic
Very Interesting
At first glance, this seams to be just perfect for the filtering module of Liquid. Provided that you are right about the "good written, modular" part, Text_Wiki will soon be a part of the Liquid filtering package.
I've just finished four hours of rewriting the MediaWiki parser for use in Liquid. I suspect that most other wiki parsers are as poorly implemented as MediaWiki, so this is really a blessing from above!
Thankyou!
A short followup on Text_Wiki
I have integrated Text_Wiki with the Liquidfilter module which means that it now "supports" the following wiki markup formats:
Bad news is that Text_Wiki as a rather new project and the design has not yet been adapted to more advanced features like templates, skinning or integration with existing systems like Drupal. Moreover, the current state of Text_Wiki only supports limited subsets of the markups (sometimes even incorrect parsing).
The conclusion is that Text_Wiki might evolve to something VERY usefull and since I don't plan to implement and maintain parsers for all the abow markups I'll stick to using Text_Wiki at the moment. For completeness, Ill include a fullfeatured MedaWiki parser (a rewrite of the original parser that I've allready completed).
/ Soren
Markup schemes
I am a big fan of Dean Allen's Textile markup scheme. I think it has a lot to recommend it compared to the standard wiki markups.
MT-Textile 2 was written in Perl by Brad Choate for Movable Type with extensions to Allen's Textile syntax.
TextilePHP is a PHP port by Jim Riggs of Textile 2. Riggs and Choate have attempted to keep their work in sync.
The most complete markup syntax must be xilize. However, this is written in Java and is designed for the client side so it may not be feasible to work it into the wiki.
Both my students and I have found that Textile2 (the enhanced Textile by Brad Choate) is easy to learn, logical, and with orthogonal syntax which is easy to remember. So if it's possible to incorporate the TextilePHP listed above as a wiki input syntax I think that would be super triffic.
Mark Pearson
Destructional Technologist,
Earlham College
"Beware of geeks bearing gifs. Or, if you like, just beware of geeks"
Use the textile.module
See http://drupal.org/project/textile
Just a notion on permissions
This is a wonderful permission, and something that I could see people using this module for ... just for that permission.
Which leads me to this: Any way to meld or interact with CCK so that you can have different wiki types, so that a group of people can edit wiki type A, but another group can edit wiki type B?
Also, it would be good if the existing wiki page will always display until user A's changes are approved. (This problem of modified-and-not-yet-approved pages being unpublished has arisen with the Handbook pages on Drupal.org -- forgive me if this has been addressed in 4.7 in general.)
Very excited about this module as wikis come up all the time for us with clients.
As for names, I suppose "Driki" or "Wikal" are too silly. Liquid seems very descriptive for your concept so my vote is to run with that!
Laura
_____ ____ ___ __ _ _
pingVision, LLC • BlogHer • rare pattern • scattered sunshine
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
Re: Just a notion on permissions
Thanks for your suggestions, Laura! I'm quite new to Drupal in general and not familiar with all development projects going on. Thus, I'm not familiar with the Content Constuction Kit at the moment, but I will look into it as soon as I can.
However, the problem you describe doesn't seam to require two different node types. What you need is a way to set permissions on groups of nodes. Grouping nodes is handled well by the taxonomy module, but at present time there seams to be no good way to set permissions on context basis. The taxonomy access module supplies a simple way to grant view, update, delete and create permissions using hook_access_grants, but this will only work in the simpler cases. Moreover, it seams that the taxonomy access module still suffer from several severe bugs. The ideal solution would be to rewrite the Drupal whole access control system to grant/deny access depending not only on who you are, but also on what context you are in. However, this is way out of topic for the Liquid project.
I've just checked and the modified-and-not-yet-approved problem has not been solved in Drupal 4.7 beta 5. This is just another manifestation of the fact that Drupal hasn't been designed to support community editing. Another feature that is missing is a way to handle concurrent editing (preferably without setting locks). None of these things are wiki specific and should be implemented into the Drupal core. This will require lots of time so I won't look into that at the moment. If you need a fix right away, I suggest that you patch node.module so that the latest published version of the node is displayed, unless you have permissions to see the current version. It's a hack, but it will solve the most imminent problem of not seeing the node at all.
Finally, about the name. I agree that both "Driki" and "Wikal" sound a little cheap. I'm starting to get used to Liquid so I might stick with it in the end. But I'm still on the market for something better, so just shoot!
Sören
edit all standard for every node type
Why do we need new modules to implement "edit all?" This is a pretty basic permission. It's been added for book pages in 4.7. Seems like this should be a standard for all node types. Perhaps it might be a good thing to suggest for 4.8?
There are several things
There are several things that need to be incorporated into drupal to make drupal suitable for community editing projects such as wiki systems and similar. A permission that allows editing of a specific node type is just one of them.
In liquid, the "edit by anyone" permission on the wiki page node has become obsolete, replaced by the "edit wiki content" from the liquid_access module (not a separate module in the current release, but in the one that is to be released soon). I will probably remove the permission from the wiki node unless someone has a good reason why I shouldn't (If you do... pleas notify me).
An even more important feature that has previously been discussed on this thread is support for concurrent editing. Concurrent editing is no big problem when only content owners and content administrators can edit a node, but when editing is open to everyone the situation is different. Drupal should be able to cope with several users editing the same node simultaniously. I personally like the way MediaWiki sovles this problem by using diffs to merging the changes. The way I see it, locks is no solution to this problem. I might have to consider including suport for concurrent editing into liquid untill the support is added to the Drupal core ... we'l see.
Yet another thing that should be reconsidered when it comes to comunity editing is how content approval is handled. The current solution of making all revisions (also published ones) unavailable while waiting for the latest change to be approved has several problems that have already been descussed on this thread.
To sum things up: I believe it's a good idea to suggest that the change is made to the drupal core. I do also think there is a need to start a project with the aim of making drupal more suitable for comunity editing projects.
Regards,
Soren
content approval and concurrent editing
The content approval process is a major issue. Utimately, it would be nice if Drupal could display the most recently approved revision/version and include a notice that a new version is awaiting moderation approval. If anyone comes up with code to implement this and argues for its inclusion in core, be sure to mention how helpful this would be for the Drupal handbooks here on drupal.org. And let the Drupal doc team know, too (via the documentation list), so that they can offer their support of that need.
As for the concurrent editing, I agree that would be nice plus. But probably not as important as dealing with the moderation issue. Concurrent editing only affects those editing a text; the content approval process is a usability problem for all users who access it. In my work with the docs team, I can't remember the last time concurrent editing was an issue (I might remember someone mentioning it once in the last few years?). But the moderation problem pops up again and again because users get frustrated when they can't find a page they are looking for.
Workflow?
Hey,
I haven't personally used it yet - but wouldn't the workflow/actions modules take care of this type of problem? Those modules are specifically designed for creating more complex publishing structures. Granted, I think it could be easily argued that these modules should be incorporated into core - as well as some of the access modules. But I dont' think we should forget about what's available.
-Ryan
--Ryan
Ryan Cross
James Cross Construction Services
Project Management Software
Content approval and concurrent editing in connection with wikis
I agree as to the importance of modifying the content approval process. This is a serious problem for moderated sites. However, since most wiki sites are non moderated, this might not be a very large issue in connection with Liquid. I may be wrong, but I feel that concurrent editing may be a much more serious issue in the context of wiki systems.
The "community culture" that develops around a wiki is quite different to the one around the Drupal documentation. Just the fact that only the drupal docs team are allowed to edit the content does a huge deal. Also, the nature of the content may be more volatile. The prime examples are wiki brainstorming and talk pages. In both cases (especially brainstorming) a page may be edited many (>40) times during a very short time period (1-2 hours). In such cases, some support for concurrent editing is required.
The problem with how drupal handles concurrent editing is that it doesn't handle it at all. This may result in content being lost without no one ever noticing before its too late. For those of you not familiar with the concurrent editing problem, here's a short explanation:
Say that A stats editing a page. While A is working, B also decides to edit the same page. Since A has not yet submitted his changes, B starts out from the original version. Now, depending on who submits first, one of the changes will be lost. Say that A submits his changes before B. Then B will overwrite A's changes when he/she submits. Since Drupal does not care about concurrent editing, B will not even be notified what happened.
The best way to solve this problem is to let Drupal merge the changes by A and B when possible. This may sometimes be quite complicated but a solution similar to the one in MediaWiki would suffice. A far simpler solution would be to implement a variant of optimistic locking. In a system implementing optimistic locking, B is denied to submit hes/her changes as they are changes on an outdated version. This is far from optimal, but it would solve tha main problem of content getting lost without no one noticing.
When a distributed system of such magnitude and quality as Drupal does not handle concurrency at all, something seams to be wrong.
However, I may be wrong...
Best regards
Soren
editing content--more wiki like
Currently, anyone on drupal.org can edit the book pages that they created. Once 4.7 goes stable, it's likely that the handbook access will be switched over to allow everyone to edit any page in a more wiki-like manner. The revisions tabs will also be available for everyone to view (although only doc teams can revert a version).
I think this will increase the amount of community involvement in editing existing handbook pages which raises the amount of pages that will need moderation review. So this issue of handbook pages completely disappearing while in moderation becomes even more of a problem.
Furthermore, I suspect that the concept of moderation, while not indicative of wiki communities in general, might be an effective workflow component for guaranteeing quality in many wiki projects. This would allow wiki communities to implement some approval gatekeeping process. I know that this has not been standard in the past with wikis, but could that be because wikis do not have the necessary features for implementing such a moderation process?
Templates with Params
Hi Soren,
Here's another Swede (Gavle) with a bent for wikis. Yup, I know what's needed (to start with) when working with wikis; Templates. I mean, simple templates (simplicity is the point with templates anyway, right?).
*Content* templates. One page = one template.
Replacing template-tags (or "calls" for a template page) is very powerful. See for instance http://www.rilbible.org. There you'll have to dive through several layers of templates before finding actual text content... only templates calling template calling templates.
Templates must be able to handle "ordinal parameters" (first, second, third...etc) to be sent to the templates ("transparently" through chains of templates). Example: Calling a template with params:
{{templatename|param1|param1|param1|param1|Default text to be shown if nothing is returned}}
The target template (or any page really) represent the params with the following representation:
{{{1}}}, {{{2}}}, {{{3}}}, {{{4}}}...{{{n}}}
'templatename' must not necessarily be a dedicated template (although it could). Like in MediaWiki you can "call for" any page content by simply adding a colon in front, like:
{{:anypagename_really}}
A real killer would be to allow for "calling" external pages, i.e. url's. What for? Yes, scalability. Often a page or part of a page content is so different in type or kind that certain categories of pages or page sections can be stored as separate pages on different sites. Calling for them by name and insert them "as is", that would scale! [edit: Well, no, it probably wouldn't add anything to scalability, due to the way caching works, and moreover, this is serverside stuff etc, but at least it would be a useful way of "physically" separating different kinds of data].
Well, that's exactly what I just tried to do with the Bible verses (actually referencing both Drupal pages and other MediaWiki pages on other wiki-sites (aka InterWiki)). I was trying to referencing external Bible Commentary pages (separating "user input data" from the more static autogenerated stuff even simplifying "everything", from data maintenance to managing data input (backing up the "dynamic" user input data separately from the huge shunks of static data)).
Remark, being able to call for a "template" by external url's doesn't blur the simple concept of calling internal page content using "internal calls" (i.e. only the page name, assuming similar "file path" before the page name as the path of the calling page).
All this would be very very powerful in all its simplicity!
And redirects. Redirects from one page to another is needed in any wiki where you need to maintain page addresses (avoiding link-rot).
I've been thinking about using Drupal instead of MediaWiki, but the template handling in MediaWiki is powerful and I can't do without it. Unfortunately I'm only mastering Delphi/Pascal! Let me know when I can start using Drupal Wiki with support for templates and params! :)
Regards,
// Rolf Lampa
Templates are on the menu!
You are definitely right about templates, although they are not needed for basic wiki implementation, they certainly add to the flavor.
I'll se to that the liquidfilter module is designed with templates in mind so that they can be added at a later stage (I don't have time for it at the moment)
(and just to make things clear, I'm not a Swede)
Yours virtually,
Soren
consider tiddlywiki's
I'd like to suggest you consider also the possibility of the tiddlywiki variety
checkout http://www.tiddlywiki.com for the original
and
http://www.patrickcurry.com/tiddly/
for a php server side version that could easily be adapted for drupal, the php code is freely available on the site.
Could you be more specific?
What exactly is it you want me to consider about tiddlywiki?
Tiddly wiki is a variant on
Tiddly wiki is a variant on the wiki concept whereby the wiki is really a single page application. clicking on a wiki link doesnt force you to download a new page but instead it just expands the node within the page, makes for a very compact and fast wiki browsing and using experience. So what I'd like you to consider is would a tiddlywiki variety be one of the possible options when creating a new wiki.
I'm sorry to say that,
I'm sorry to say that, at the moment, I find three reasons not to implement a dynamic HTML based editing interface into the Liquid module:
1. Every use case in a system should be implemented in a way that it can be completed by all users. In the context of a web-based UI this means that all central parts of a use case should be implemented using standardized web technology. Unfortunately, dynamic HTML has not been properly standardized and may be implemented differently in different browsers. It doesn't help that several implementations (especially IE) suffer from bugs. Since I consider Edit Wiki Content to be a very important use case in a wiki system, I wouldn't recommend implementing it using dynamic HTML.
2. The TiddlyWiki approach suffers from a design flaw with respect to concurrent editing. The wiki code for a node is downloaded to the client as the node is displayed and may not be synced with the current version on the server at the time the user starts editing it. This is a problem as there might be a considerable time gap between the time the user loads the page and the time he/she chooses to edit the node. One can never avoid concurrent editing (without setting locks), but you should at least be working with the latest revision when you start editing...
3. A dynamic HTML based editing interface is not a wiki-specific feature and should probably be implemented as a separate module.
To be honest, I find the editing concept of TiddlyWiki to be an example of how dynamic HTML can be misused to create flashy effects that doesn't add to the actual functionality of a system. On the contrary it introduces several problems such as the ones mentioned above. There are cases where dynamic HTML really does the work - a perfect example would be the resize feature of the text fields in Drupal forms - but generally I believe that dynamic HTML should be avoided as long as a feature can be implemented without it.
Correct me if I'm wrong.
Regards,
Soren
+1
This sounds great. Exactly what Drupal's been needing in terms of wiki functionality.
Agree
Excellent contribs
Apache is bandwidth limited, PHP is CPU limited, and MySQL is memory limited.
Permissions
Here are my suggestions for the permissions to have.
Administer wiki -- administer main wiki settings
Manage wiki -- allows for inserting/moving/removing arbitrary node types
Create wikipage -- allows for the creation of wikipages
Edit wikipage -- allows for the editing of all wikipages
I would stay away from advanced node_access stuff -- let organic groups or taxonomy_access (for example) handle that for now.
A block showing X last wikipages (edits + new) would be good, including an RSS feed of edited + new pages, i.e. wiki/feed
What about linkbacks?
A part of the filter that auto-links usernames to their profile page and/or redirects wiki/[username] to user/uid
Hierarchy using naming conventions? e.g. wiki/SomeSection/SomeChildPage
We've got lots of ideas, just not a lot of code at this point. Let me know if you have any issues in applying for a CVS account and creating your project page.
The permission system for
The permission system for wiki's certainly needs rethinking. Here are some loose thoughts regarding your suggestions
* Administer wiki -- administer main wiki settings
All administration of the wiki is currently done in the administration pages and is thus protected by the access administration pages permission. This has the disadvantage that only administrators will have access to the main wiki settings, but this would generally not be a problem (or am I wrong?).
* Manage wiki -- allows for inserting/moving/removing arbitrary node types
This is the permission that i have called "administer wiki" in my initial post. Your name is better!
* Create wikipage -- allows for the creation of wikipages
* Edit wikipage -- allows for the editing of all wikipages
These permissions are currently handled on a node basis in the ordinary Drupal manner. I just came to think that one might be interested in adding a "edit wiki content" and "delete wiki content" permission which grants editing/deleting permission to content, not normally editable/deletable, as long as it's situated in the wiki. This would however require that the Manage wiki permission is split into two permissions: one for move and one for insert/remove. This might, however be the logical way to handle things.
>> I would stay away from advanced node_access stuff -- let organic groups or taxonomy_access (for example) handle that for now.
I totally agree. Liquid should not become a large hack to get around design-based restrictions in the drupal core. I might dive into the problems of the drupal access control system, but then it would be with the aim to help enhance the drupal core, not to produce a wiki module....
>> A block showing X last wikipages (edits + new) would be good, including an RSS feed of edited + new pages, i.e. wiki/feed
Not sure that this should be a part of the initial Liquid release, but it's certainly something I will consider adding at a later point. Until the, its quite simple to get this functionality by creating a block with some simple php code.
>> What about linkbacks?
Not sure what you mean, could you be more specific?
>> A part of the filter that auto-links usernames to their profile page and/or redirects wiki/[username] to user/uid
I think that auto-links to user names is out of topic for the wiki filters, but it might be an interesting filter to combine with the a wiki filter. I do, however, like the idea of some kind of link to the user pages. One should probably avoid using wiki/[username] since it might collide with wiki names, but a namespace approach with user:[username] would work. One should probably also consider adding a tab to the user profile with a wiki page for each user.
>> Hierarchy using naming conventions? e.g. wiki/SomeSection/SomeChildPage
I can see what you mean, but could you give some examples when this feature would be helpful? I cant think of any situations that couldn't be handled better by taxonomy at the moment.
>> We've got lots of ideas, just not a lot of code at this point. Let me know if you have any issues in applying for a CVS account and creating your project page.
Thanks! It's good to know that there is help to get if I screw up :D
Yours virtually,
Soren
Liquid Project created on Drupal.org
I am happy to announce that a project node has been created on Drupal.org to handle the Liquid Wiki Engine Project. An alpha of Liquid, based on your suggestions, will be released shortly. The alpha will be targeted at Drupal 4.7 beta 5. I will post a comment on this thread when this happens.
Future suggestions should be posted on the project page.
Thank you for all your suggestions!
Best regards,
Soren Petersen
Import from another Wiki
From GetWiki.net, this was a nice feature:
A major addition, in a small package, to GetWiki 1.0 is "getwiki.php", which, when there is no article present on our site, imports the XML exported for that same article from Wikipedia, or another XML exporting Wiki, and seamlessly includes
the article on our page.
It's also fairly simple to use. For example;
http://en.wikipedia.org/wiki/Charon_(mythology)
Above is a normal wikipedia entry. Inserting 'Special:Export' before the term will export XML, like such:
http://en.wikipedia.org/wiki/Special:Export/Charon_(mythology)
Having this option available would be fantastic.
PmWiki Import
Importing from PmWiki would also be great.
ALPHA of Liquid is now available for download !!!
I'm happy to announce that an early ALPHA of Liquid can be obtained from the CVS . The version contains the following features:
* Wiki name binding
* Redirects for moved pages
* Wiki access controll system (se the README for more info)
* A wiki page node type
* A filter for a rather large subset of the MediaWiki markup.
As soon as I get time I will release a more complete version of the module (most of the features are allready implemented, but require some testing). This release will contain:
* Support for templates
* A sandbox node type
* Enhanced documentation
* Comments, hopefully....
Note that TEXT_WIKI support has been stripped of the releases (se the forum thread for more info). I still plan to integrate TEXT_WIKI into Liquid, but it will wait untill TEXT_WIKI has reached an acceptabel maturity level. If you need a copy with TEXT_WIKI support for a particular wiki markup language, feel free to contact me.
Talk Pages!
First off, it's incredibly awesome that you're doing this!
I am just starting a project that will have to integrate Drupal and Mediawiki. Part of this was going to involve porting the Mediawiki parser and linker into a Drupal input filter and node type. Maybe I won't have to do that now.
One thing that makes Mediawiki so great is the Talk Pages. Many non-Mediawiki sites are just a mess of mixed content and discussion about the content. The whole reason I'm starting my site is that the other wiki in this particular area is so chaotic. If you could implement Talk Pages that are as easy to use as Mediawiki's, it might mean that I don't have to use Mediawiki at all. Maybe I can even help you out with this.
The other real nice feature of Mediawiki is the way Special Pages are handled. Most of them are just PHP scripts named Special*.php. A similar mechanism would be nice. I know this might seem like it's overriding Drupals module functionality some, but it would remove a lot of clutter from the module admin page if Liquid just had a directory that you could drop Special Pages into.
Templates would be wonderful too.
Thanks for your suggestions
Thanks for your suggestions Spankalee.
I hope that my MediaWiki filter implementation will do for you. The implementation is lacking support for some central features at the moment, including:
* TOC
* Links to image nodes in the wiki are displayed as plain links (will be fixed as soon as namespaces are implemented)
but I will fix this as soon as possible.
I'm sceptic to implementing talk pages for Liquid. The way I see it, drupal allready supplies a good way to discuss node content through the comment module. I'm aware that a talk page would allow a more "free" (as in freedom) discussion, but the limitation of comments does, on the other hand, help to keep the discussion structured, which generally is a problem on MediaWiki sites. Another problem with separate talk pages is that it would create three natural places to discuss the node content(*), which might be confusing for the user.
If you still think the talk pages is a "must have" please submit a feature request on the project page and I'll insert it as an option when I implement hierarchial suport and namespaces.
I'm not sure about the special pages either. I would generally say that all Drupal administration should be handled through the administration interface for security reasons. However, if our just interested in the ability to run php code in the wiki, this is already supported. Just create a page node with input format set to php, insert the code and, finally, insert the page node into the wiki.
And regarding templates: Yes that would certainly be nice! Templates are on the todo list and will be implemented as soon as higher priority features are implemented.
(*) Comments on the actual node, the talk page and comments on the talk page.
Regards,
Soren
-1 for talk pages
No sense in devoting time to a feature which Drupal has, only implemented differently. Besides, seems like to me that the threaded discussion capabilities of Drupal comments for each node are superior to talk pages, not an detriment. Structure is good. Nice thing about the comments is that one can also read the comments on the same page as the wiki page text without having to flip back and forth. Comments will also appear in the recent comments block.
BTW: I look forward to testing the module when I get some time. Thanks for all of your work on this :)
So could there be a way to
So could there be a way to use the Drupal comment system, but show comments on a different page than the content?
The thing I like about Talk Pages is that after something has been settled it can be deleted, and the talk page can focus on whatever the current issues are. It can also work as a scratchpad area. If Wikipedia's Talk Page were replaced by a threaded discussion you'd probably have to wade through dozens of pages of comments to see what's currently going on. To get rid of having three places to discuss a page, I was thinking that I would turn off comments on the wiki pages.
I guess it would probably be a simple hack to add talk pages anyway. All it is is a new tab that links to Talk:Page_Name.
I like your solution for Special Pages, but can a module add content to a Drupal site? Could there be an install script to add Recently Changed, and What Links Here pages, etc.
Let me make this VERY clear:
Let me make this VERY clear: Liquid is NOT intended to be a collection of "simple hacks" and similar party tricks. I don't care how easily a feature could be implemented into Liquid; if it doesn't belong there, it shouldn't be there. I'm not saying that talk pages shouldn't be implemented, I just hope this is the last time I se this kind of argument for including a feature.
With that out of the way, lets look at the feature. I can see your point in letting the community manage the discussion so that only current issues remain on the discussion pages. Using the coment module, this would require some users to have previliges to remove and administer comments. This might be reason enough to implement a talk page feature. A talk page feature should, however, be regarded as an extra option, since I still believe that most users would prefer to stick with the drupal commenting interface.
Drupal does already provide an excelent feature for discussing general content (the comment module) so this is really a low priority feature. It will (probably) be implemented, provided that you submitt a feature request on the project page. If you desperatly need talk pages and can't wait, consider contacting me for a paid custimization (in that case, I'll be able to put other paid work aside to implement the feature for you).
Best regards,
Soren
Let me make this VERY clear:
Whoa, buddy. Chill out. I hope this was just one of those internet misunderstandings, because I'm not advocating any "party tricks". Hacks are not a bad thing, they are a way for someone to add some functionality that wasn't originally there. I think Talk Pages are useful, whether or no you do, and regardless of how they're implemented. I'm not arguing that you should include them because it's easy, and I don't really care if you think Talk Pages should be in Liquid, or not. If I want them there I'm free to download Liquid and "hack" them in myself. That's what I was talking about. No need to pay you.
You are always welcome to
You are always welcome to modify Liquid (or any other Drupal module) to fit your special needs. Thats one of the beauties of GPL. Obviously, I didn't ask you to pay me for doing something that you are capable of doing yourself. I was just offering to help in the case that you didn't know how to add the feature on you own and couldn't wait untill I got the time to do it (I do, generally, prefer not to do paid customizations, since I usually have better things to do).
I understand that we may interpret the word "hack" differently. I normally use the word to describe a "solution" to a problem that is the product of slovenly job. You typically get a hack when you set a deadline that is to tight to allow a "real" solution. In most cases, hacks doesn't consider overall software design or integrity, but just fixes the problem/adds the feature in the simplest way possible. Therefore, with this interpretation, a hack is a bad thing and should be avoided at all costs. When a piece of software is modified in a responsible manner (for instance to fix a bug or add a feature) I generally use the word patch.
I'm sorry if this discrepancy between our interpretation of the word lead to missunderstandings. I did not mean to offend you.
If you decide to create a patch that implements Talk pages, I hope that you will submitt it as an issue at the liquid project page.
Thanks for your suggestions,
Best regards
Soren
I'd like to get involved
Been messing around with Drupal for some time now and I was looking for a project that I might be able to get involved with. I have some PHP experience, but I have very little experience with Drupal modules. But at this point, I'm willing to help in any way with hopes that I can learn the project well enough to hopefully contribute code and expand my knowledge of drupal module development. So I'm willing to help with documentation, cleanup work, etc.
Do you need help in that way?
-- Coplan
bugs some
Thank you soren , what a wonderful contribution.
i'v tried this module, sth need help.
1. zh-cn wiki ID is invalid yet, does it work in non en language?
2. redirect function: when a edit-granted user, click a empty term, it shows "There is currently no text in this page", but no "edit" is available. a small bug i think:[[abc]] only create wiki id, no node is created at the same time.
Any help is much appriciated
In my mind, redirect is the key function in wiki modules, because drupal has a well-structured category system already.
Secondly, a most popular wiki grammar should be involved. The wiki modules of 4.6 is pretty good one in function. But unfortunely, it support phpwiki grammar, not medieawiki.
once again thank you soren.
Deary hesiyu,
To everybody: Please understand that this is the very first ALPHA release of Liquid. Many things will be changed and no documentation/support is provided. I will try to answer all questions about any bugs you may report (but try to report them as issues on the project page). I can however not promise that I will have time to explain why things doesn't work. I am, after all, doing this in my spare time.... :) Thanks for your patience!
Dear hesiyu,
1. Non English Wiki Id support will be fixed soon. See the issue on the project page.
2. It seams that you have confused the concepts somewhat. When the liquid wiki filter encounters a link to a wiki node, [[abc]] say, nothing is done apart from replacing [[abc]] with a link to "yourdrupal.com/wiki/abc". So, no wiki Id is created at this point. Actually, wiki Id's can only be "created" by binding them to a node. This can be done by inserting an already existing node into the wiki or by pressing the edit tab on an "empty" (see 2.4) wiki page.
When a request is made for "yourdrupal.com/wiki/abc" there are four steps to determine what to do:
2.1. If an alias has been created for wiki/abc, the alias is applied. This will be the case if a node has been inserted into the wiki with wiki Id set to "abc" and the use of path aliases has been enabled for liquid (it's on by default).
2.2. No path alias. The request is handed over to liquid. Liquid checks if the wiki Id "abc" has been bound to a node (that is, if the wiki Id exists). If so, the browser is redirected to the node in question.
2.3 If there is a move reference for the wik Id, the browser is redirected to the new wiki Id of the page. A drupal message is set to inform that the redirect has been performed and to enable the user to insert new content at the old wiki Id (this is analogous to the moved page redirect of MediaWiki). Move references are created by moving a node in the wiki.
2.4 Finally, if none of the above applies, an empty page is displayed. The content of the empty page is defined in the liquid settings. It will default to "There is currently no....".
The "bug" you have encountered is probably a problem with your user permissions. The "edit wiki content" permission will only grant edit access on nodes that has been inserted into the wiki and has wiki access level set to normal (or protected provided that the user also has the manage protected content permission or manage wiki permission). The "...currently no text..." is, however, not a node and can therefore not be edited. What actually happens when you press edit tab is that the submit form for the default wiki content type is displayed. Therefore, to be able to see the edit button, you must have both the permission to create nodes of the default wiki content type (see liquid settings) and permission to "create wiki content". If one of these are missing, you wont see the edit tab on "empty"/"nonexistent" wiki pages.
Please take your time to read the section about permissions in the README.txt . I know it's not very well written, but it might shed some light over the liquid wiki access system.
I hope I answered your questions, hesiyu. If not, feel free to post again!
Best regards,
Soren
Dear Coplan
Your offer to help is certainly welcome. Unfortunately, there's not much to help with at the moment. I have already been offered help with documentation (thanks cel4143) and the module is so new that most things are hard to just hand away. The only thing that I can think of is if your willing to implement a sandbox node for Liquid. I was intending to include this node type into Liquid, but I can be released as a separate module if you'd rather like it that way. Since sandboxes are mostly intended to experiment with input filters, they certainly make sense by there own.
These are the notes I jotted down on a sandbox node some week ago:
* The sandbox node should have two extra text fields: "default title" and "default body" (note that these values are set on a per node basis).
* At a given interval (preferably set on a per node basis), the content of the sandbox is reverted to the default values.
* It should require a special permission to see and edit the "default title", "default body" and "revert interval" settings for a sandbox node.
Apart from this, the node should not differ from an ordinary page node.
This shouldn't be too hard to implement so if you are interested, contact me (use the contact form). I'll probably implement the sandbox node at the end of next week if I haven't heard from you before that.
Greetings,
Soren
Dear soren
so much thanks for ur detail explanation. Im sorry for my absent minded when activating the access control, of liquid. Liquid_wiki is done but liquid not thus that happened.
Wiki ID to node structure is good to further expansion, such as changes history list.
Regarding to new features, maitainers of a wiki ID and user's works should be take into consideration. should this submit in feature request?
Some words about threaded
Some words about threaded discussion in drupal:
I realize that you must be new to the threaded discussions of drupal. If you take a close look at the discussion, you will see that your requests/respones have been placed as answers to comments that have nothing to do with your text. This is annoying for the reader, because its hard to follow your discussion (since its spread over the forum) and you are interupting the requests of others.
The reason is simple: when you post a comment in response to another comment, or the main thread you should always use the reply button of the comment (or the main forum topic) that you want to respond to. Drupal will then place the comment at the right place. You have consequently used the replay buton att the bottom of the page, which places your comment as a response to the comment at the bottom. Try to use the right "reply" button in the future... Thanks in advance!
And now, in response to your post:
Please don't appologize. The access system of liquid is everything but trivial and, since it's just an ALPHA, the documentation is vauge and short.
I must however appologize, cause' I just can't understand what you mean by the rest of your post. I hate to step down on other peoples English, mostly because I'm not a nativ speaker myself (which you probably have noticed by now), but your post makes no sense to me. I'm really sorry, but could you try to rewrite it?
Yours sincerely,
Soren
Wiki Syntax?
Perhaps I am missing something but i don't see the possibility to use wiki syntax in this wiki which seems to defeat a lot of the purpose to me. It's all html.
If i put in WikiPage, or NewTopic it should create a link to that page or a link to create that new page.
Am I missing something? This kind of thing seems like it should be the core of a wiki module.
Thanks for you work, looking forward to being able to use this module more.
I assume that you have
I assume that you have created an input filter for wiki markup using the "Liquid MediaWiki Filter" module and that you are using the input filter to save your wiki nodes...
How links are handled depends on the what wiki markup language you use. Some markups create links as soon as you write a word with several capitalized characters, other require you to mark the word as a link. The first version of liquid only has support for the MediaWiki markup (or actually a large subset of it). To crate a link in the MediaWiki markup, you have to use the MediaWiki syntax, that is:
or
Please refer to MediaWiki (or Wikipedia) for information on the wiki markup. (note also that there are some problems with leading and trailing spaces in wiki ids in the first ALPHA of liquid. This has been fixed and the fix will be included in the comming release.
I hope I answered your question... if not, feel free to repost.
Regards,
Soren
OK, I see my error. Thanks
OK, I see my error. Thanks for that. I've got it working. All the previous wikis I have worked with automatically create a link when a WikiPage type syntax is used. Hence my assumption.
Keep up the good work. Apart from some documentation another suggestion would be to have back links, or whatever you want to call them, eg home > wiki > SomePage > AnotherPage
Perhaps this already exists but I didn't see it.
Looking forward to the beta.
How to implement backlinks
Backlinks is a greate idea, but I'm not sure how to implement them. One could use breadcrumbs as your suggested, but it might not be the best approach. Breadcrumbs should, in my opinion, reflect the (hierarchial) structure of a site. Due to the web-like nature of wikis , wiki backlinks may not be a good way to determine the structure of a site. For instance, take the following backlink breadcrumb:
Home > wiki > Main Page > Project Description > Economy > Billing DepartmentI't reflects a posible path through a site starting at the main page and ending at the billing department. I't does however not relect the structure of the site. The natural breadcrumb would probably be somehting like:
Home > wiki > Departments > Billing(ok, one would probably not place this page in the wiki, but just as an example)
To make things more complicated, the next release of Liquid will support heirarchial structuring of wiki pages. This will make it possible to place "ChildPage" under "ParentPage" and I planned to use breadcrumbs to reflect this structure by setting the breadcrumb of "ChildPage" to
Home > wiki > ParentPageWhat do you think? How would you implement tha backlink support?
Best regards,
Soren
Ps. Documentation will be written and included during the BETA phase of Liquid. The reason that documentation has been omited in the ALPHA release is that too many things are changing in Liquid. Documenting Liquid at the current moment would be like trying to catch your own shadow... :) Ds.
backlinks
I think a heirarchical structuring of a wiki is fine, it's usually how I do it and allows me to build a kind of taxonomy within the wiki. I generally find it much clearer than having all the pages everywhere in more of a jumble than a web. If you wanted to bring in more of that horizontal feel you could perhaps add the ability to easily insert a link to a related page or area, or be able to add tags to the page about the content etc.
I'm also really interested in the levels of permissions for the wiki. At present they don't seem to be working for me, unless (and it's highly likely) I am doing something wrong. I want to create admin only areas for files and pages etc. There seems to be the ability to select this but as an anonymous user I was still able to access everything.
thanks.
Notes on the Liquid Access Controll System
The Liquid Access Controll feature is, perhaps, the hardest part of Liquid explain and understand. There's a short description in README.txt. Unfortunately, it requires an in depth understanding on how Drupal handles access controll so it might not be of much help.
The access controll system was created to solve the following problems:
1. The wiki comunity should be able to edit/move/delete (depending on permissions) the content of the wiki, without necessarily allowing the user to edit/delete all content of the specific content types.
2. There should be a way to protect certain pages that are subject to wiki vandalism. Only trusted members of the comunity should be able to edit/move/delete (depending on permissions) these pages.
Both these goals can be obtained using Taxonomy Access, but the module suffers from several bugs, I therefore decided to implement an access controll feature for Liquid. The feature may be removed in the future, provided that Taxonomy Access is fixed.
Note that the Liquid access controll system only grants rights to the wiki user. It never revokes any rights. This might explain your problem with anonymous users still being able to access everything in the wiki (provided that you ment that anonymous can see, but not touch). By default, all users are granted the rights to view all nodes on a Drupal site. If you wish to restrict the rights to view certain nodes you should use Taxonomy Access or an equivalent access module.
I hope this answers your question. If not, please repost.
Regards,
Soren
I'm a little concerned when you say that you could access everyting as an anonymous user. What exactly do you mean? You should be able to view the nodes, but not edit, delete or move them.
Hm, could you please specify what you mean by "able to access everything". Does this mean that you could view the nodes or where you able to alter/delete/move the nodes?
I believe that Taxonomy_Access
being more specific
Sorry, I should be more specific. Anonymous users can view everything but not edit everything. I was looking for a way to set different levels of permissions for viewing also. Sounds like taxonomy_access is the solution there once the bugs. It would be great within the wiki to be able to set a specific page to viewing/editing for admins only.
Thanks.
The last rows of my previous
The last rows of my previous comment was not ment to be published... I should have removed them as they were a part of the editing process, but it seams that I forgot. Sorry...
Please do NOT implement backlinks in a rush ...
There is a much more useful generalization of wiki links. See this extension of MediaWiki:
http://meta.wikimedia.org/wiki/Semantic_MediaWiki
In a nutshell, wiki links are of different kinds as well (just as wiki nodes can be assigned categories). Using mediawiki syntax for now:
[[Cairo]] -- a (untyped) link to the wiki page Cairo
[[has capital :: Cairo]] -- a typed link to the wiki page Cairo; type = Relation:has capital.
Meaning of the above: the current node has capital = Cairo.
The link type itself (Relation:has capital) is another wiki node, hence it can have its own typed relations. Taxonomies of relations (much like Drupals taxonomies of nodes):
Relation:has capital
[[specializes :: Relation:related place]]
So if you ask for all related places of X you should also see the has_capital of X.
Once this is done, entire relations can be declared to be inverses of each other, and "backlink" processing automatically applied to these relations. The underlying basis for this is RDF http://www.w3.org/RDF/ which has a huge amount of public tools applicable to it.
Relation:has capital
[[inverse_of :: Relation:is capital of]]
Which means normal wiki backlinks are just a special case:
Relation:normal back link
[[inverse_of :: Relation:untyped link]]
Sound relevant? Feasible?
Liquid wiki motivation
Hi Sören,
Thanks for the development of liquid, I look forward to when it's available as a 4.7 beta module.
May I ask, what prompted you to develop liquid?
Regards,
Russ
---
Russ @ Firewize
You are always welcome to
You are always welcome to ask. If your lucky you might even get an answer. *smile*
The motivation for creating Liquid is simply that I'm developing a community site which require wiki support. I would normally have settled for a more advanced and well designed web platform, but unfortunately, due to performance requirements, that wasn't possible. I tried around 15 different lightweight CMS packages to conclude that Drupal was the only system based on a resonably sound design. Drupal did however not include a wiki module. Rather than struggling with one of the other nightmare CMS packages I decided to implement a wiki module for Drupal.
I hope this answered your question. Just out of curiosity: why this interest for my motives?
By the way, Liquid for Drupal 4.7 beta is already available for download on the Liquid project page. I'ts still ALPHA and has at least one known bug, but it might still be interesting to try it out...
Best Regards,
Soren
lots of edit links..
wow,
its late and i may have missed if someone suggested this before..
i really like how wikipedia has little edit links on the right on each paragraph..
they allow anonymous submissions that could enter a queue for approval... also, revisions would of course be saved for safe keeping...
i imagine granular permissions for submit edit without approval versus those that need approval
can we have something similar?
im looking for extreme usability for all my ignorant users..
thanks
ryan
thefractal.org
Yes, on the Edit Paragraph links
Yes, I agree. Those Edit Links are WONDERFUL! Before I came to Drupal, I used some Wiki CMS, including Mediawiki (that powers Wikipedia) I really liked those edit links. I wish that ALL content (not just Wiki content) on Drupal, including Books, Stories, Articles, Blogs, etc. could have those type of "edit" lijnks. That makes editing just small amounts of content so much easier, and less risk of messing up the whole rest of the page.
Actually, those "Edit Links" are associated with the headings. For example, whereever you'd use a "h1, h2, h3...." (heading 1, heading 2, etc.), there would be an edit link to the right hand said of that header, that would allow you to edit all the text down to the next heading of the same, or higher, level. Each level of heading would allow you to edit everything (and the content of all lower level headings) under it. For example if you had a block of text arranged:
HEADING 1A __________________________Edit
Text text text text text text text text text text text
Text text text text text text text text text text text
.Heading 2A __________________________Edit
.Text text text text text text text text text text text
.Text text text text text text text text text text text
...Heading 3a ...............................................Edit
...Text text text text text text text text text text text
...Text text text text text text text text text text text
...Heading 3b ...............................................Edit
...Text text text text text text text text text text text
...Text text text text text text text text text text text
.Heading 2B__________________________Edit
.Text text text text text text text text text text text
.Text text text text text text text text text text text
HEADING 1B __________________________Edit
Text text text text text text text text text text text
Text text text text text text text text text text text
If you clicked on "edit" for Heading 1A, then you could edit all the children (h2, h3, etc.) below it. In this example when you "edit" Heading 1A, you could edit everything down to Heading 1B.
Conversely, if you chose to edit text under Heading 2a, you could edit all the text down to Heading 2b, including "Heading 3a" & "Heading 3b". If you chose to edit text under Heading 3a, you would only be alowed to edit text under that on edit, down to, and stop at, Heading 3b.
Of course, you could have multiple paragraphs under each level of headings
Stephen
Winters Sewing
Winters Sewing: Upholstery Information Website
Edit links are fine, but how do we implement them?
I think most people who have used MediaWiki are ready to agree that edit-links on each heading simplifies life in many aspects :).
Implementing these links in a neat and non-hack fassion is, however, easier said than done as no infrastructure is provided by either Drupal nor Liquid. Some of this will be adressed in a comming version of Liquid (not the next one, but the one after that) where I'm introducing a couple of hook points for content filters, allowing them to report important information about content attributes, structure and contained links. The main reason for these features are to keep track of the wiki linking structure and enable building of contentent tables, but it will also help in implementing edit links.
If you know of any easy, yet well designed way to implement edit links, please let me know and I'll fix it as soon as I can. Otherwise, it will have to wait untill it falls in naturally into the development of Liquid.
Best Regards,
Soren
Thanks for the liquid update
Sören,
If you look back in drupal time there have been close to 500 posts relating to the development of a quality wiki module...
Your contribution gives me (a non-programmer) hope....
I have a drupal development site and a mediawiki site which I would like to port over to drupal, so I'll be keeping an eye on your work.
I have offered to contribute $ towards the development of a good quality functional wiki module in the past... My offer still stands if you can get this into a stable product...
Keep up the good work.
Russ
P.S. Perhaps other people could also contribute $ towards this development... Any offers?
---
Russ @ Firewize
Dear Russ, Thanks for
Dear Russ,
Thanks for showing an interest in the Liquid project. I didn't mention it in my previous comment, but the interest and positive attitude towards Liquid in the Drupal community is really a big part of the motivation. I hope that, one day, Liquid will live up to your derams of a good quality functional wiki module for Drupal.
When it commes to money; any contributions are highly appreciated. The downside of non-profit software development is that the projects allways comes in second place compared to other projects that generate revenu (gotta put food on the table). Any economical contributions would enable me to prioritize the Liquid project and thus enhance quality as well as speed up the development.
I would also like to ask you what exactly you mean by a "good quality functional wiki module". What features should be included? Are there other quality aspects than those usually considered in software development (correctness, robustness, compatibility, extendibility, reusability, efficiency, functionality, ease of use ...)? Should any of these factors be emphasised (in your opinion)?
Regards,
Soren
Wiki enhancement proposal
Sören,
I have been keeping an eye on this thread since you started it while maintaining momentum as you have gone along which is also great.
I am a keen contributor to Wikipedia and we use MediaWiki internally as a knowledge base and library for all of our company information (policies, procedures, etc). One of my problems using Mediawiki is that it has been designed to be open to the community, that is that there is no real notion of restricted content access either open, groups or full.
In our case there is some content we would like to share and other content we want to secure. Currently we use Apache security to restrict ALL access to the "World".
In addition to MediaWiki we currently we use Mambo for our main company site which will be converted over to Drupal (4.7 RC-2) this week, we also use phpBB for an industry forum we sponsor.
My goal is to consolidate all of the above into the one platform.
Perhaps further development on Liquid Wiki would be best served by creating a new post under the banner of a Drupal enhancement proposals (DEP).
I hope thes idea of creating a DEP helps in the further development of Liquid Wiki. I also suggest to future proof Liquid Wiki that it be developed within the constraints of core development, this should ensure the future of the project remains strong.
I hope this helps.
Russ
P.S. If you think the idea of creating a DEP is ok, then leave me a message with your email address and I'll send you a copy of a DEP that I have created for the this project.
---
Russ @ Firewize
Interesting...
(This note has also been sent as a mail to rport)
Hi Russ,
Once again, thanks for taking an interest in Liquid. I really hope that Liquid will be able to do the trick for your future plans of moving your wiki into Drupal. I have some questions regarding your last comment in the thread. These questions are a little of topic since they are about the project rather than the product so it might be appropriate to continue this discussion by mail rather than polluting the thread.
I also suggest to future proof Liquid Wiki that it be developed within the constraints of core development, this should ensure the future of the project remains strong.Forgive my ignorance, but I'm not familiar with the constraints you are referring to. What exactly does it mean to develop a module (such as liquid) within the constraints of core development?
I sure like the idea! I'm generally opposed to software development without a proper documenting process. However, since my time on this project has been somewhat limited I have chosen not to be too strict. As the project has evolved it has reached a point where some structuring documents are required to describe the boundaries and aims of the project. After a quick glance at the headlines of the DEP template it seams that the it fills fills the basic needs for structuring documentation at this point.
Its great that you have done some initial work on a DEP as it will save me some time. Please send me a copy.
Yours sincerely,
Soren Petersen
Drupal 4.6 or 4.7?
Hi,
I'm trying to install and test liquid, but I get an error regarding drupal_urlencode(). FWIK, drupal_urlencode() is a 4.7 function? Or is there some other modules I'm missing? Thanks in advance.
Stanley
Please.... post support
Please.... post support questions of this kind in a thread on their own... this thread is for discussing feature suggestions, ideas and so forth.
Yes, drupal_urlencode was not included in the 4.6 releases of Drupal. However, fixing this problem by replacing drupal_urlencode with its php counterpart would not allow Liquid to run on 4.6. Liquid has been targeted towards 4.7 by using the new form api and many other (more or less) 4.7 specific features. Since 4.7 will be released shortly I'm affraid that I won't put any effort into making a 4.6 compatible version.
Best Regards,
Soren
Rep[lacement]Tags
Hi Soren,
Thought this module Rep[lacement]Tags might have some benefit to the Liquid project.
Also congratulations on getting mentioned as a proposed project in the Google Summer of Code 2006. Hope this helps developemnt.
I would be happy to help you write a Summer of Code application if your interested...
Any further ideas on the DEP I sent through?
Russ
---
Russ @ Firewize
Rep[lacement]Tags & Google Summer of Coding 2006
Hi Russ,
I'm sorry that I haven't responded to your letter. My schedule has been overbooked for several weeks now and as soon as one urgent task gets done, two new seams to pop up. I do, however, hope that I'll get time to respond to the DEP and to make a beta release of Liquid before the end of this week. I shall also take a closer look at the Rep[lacement]Tags module as soon as I get the time. I'm not sure exactly what the module is capable of from reading the project page, but it seams promising. Thanks for pointing it out!
I'm honored that Liquid has been proposed as a project for the Google Summer of Coding 2006. I'm, however, afraid that I may not be able to participate. The main issue is that I don't think that I can afford to dedicate three months of full time work at a salary of only 4500 dollar in total. The sad truth is that I rely on my income during the summer in order to be able to finish my studies in pure mathematics during the fall. Anyhow, thanks for offering to help with the application.
Best regards,
Soren
Suggestions
This is wonderful! I've been playing around with this module on my dev site, and I see a lot of potential for this module. I have a couple of suggestions however:
I've found that this plugin (http://drupal.org/project/freelinking) might work well with this wiki as it adds CamelCase and [[wiki]] linking functionality.
As a sidenote: Is there a way to force a new revision every time someone edits a page?
My solution
I don't think there is a way to "force" a new revision each time. But the way that works for me is to change the default settings to include the revision option by default. Most people don't bother changing those type of options, so it has worked so far for me.
--Ryan
Ryan Cross
James Cross Construction Services
Project Management Software
Yes
this would be good if it could do both CamelCase and [[Free linking]]!
it does both
i just used it in a site, it does both.
--Ryan
--Ryan
Ryan Cross
James Cross Construction Services
Project Management Software
i keep receiving the
i keep receiving the following error everytime i try to add new wiki content
Fatal error: Call to undefined function: node_validate_title() in /var/www/modules/liquid_wikipage.module on line 73
any ideas?
tnx
Hasn't been updated for Drupal 4.7 final release
It's a bug. I've made some fixes and will be adding patches.
I had this too
where can we get the fix
Liquid Status
Hi everybody,
As you might have noticed, I haven't been very active in the past couple of weeks. This is mainly because I've had too much to do (and still have) to be able to prioritize Drupal and Liquid. I have, however, not forgotten about Liquid and although it will take a while, I will get back to it and make the promised BETA release.
I have completely rewritten Liquid for the BETA release. Effort has been put into designing Liquid in a more modular fashion allowing for extensions without rewriting the core code. I have concentrated mainly on the core functionality of Liquid (that is, the basic name bonding features), since I believe this to be the most important features of liquid. All reported bugs and most feature suggestions not relating to the mediawiki filter has been implemented.
The current status of the BETA release is:
- Added event hooks for several events (including add/move/remove wiki page) to allow separation and extension of the module.
- Moved all access control code to a separate module.
- Moved the "moved page redirect" code to a separate module.
- Rewritten the wiki-id handling system to handle hierarchical wiki ids.
- Added hook for "special pages", allowing modules to inject "special pages" into the wiki.
- Added support for ISO-8859-1 and UTF-8 wiki-ids.
- Rewritten most parts of the interface.
- (lots of more)
Things left to do:
- Fix problem with url character encoding on some apache + php combinations. This will probably result in a patch for the drupal core as the problem should be solved there rather than in the liquid module.
- Fix some bugs connected to hierarchical wiki-id handling.
- (perhaps some other changes)
I hope you can forgive me for being late with the release,
Virtually yours,
Soren
Code checkin?
Soren -- I've already found some bugs with the final release of Drupal 4.7 and the current version in CVS. If you could sync your dev environment, then we can work on this together.
History Tab?
Hello Soren,
Wow, you're going to become a drupal celebrity when this is done!! ;-)
I'm interested in your work for two reasons:
One thing I haven't found in this thread - this is my "feature request" - do you plan to add a "history" tab? Even if it is not implementing all related MediaWiki features (comparing two versions etc.), a simple list of edits with user/day/time stamp and brief description (if entered by user) would be useful. Let me know if you want me to enter this as a new feature request.
Many thanks!
patrick
G2TT | IMN | Slaw
This feature is already part
This feature is already part of drupal. Its called revisions. Look under Publishing Options
eta?
was just wondering when is an ETA planned for the beta release?
thank you
I'm terribly sorry, but the
I'm terribly sorry, but the answer must be: "I don't know". Could be a fourthnight, could be two months. As soon as possible, but it all depends on how tightly booked my schedule will be during the comming weeks.
ok no worriez, take your
ok no worriez, take your time with it :)
i just got it to work (fixed the earlier bug with the node validate issue) and my only big request so far would be a 'history' option just like with all the other big wiki scripts that allow you to view versions of the wiki back in time...
just my .02 cents :)
ditto for history tab!
*sigh* I should have read the whole page before I posted my reply above... sorry for the repetition. ditto for history tab!
Revisions
Drupal has this built in -- it's called revisions. Make sure you have it enabled for wiki page node types.
There is also a "diff" module that needs some work which shows the differences with past revisions.
Silly question
Hey, silly question but I just looked on the modules page and couldn't find the diff module (i want it unrelated to liquid). Could you point me to the node or wherever it is? Hopefully its available/working with 4.7? Thanks!
--Ryan
--Ryan
Ryan Cross
James Cross Construction Services
Project Management Software
Diff
http://drupal.org/project/diff -- not ready for 4.7, I don't think.
A much-needed module!
Hi Soren,
Kudos to you for taking on this project!
Drupal has such a rich set of user-created content types that I was a bit surprised to see a user-level Wiki functionality missing. I can't tell you how happy I am to see you filling that hole. Again, kudos for tackling this.
How it's done in Tikiwiki
In Tikiwiki, if configured properly, each wiki page has an icon that when clicked, will take the user to a topic for that page in the admin-designated forum. If the topic for that page does not yet exist, it is created automagically. The topic has an automagic backlink to the relevant wiki page. And watches can be set on a forum-by-forum basis, so it's easy to get an email notification when someone comments on a page in the designated forum.
That eliminates the clutter of having comments appear directly on the page, having to set page-by-page watches, etc. It's a system that works well.
SUPER!
Woow,
this sounds cool as I abandoned Drupal because of wiki-absence for one of my sites.
Jan
----
The Smart Boy - Free Scripts and Linux Guides
Support Drupal! - Drupal at Free Scripts Forum
Inserting existing Wiki pages
I am probably missing something obvious.
Having many wiki pages, I am now forgetting what there is to link to.
How do I get a list of the wiki pages that are available to insert?
On the breadcrumb, when I click on home>>wiki, or ?q=wiki, both just takes me to wiki/Main_Page
Thank
Michael
Wiki List
For those who are interested, I managed this by creating a PHP block only visible when editing wiki pages, with the following code:
this provides a listing of current wiki registered page titles.
Edit post per paragraph and wikiwyg
Dear Mr,
I suggest that the edition per paragraph is really a wonderfull feature that allows to build long text while minimizing editing problems. (others have previously presented the interest of this feature).
An editor is especially good providing this feature while allowing users to see the page and the text above and under.
You double clic a paragraph and the editor appears (wiki, wysiwyg, and preview mode). This is simple, efficient and I had like to edit standard text area with this editor.
In my modest point of view, a really necessary tool to edit conveniently wiki or text.
http://www.wikiwyg.net/
http://demo.wikiwyg.net/wikiwyg/demo/standalone/
a really necessary tool to edit conveniently wiki or text
I wonder how everyone advocating paragraph editing survivies in a word processor or WYSIWYG like Dreamweaver ;-)
-----
Charlie Lowe | cyberdash
Tips for posting to the Drupal forums
Nor the same context, nor tool
Dear Mr.
You can not compare these softwares with collaborative editing. Editing per paragraph avoids errors and minimizes their consequences. Thus, to directly answer to your question, I work perfectly with word processors or htlm editors. The main problem is since php revolution, building long document using small and unsecure text areas is painfull compare to using old wysiwyg html editors. The fact that Drupal work with one message per page also tends to produce short pages and unecessary and unreadeable hierarchical document (see Drupal book). Thus, editing per paragraph allows multiple posts per page that could also better help drupal manage long document.
An other solution is to edit directly long documents (odt or doc) using the activex version of writer or word processor. This work mostly (few bugs) in intranet, but does not apply to Drupal post.
Sincerely.
Good points, can't wait for LIQUID!
Good points about paragraph editing. I love it.
One of dreamweaver's best features is the ability to click an element in visual panes to highlight instantly the code snippet it refers to in the code pane. Quick jumping to specific edit focii is crucial. It would be amazing to have this built-in using javascript "onclick" so that you could just click a paragraph and jump to it without having a dedicated "edit" link next to it like MediaWiki
which I use now
I like this feature..
This feature is really helpful in collaborative environment.
I wonder how is this implemented? Any guess?
I'm really interested.
What all will be required to implement this in Drupal?
I get The wiki ID 'Main
I get
The wiki ID 'Main Page' is invalid.when trying to edit it.Latest Status?
I was wondering if anyone can tell me the latest status for this project? I noticed that the latest CVS updates were at the end of May 2006. Is more work being done behind the scenes?
Thanks,
Bryan
CMSReport
Answer to my own question
Looks like Steven Peck answered this question just a day or two at: http://drupal.org/node/77321#comment-143006 .
-Bryan
Feature request: Redirections
Kudos to the devs for this module! I just had a chance to try it.
A feature I would really like to see are redirections not only for moved wiki IDs but also from multiple IDs pointing to the same wiki page (think "colour" --> "color").
Another thing: There should be the possibility to delete the reference of a moved wiki page along with the page itself (or all references if the feature above should be implemented).
take a look at
take a look at tikiwiki.
with it, you can use wiki on everything. all content can be the wiki itself. articles can link to wiki simply by using WikiWords. very great concept that imho should be into drupal.
rgds,
rex
www.NGoBRoL.com
Is Liquid still alive ?
Hello,
I need to set up a wiki. I have seen only the liquid module. It seem to have no developpment on this module any more. I installed this module (drupal 4.7.3) and tried a test page :=> bug
Fatal error: Call to undefined function: node_validate_title() in c:\program files\easyphp1-8\www\drupal473\modules\liquid\liquid_wikipage.module on line 73
Should i use another CMS like tikiwiki as suggested in this previous post, or is there another solution ?
Thank you for any answer.
Really dead ?
Nobody to react, any explanation why this module seem to be dead ?
Comment out line - not the best fix, but works
I just commented out the line. Not the best fix, but it works for now.
function liquid_wikipage_validate($node) {
// node_validate_title($node);
}
liqwid or liqwiki
would be seriously google friendly, being a new word...
Ian Dickson - community specialist.
www.emint.org - Association of Online Community Professionals
Drupal 5.0
I've started working on getting this module to work on Drupal 5.0, since I haven't seen any mention of it being converted to 5.0. I'm new to module coding, so it may take a couple days, but I'm making progress. I have the Wiki Filter module working and I have settings working on the main liquid module. I haven't looked at the wikipage module yet.
I hope you can bring this module back to life
I have a large amount of Wiki information and I'm currently struggling with either migrating all of it into Drupal pages or continuing to maintain both MediaWiki and Drupal. I'd really like to have a single authentication for both and have the option of maintaining content pages in standard HTML or Wiki form.
Since it looks like the original developer has abandoned the project, do you intend to create a new project page for it or continue to use the existing project page? I'm not sure how permissions work on those...
Interested
I'm not sure how to proceed on getting the new code I've worked on into this project. I don't see any contact info for sorenp. I would be interested in becoming the maintainer for this project, but I don't know if that is possible or not.
Here is where the patch to update to 5.0 is located:
http://drupal.org/node/108918
XeQUae
----
http://www.xequae.com
...
If a project appears abandoned, you can request to take it over.
You must try to contact the project owner. If that is not possible through the contact form then file an infrastructure issue requesting to take it over. Site maintainers can attempt to contact the project owner.
You must also have a cvs account to manage a project.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
I'm still here... watching
I haven't really abandoned the project. I just haven't had the time nessecary. There has been development going on but no releases have been made before today.
// Soren
Glad to see you're back
Glad to see you're still working on the project. I'll let you know how your update for 5.0 goes tomorrow.
XeQUae
----
http://www.xequae.com
Thx... Please post in the
Thx...
Please post in the new thread ... this one is getting awfully crowded :D
// Goodnight
Wiki markup
I strongly support efforts to bring Wiki markup to Drupal. I use MediaWiki for other applications and, once you get accustomed to the ease of wiki markup, it is difficult to go back to html on pages. For certain things, like help pages, lists of URLS, lists of anything, etc. wiki markup is superb and much better than html.
So I am extremely interested in a Drupal Wiki module that will allow the use of wiki markup on regular pages. Thanks for your efforts!
If you just want to use
If you just want to use mediawiki markup why not use the pear-wiki.module which not only allows you to use mediawiki markup but also the following Wiki_Doku: Wiki_Tiki: Wiki_Creole: Wiki_BBCode: ?
Tried it
I'm currently trying to make do with pear-wiki now. It's better than nothing, but really isn't cutting it. It doesn't understand many Wiki syntax constructs, has very poor image handling, etc.
A sugestion
My sugestion is a module which would provide Free Linking and/or CamelCase linking inside the wiki. It is a common feature to all wiki's, and I believe it is it that distinguishes the wiki portals from the other kind of CMS.
This extension shouldn't be much difficult to implement if the site is enabled with Clean URLS, and would be great!!
1 Suggestion on Layout/Design and 1 On Functionality
I have used a few free wiki websites and there is one, in my humble opinion has a superior layout/design. If you go to http://accordd.pbwiki.com/ you can check out a page I made as an experiment when I was looking for a good wiki. Notice that when the content gets down past the navigation box, the entire page is available for the content, more like traditional webpages. Also, the menus are at the top and the bottom which also keeps the real estate clean and open for content.
Another feature I have only found once (at a different wiki site), was the ability to paste in HTML code and have the page look like it should.
-Bob
I'm sorry to say that you
I'm sorry to say that you seam to have missed what Liquid is all about. The main goal of Liquid is to provide Wiki capabilities (infrastructural things like naming, access control, general markup infrastructure...) to Drupal. There has never been an ambition to create a Wiki CMS system based on Drupal (read through previous postings and take a look at the module and you'll understand).
Based on this, all layout/design suggestions you have posted doesn't apply. If you would like a layout/design similar to the one at pbWiki, you should implement it as a Drupal theme on your own.
The functionality feature-request is also somewhat out of topic. Drupal already supports HTML input (you should however not enable it for regular users without some kind of filtering). If things look wrong when using HTML input, its probably due to the CSS setup of your theme. Again, I fail to see how this falls within the realm of the Liquid project.
Best Regards,
Soren
Liquid Design and Recent Development
Due to the inactivity and inconvenient size of this thread, the discussion has been moved to http://drupal.org/node/117309. Please post further comments there.
From the start, Liquid has clearly separated wiki markup from other infrastructural details. From the next release of Liquid, the MediaWiki markup will no longer be included as more than (perhaps) an example of how to implement a plugin for the LiquidFilter module. The LiquidFilter module will provide several infrastructural services needed by most wiki markup languages and will also provide a framework to plug these markup modules into. Examples of features that will be supported by LiquidFilter is templates, control over what links to what and headings/table of contents. In later versions may also contain support for showing special blocks and similar functions. However, no markup-specific details will be handles by Liquid itself in the future.
How linking is handled (Free Linking, CamelCae or whatever) is determined by the wiki markup language used and my hope is that as Liquid matures, other developers will start to contribute LiquidFilter plugin modules for several well-known wiki markup languages.
Best Regards,
Soren
Check out Flexifilter
This mod is dead, it took me so long to find the newer options I thought I'd put this here.
http://drupal.org/project/flexifilter
http://drupal.org/project/flexifilter_cite
http://drupal.org/project/wikitools
Drupal needs to re-index their search, maybe? Anyways, the flexifilter + wititools + cite combo should cover things pretty well ;)
wiki permissions only to some fields of the wiki content type
Hi. Working with wikitools module I´ve found that is impossible to asign wiki permissions only to some fields. For example, i would like to give wiki permissions to edit only some fields of some content that is selected as wiki content type (example... i don´t want nobady to change the lenguage field). Hope you consider this for the new module.
Also, there is a bug in wikitool module... is the option of MOVE PROTECTION. It dosen´t work. As you see, if i can choose what field is wiki and what isn´t, then this bug will be no longer a problem.
Excelent initiative! good luck with this new module.