Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By G Fairbanks on
I'm a recent convert to Drupal after running my site based upon JSPWiki for about a year. I'm currently running a fairly simple site (groupedia.com) using the wiki module.
To cut to the end of my story, I've got a re-architected version of the wiki module partially working that implements a new node->format. I would like some help in fixing some bugs and investigating core changes to support an elegant implementation. But first, let me start the story from the beginning:
After a bit of investigation, here's what I've been able to deduce about the architecture as it relates to the wiki module. The wiki module intercepts the module_filter hook and transforms the written wiki-text into HTML. So to write a page using wiki-text, you set the $node->format to be HTML, even though it isn't, but since the wiki module is activated, the wiki-text is transformed into HTML before being rendered to the screen.
The drawback to this approach is that once the wiki module is activated you can no longer write nodes using HTML since they are always filtered through the wiki module.
It seemed to me that what we wanted to do was to add another entry into the dropdown list indicating the format of the node. Currently the only choices are HTML and PHP and these choices are hardcoded in the source code. What I mean is that there is no hook (that I could find) to add a new node format.
So I hacked the code a bit. I've listed the changes here in text but I can post diffs if desired.
1) I added a new entry ( 3 => "Wiki" ) into the node->format dropdown menus in page.module and book.module. That allows me to set the node->format but of course nothing changes in the rendering yet.
2) I edited the wiki.module to remove the module_filter hook -- I just commented it out for now. At this point my pages, which are written in wiki-text, are rendered as raw wiki-text (not transformed into HTML).
3) I added a new clause to page.module::page_content. It already checked for node->format of 0 and 1, corresponding to HTML and PHP. I added another check for type 2, now corresponding to wikitext.
For wikitext, it invokes the _wiki_transform() function from the wiki.module.
4) I edited a page whose format was set to be HTML; I set the format to be Wikitext. Now, when viewing this page, the source text is transformed through _wiki_transform() into HTML and rendered correctly.
What's good about my hacking:
- My site can have wiki text in some places and HTML / PHP in others.
- New modules could be written for other node->formats. For example, there are numerous competing wikitext dialects. When converting my old wiki site to Drupal I had to hand edit over a hundred pages. I can imagine a number of wiki modules that implement different wikitext dialects. Other source formatting possibilites are wide open.
- Less interference with other filters. I've seen that this is already a discussion item. Note however that another filter that is expecting to filter HTML is unlikely to work on wikitext.
- It's conceptually cleaner. (OK, this is opinion). I think that the existing filtering hook is great for modules like the swearing filter or the link creation filter. When the node format just isn't HTML, it seems wrong to say that it is then use a filter to make it HTML later. If this is the preferred mechanism, then why make the PHP and HTML distinction -- you could use a filter to transform PHP into HTML.
What's bad about my hacking:
- The node->format dropdown menus are hardcoded.
- Transformation of wiki text is hardcoded in the page_content function.
- There's still no defined hook to add a new node->format.
- There is a namespace problem. My wiki module just grabbed node->format "2" (HTML is 0, PHP is 1). Using a text string (maybe the name of the module) would be more resilient against collisions.
- More stuff I haven't thought of yet.
I'd appreciate any feedback on this idea. It seems to me that adding a new hook point for format isn't so difficult (though I haven't done it yet). Changing the node->format datatype from int to string is a bigger problem because of data migration and may need to be postponed.
Regards,
-George
elvis+drupal.org@cs.cmu.edu
Comments
diffs
It's probably a good idea for me to post the diffs.
sounds good
in principle, i think this a fine approach.
How about other content?
If we want to add wiki formatting (or other formatting 'standards' such as bbcode), we might want to think ahead a little and wonder how we can add support for other content types such as comments -- and to a lesser extend, custom blocks, user biographies, taxonomy descriptions and so on. It makes sense to opt for a solution that can be used throughout the entire site. Maybe we should think along the lines of a special textarea widget (which adds a selection menu and relevant guidelines such as the 'Allowed HTML tags' message) and some function to filter the content. Having said that, this might be a relevant use case (user story) for those involved with the filter system improvements.
What about Wiki Style Node Creation?
Wiki formatting is a great addition to Drupal, but I would like to see the ability to create a node as easily as in a wiki engine.
Historically this is done by typing a CamelCase word which creates a link to a potential page. However most engines are coming to grips with a more natural approach using brackets to create links, called a Free Link. The success of wikipedia.org is a testament to this simple form of content creation.
Drupal is part way there, with the title module, allowing the simple linking to any node by putting its title in brackets. Going one step further and allowing the creation of a node by this method would greatly increase drupal's popularity with those frustrated by the complication of systems such as TWiki.
I realize that this might run counter to the submission and moderation features of Drupal. Also with the increasing value in taxonomy, simply creating nodes without establishing a category becomes problematic. But perhaps a complete redesign of the way nodes are created would not be necessary to implement wiki node creation, if clicking on the new bracketed link would simply take the user to a special node creation page which would present them with the usual node creation form (book format comes to mind).
Another benefit of wiki node creation is that a natural hierarchy of information is established. A wiki link established in one node, automatically becomes the child of the node it was created from. This is the fastest possible way, at least in the way my brain works, to create semi-structured content. I struggle sometimes when taking notes, or researching a topic, to store that data in drupal because I am always thinking about how to structure my writup around a book structure or a blog. While its wonderful to be able to "attach" nodes to a book, it is not natural when writing a book to have to "create new content" when wanting to start the next chapter or section and manually select the parent. You just want to free form write, and expand thoughts later by "leaving space" where need be.
I know that this desired feature has been discussed before, and I am not a developer, but is there something in the nature of drupal that would prevent an implementation of wiki style "accidental" node creation?
No taxonomy needed
Drupal does not require you to relate nodes to taxonomy items... You are free to store nodes standing alone... Therefore this kind of Wiki creation would not be hard to implement probably... The wiki.module needs to define a filter to convert wiki targetted links to node submission links or node view links depending on what is available...
optimizing performance
that filter might be pretty slow, no? it would have to query the node table for every wiki link in order to determine if the node exists already. this is done in order to decide whether to show the 'node/view' or 'node/add' link.
upon further thought, this decision could happen *after* clicking the link. just write an href like 'wiki/goto/my+title'. ah, thats much better.
node->format vs. filter
i'm glad someone (with an unbiased view apparently) starts shifting the focus in the big filter / various markups issue away from "filters" towards "node->format" / content-type. because i'm convinced that things like wiki, bbcode, textile, and restructured text markup cannot be solved with the current filter system and *need* another "node->format" / content-type
just a heads-up - gotta go now. more later.
Textile.module
textile.module does something similiar.
i think it would be a usefull addition to the filter.module base, to allow people to select which filter to run their content through.
I would ideally like this to be set on 3 different levels.
1) sitewide , all the nodes will be run through this
2) per user , the user can select in his profile page what filter to use
3) per node , override the previous 2 settings.
on daemon.co.za i usually use textilev2 , but sometimes v1 if it's a simple post..
but when i am pasting a load of data, i just use html and fix it up as i see fit.
filters need a lot of work.
Thank you everyone for the go
Thank you everyone for the good discussion. I have gotten caught up in work and have not had time to pursue this very much since I posted. I have cleaned up the code a little bit and tried to expand it to work with more modules but have run into a snag in the Blog module. While I have added a dropdown list to select the node->format, I can't find where the Blog module loads or saves its data (this was easy for Node and Book, however). If anyone could give me a hint it would be appreciated. TIA!
Can you post or submit the code?
I'm running a JSPWiki and Drupal for the same team, and I'd love to merge the two. But the current 'wiki' functionality has the weaknesses that have been discussed here. Anything that could move things ahead would be great! Can you post your cleaned up code?
- Laird Popkin