ext_7775 (
almostnever.livejournal.com) wrote in
otw_news2007-05-26 12:48 am
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png)
![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png)
Research Report: Drupal
I've put together an overview of Drupal features to help us consider its possible use for the archive project. If you have any experience with Drupal, or more information about it, please pipe up in the comments! That definitely includes any reservations that you may have. We're still in the fact-finding stage.
Overall: Drupal would give us several of the familiar features we enjoy on Livejournal, while also offering a content management system that's more conducive to organizing a fic archive, like sitewide categories, sitewide search, collaborative writing features that auto-generate their own navigation and table of contents, and author update tracking.
Drupal is open source and free, written in PHP. It's used by high-traffic sites like The Onion, Ain't It Cool News, and the Sugar Publishing Network. You can get more of an overview from its Wikipedia entry or visit Drupal.org for comprehensive information.
Italicized phrases are quotes from Drupal.org, followed by my explanation.
Users can register and authenticate locally or using an external authentication source like Jabber, Blogger, or LiveJournal.
This means that the site can be set up to allow comments (or perhaps even posts) from anyone who already has a Livejournal, without making them sign up for a new account on the archive site. Allowing LJ users to use their LJ accounts to comment on the archive site could make it easier for LJ-based fans to adopt use of the archive.
Drupal provides a powerful threaded comment model for enabling discussion on published content. Comments are hierarchical as in a newsgroup or forum.
Drupal's threaded comments support the same type of comment conversations that we're already familiar with from Livejournal. It's possible to set up a Drupal site so that all comment threads can be expanded with one button, rather than requiring viewers to click into each thread.
The comment module provides specific features to inform site members when new comments have been posted.
Comment notifications are another handy LJ-like feature, though the notifications may not work quite the same way.
Collaborative book feature lets you setup a project or "book" that needs to be written and then authorize other individuals to contribute content. At the bottom of book pages, Drupal automatically provides links for moving to the previous page and the next, and a link labeled up that leads to the level above in the structure. A contents page is also automatically created.
Taking advantage of this feature, the archive could host round robin projects, challenges, maybe even roleplaying games that tag back and forth between players.
Support for the Blogger and Metaweblog APIs means your Drupal site can be updated by many different tools. This includes non-web browser based tools that provide a richer editing environment.
I'm not sure yet whether users will be able to use Semagic with a Drupal archive, but Drupal does support the Metaweblog API, which Semagic uses. This is something we'll need to experiment with, but in theory users could post to a Drupal archive through Semagic just like they do to Livejournal.
The categories module lets you classify content into categories and subcategories, thus organizing the content on your site. For example, you could classify music by genre: classical, jazz, rock. And you might further classify "classical" into concertos, sonatas, symphonies, and so on. When your users create new content, you can let them classify it (or even require them to do so) right when they create it.
When users view a post to which a category has been assigned, along with the post your theme will generally show the name of the category (or categories) to which the post belongs. Each category's name appears as a link. And clicking on that link will bring users to a page showing the other posts of the same category.
I think the utility of that one is obvious for an archive site...
The tracker module displays the most recently added or updated content to the website allowing users to see the most recent contributions. The tracker module provides user level tracking for those who like to follow the contributions of particular authors.
This was one of the features on the wishlist. It's not quite as fine-grained as we might like (you can track only a single author, but not only a single story) but it comes close.
Drupal administrators don't have to tediously setup permissions for each user. Instead, they assign permissions to roles and then group like users into a role group.
In other words, we should be able to create an "author" role to grant author permissions automatically to anyone who signs up for an account.
One way to use this in conjunction with the Livejournal authentication feature might be to allow anyone with a Livejournal account to have commenting privileges, but only archive users who have signed up through the archive site to have an "author" role and the ability to post stories. That will allow easy adoption of the site to give feedback, while giving us more tools to moderate posters (to guard against spamming).
Drupal's theme system separates content from presentation allowing you to control the look and feel of your Drupal site. Templates are created from standard HTML and PHP coding meaning that you don't have to learn a proprietary templating language.
This is helpful from an administration perspective.
On sites with active commenting from users, the administrator can turn over comment moderation to the community.
While I'm not sure how this would work on a practical basis, it's something we might experiment with.
More built-in features:
Other features that are beyond the scope of the initial archive project, but which we might like to make use of later, include individual blogs for users, a built-in RSS feed aggregator and reader, and messageboard-style forum areas.
More options available by installing additional user-created modules.
Being open source, Drupal allows users to program additional functionality to extend the system. More features can be added to the core software by installing extra modules. The downside here is that some modules may not be as reliable as the core software: we should test any additional modules before using them.
There are modules to provide these features, among others:
Because the API for Drupal is open source and further programming is encouraged, we might be able to recruit fans who are familiar with PHP and MySQL to develop modules to add more features to the archive.
Now for the caveats. It's been a while since I personally worked with this system. I'm working on getting a demo installation up to try out the current version, and I hope to have it available for the technical decision makers to try out by the time we get to the decision-making point of the process.
Ideally, the project could recruit fans who are familiar with the system and/or PHP to assist with setting it up, and to help the administrators learn how to use it. Less ideally, administrators may need to get a book or two to help them learn how to run the system.
My experience is that Drupal is very powerful with a lot of features, but that this can represent a significant learning curve for administrators, and, to some degree, to users. I think that's going to be true of almost any software we use to manage a project like the archive, but Drupal might turn out to be cumbersome for a team of volunteers to administrate in their free time.
Another concern is that open source projects are sometimes lacking in documentation, and this also seems to be true of Drupal. That means that archive administrators may not always be able to find easy answers to problems in the help files & documentation.
Drupal has a very active community of experienced programmers and admins at Drupal.org, but using this community as a resource still means asking questions and waiting for answers if there's an issue that's not documented.
If at all possible, it would be best to have some archive volunteers with PHP knowledge available to help out; they'd be in a better position than a layperson to puzzle out problems if the documentation falls short.
I hope this information's helpful. If you have any info about Drupal, pro or con, please share it in the comments! The more we know about all the options available to us, the more likely that we'll be able to eventually make the best choice. I'll update the body of the post with any further information that comes up in the comments.
Thanks to
e_m_pink, who compiled this very helpful list of additional information!
Cons:
kerravonsen asked some great questions that should probably be considered for future research on potential software. Her questions in italics...
how easy is installation?
Drupal is comparable to most blog packages in its installation. I did it in a few hours, start to finish, no major problems.
how painful are upgrades to new versions?
e_m_pink says, not painful.
how easy is it to back up your data?
Again from
e_m_pink: fairly easy.
how much effort will ongoing maintenance be?
It's hard to be sure, but from what everyone has said so far both pro and con, it seems fair to say that Drupal will require significant effort to set up and maintain. I think if we chose Drupal, we'd want at least 6 volunteers who know the software, or are willing to learn it, to be available in case of problems.
how modular are the plugins? Do they require hacking the core code?
Very modular. I haven't seen anything yet that requires hacking the core.
how easy or difficult is it to create your own skin/template/look?
Fairly easy for people with good HTML and CSS skills.
how well-documented is the system?
Not very, unfortunately. There are holes in the documentation.
if something better comes along, how much effort will migration away from the system be?
This is a particularly good question. Drupal has lots of import/export modules but the most comprehensive import/export tool is still in beta. We wouldn't be locked into Drupal-- if nothing else, it provides RSS feeds for everything and those are suitable for importing into most other systems. But it might be a hassle, depending on how quickly that comprehensive import/export tool comes through beta.
Overall: Drupal would give us several of the familiar features we enjoy on Livejournal, while also offering a content management system that's more conducive to organizing a fic archive, like sitewide categories, sitewide search, collaborative writing features that auto-generate their own navigation and table of contents, and author update tracking.
Drupal is open source and free, written in PHP. It's used by high-traffic sites like The Onion, Ain't It Cool News, and the Sugar Publishing Network. You can get more of an overview from its Wikipedia entry or visit Drupal.org for comprehensive information.
Italicized phrases are quotes from Drupal.org, followed by my explanation.
Users can register and authenticate locally or using an external authentication source like Jabber, Blogger, or LiveJournal.
This means that the site can be set up to allow comments (or perhaps even posts) from anyone who already has a Livejournal, without making them sign up for a new account on the archive site. Allowing LJ users to use their LJ accounts to comment on the archive site could make it easier for LJ-based fans to adopt use of the archive.
Drupal provides a powerful threaded comment model for enabling discussion on published content. Comments are hierarchical as in a newsgroup or forum.
Drupal's threaded comments support the same type of comment conversations that we're already familiar with from Livejournal. It's possible to set up a Drupal site so that all comment threads can be expanded with one button, rather than requiring viewers to click into each thread.
The comment module provides specific features to inform site members when new comments have been posted.
Comment notifications are another handy LJ-like feature, though the notifications may not work quite the same way.
Collaborative book feature lets you setup a project or "book" that needs to be written and then authorize other individuals to contribute content. At the bottom of book pages, Drupal automatically provides links for moving to the previous page and the next, and a link labeled up that leads to the level above in the structure. A contents page is also automatically created.
Taking advantage of this feature, the archive could host round robin projects, challenges, maybe even roleplaying games that tag back and forth between players.
Support for the Blogger and Metaweblog APIs means your Drupal site can be updated by many different tools. This includes non-web browser based tools that provide a richer editing environment.
I'm not sure yet whether users will be able to use Semagic with a Drupal archive, but Drupal does support the Metaweblog API, which Semagic uses. This is something we'll need to experiment with, but in theory users could post to a Drupal archive through Semagic just like they do to Livejournal.
The categories module lets you classify content into categories and subcategories, thus organizing the content on your site. For example, you could classify music by genre: classical, jazz, rock. And you might further classify "classical" into concertos, sonatas, symphonies, and so on. When your users create new content, you can let them classify it (or even require them to do so) right when they create it.
When users view a post to which a category has been assigned, along with the post your theme will generally show the name of the category (or categories) to which the post belongs. Each category's name appears as a link. And clicking on that link will bring users to a page showing the other posts of the same category.
I think the utility of that one is obvious for an archive site...
The tracker module displays the most recently added or updated content to the website allowing users to see the most recent contributions. The tracker module provides user level tracking for those who like to follow the contributions of particular authors.
This was one of the features on the wishlist. It's not quite as fine-grained as we might like (you can track only a single author, but not only a single story) but it comes close.
Drupal administrators don't have to tediously setup permissions for each user. Instead, they assign permissions to roles and then group like users into a role group.
In other words, we should be able to create an "author" role to grant author permissions automatically to anyone who signs up for an account.
One way to use this in conjunction with the Livejournal authentication feature might be to allow anyone with a Livejournal account to have commenting privileges, but only archive users who have signed up through the archive site to have an "author" role and the ability to post stories. That will allow easy adoption of the site to give feedback, while giving us more tools to moderate posters (to guard against spamming).
Drupal's theme system separates content from presentation allowing you to control the look and feel of your Drupal site. Templates are created from standard HTML and PHP coding meaning that you don't have to learn a proprietary templating language.
This is helpful from an administration perspective.
On sites with active commenting from users, the administrator can turn over comment moderation to the community.
While I'm not sure how this would work on a practical basis, it's something we might experiment with.
More built-in features:
Other features that are beyond the scope of the initial archive project, but which we might like to make use of later, include individual blogs for users, a built-in RSS feed aggregator and reader, and messageboard-style forum areas.
More options available by installing additional user-created modules.
Being open source, Drupal allows users to program additional functionality to extend the system. More features can be added to the core software by installing extra modules. The downside here is that some modules may not be as reliable as the core software: we should test any additional modules before using them.
There are modules to provide these features, among others:
- Automatic Livejournal crossposting
- Userpics
- Access control based on categories: if users assign a post the category "members-only" that post could be visible only to site members, a post in the category "adult" might be visible only to 18+ users, etc.)
- Content blocker/killfile: users can choose to block certain users or categories from their view-- for example a slash-only fan could block all stories marked "het"
- "Abuse" flagging: users can flag problematic content for administrators to review
- Content embedding support: to allow vid-makers to make archive posts and embed vids hosted on YouTube, for example
- Donations module: allows donations to be taken and tracked, and/or Paypal integration module which allows donations and subscriptions to be taken and tracked
- Tag Mark: a module that potentially allows hosting of a social bookmarking system like del.icio.us
- del.icio.us stat tracking
- Content recommendation engine
- Amazon associate tools: ways to manage an Amazon affiliation; one way to let users support the archive is by providing affiliate links to buy from Amazon and kick back an affiliate fee to the archive
- Classified ad system: fandom classified ads! Probably noncommercial to avoid liability issues, but it could be a fun way to let people advertise offers for fic and art trades
- Copyright management module: could automatically add disclaimer information to every post
- Interests module: adds a LJ-like list of interests
- User-created groups with their own community pages
- MANY anti-spam measures!
Because the API for Drupal is open source and further programming is encouraged, we might be able to recruit fans who are familiar with PHP and MySQL to develop modules to add more features to the archive.
Now for the caveats. It's been a while since I personally worked with this system. I'm working on getting a demo installation up to try out the current version, and I hope to have it available for the technical decision makers to try out by the time we get to the decision-making point of the process.
Ideally, the project could recruit fans who are familiar with the system and/or PHP to assist with setting it up, and to help the administrators learn how to use it. Less ideally, administrators may need to get a book or two to help them learn how to run the system.
My experience is that Drupal is very powerful with a lot of features, but that this can represent a significant learning curve for administrators, and, to some degree, to users. I think that's going to be true of almost any software we use to manage a project like the archive, but Drupal might turn out to be cumbersome for a team of volunteers to administrate in their free time.
Another concern is that open source projects are sometimes lacking in documentation, and this also seems to be true of Drupal. That means that archive administrators may not always be able to find easy answers to problems in the help files & documentation.
Drupal has a very active community of experienced programmers and admins at Drupal.org, but using this community as a resource still means asking questions and waiting for answers if there's an issue that's not documented.
If at all possible, it would be best to have some archive volunteers with PHP knowledge available to help out; they'd be in a better position than a layperson to puzzle out problems if the documentation falls short.
I hope this information's helpful. If you have any info about Drupal, pro or con, please share it in the comments! The more we know about all the options available to us, the more likely that we'll be able to eventually make the best choice. I'll update the body of the post with any further information that comes up in the comments.
Thanks to
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
- A lot of useful features are integrated from the ground up, such as RSS (which heidi8 mentioned), comment threading and user management tools. Most of these features are fairly easy to configure for basic use, so they could be set up fairly quickly.
- A great, supportive community that's actively developing and improving the system. Asking for help is fairly easy, and so is reporting bugs and problems with modules and themes. It's not perfect, but it does work.
- Scalability is taken into consideration. There's a built in throttling function for high traffic situations, and you can improve or change that to your heart'scontent.
- It is fairly easy to develop for - the API is really well documented, and since you can modify other's modules and themes as you like, it is easy to steal borrow code from other people and build on their success.
- I think you can also save drafts and so on while creating a post or a page with Drupal, which means you can probably use it as a writing tool instead of stuff like MS Word and so on.
- Backing up your installation isn't too hard to do even without the modules that streamline it. You basically back up the actual folders on the webserver AND back up the database or databases that the installation uses. Upgrading Drupal is something I've never done, but it usually involves a similar sort of process as many other CMSes do- you switch off the modules you added, back up your database and general installation, and run an upgrade script.
Cons:
- Sometimes, the documentation for Drupal is just not as complete or effective as it should be.
- The amount of modules and themes and add-ons available for Drupal necessarily means that they duplicate each other's functions or conflict with each other in strange ways. There is a lot under the hood in Drupal from the get-go, and modding it means that it can break in unpredictable ways.
- It can be really frustrating trying to modify or fix parts of Drupal to your desires if you don't have some CSS, PHP or HTML experience. Setting up cron jobs alone nearly broke me when I realised my current website provider wouldn't allow me to do it the way defined by the Drupal manual. Experienced PHP/HTML/CSS programmers will be a must, just to cut back on frustration caused by cluelessness about those languages.
- Their taxonomy feature is both wonderful and terrible. Configuring that to work like the mishmash of del.icio.us and LJ will take some serious thinking and planning, especially if the archive won't just use a tag soup of some sort. Some underlying structure is needed, and it can be confusing to marry that with everything else. The modules provided to help that process along are not the most user-friendly around, so it adds to the frustration.
- Jesus christ, the submission forms! If you want people to be able to tag and categorise stuff as it is posted, you have two choices: go with the fairly ugly Drupal way of categorising things, or try to put your own together. This was another of the things that finally drove me away from Drupal, as I believe submission forms should be as user-friendly as possible, and it was just so difficult for me to get incremental improvements to show up. Getting to that would take some time.
- The last issue that comes to mind (I'd call it a con, but it's so much more than that) so flummoxed me that it deserves its own paragraph. Namely, it is how to handle posting of stories.
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
how easy is installation?
Drupal is comparable to most blog packages in its installation. I did it in a few hours, start to finish, no major problems.
how painful are upgrades to new versions?
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
how easy is it to back up your data?
Again from
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
how much effort will ongoing maintenance be?
It's hard to be sure, but from what everyone has said so far both pro and con, it seems fair to say that Drupal will require significant effort to set up and maintain. I think if we chose Drupal, we'd want at least 6 volunteers who know the software, or are willing to learn it, to be available in case of problems.
how modular are the plugins? Do they require hacking the core code?
Very modular. I haven't seen anything yet that requires hacking the core.
how easy or difficult is it to create your own skin/template/look?
Fairly easy for people with good HTML and CSS skills.
how well-documented is the system?
Not very, unfortunately. There are holes in the documentation.
if something better comes along, how much effort will migration away from the system be?
This is a particularly good question. Drupal has lots of import/export modules but the most comprehensive import/export tool is still in beta. We wouldn't be locked into Drupal-- if nothing else, it provides RSS feeds for everything and those are suitable for importing into most other systems. But it might be a hassle, depending on how quickly that comprehensive import/export tool comes through beta.
no subject
Mind you, Drupal does have a very impressive set of features.
no subject
There should be several more reports like it appearing on the community soon as we do more research on what's out there.
no subject
BTW, who is that in your icon?
no subject
no subject