Research Report: Drupal

[almostnever.livejournal.com]

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:

• 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 e_m_pink, who compiled this very helpful list of additional information!

• 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.

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.

Comments

[heidi8.livejournal.com]

Speaking as a fic-archive admin, I'd like to suggest that having RSS from the start, by author or by fic-title-for-additional-chapters, or even genre/ship/fandom, is incredibly important. It took a lot of retrofitting before we had it on fictionalley and it's such a useful thing for readers.

[kerravonsen]

Here some more questions to ask of any potential system:
- if something better comes along, how much effort will migration away from the system be?
- how easy is installation?
- how painful are upgrades to new versions?
- how easy is it to back up your data?
- how much effort will ongoing maintenance be?
- how modular are the plugins? Do they require hacking the core code?
- how easy or difficult is it to create your own skin/template/look?
- how well-documented is the system?
- is there a community (mailing list/forum etc) associated with this system? How helpful are they?

[franzeska]

- is there a community (mailing list/forum etc) associated with this system? How helpful are they?


The Drupal website has a page with links to their forums and various mailing lists. I haven't seen much not on their site, but the discussions there look quite informative.

[almostnever.livejournal.com]

Those are great questions, I hope anyone else who does a research report like this will take them into account.

how easy is installation?

Drupal is comparable to most blog packages in its installation. I did it in a few hours, 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 (http://drupal.org/project/Modules/category/64) 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.

[dorrie6.livejournal.com]

i had a bad experience trying to use Drupal on a website of my own, including clunky interface issues (behind the scenes), some modules that just plain didn't work, and rampant comment and trackback spam that there seemed to be no way to control. Keeping in mind that this was at least a year ago, and it is possible that more recent versions have corrected these issues, from my own experience I could not recommend it.

[sasha-davidovna.livejournal.com]

I've fiddled around with Drupal a bit, considering it as a way to make updating my personal site easier. So far, I've been too lazy to actually do it, but I've been impressed with it so far. The learning curve was a bit steep for me, but I'm not a programmer (beyond HTML/CSS) and others might find it more intuitive.Based on my experience with the Sugar sites, I do not think that it would be any more difficult than LJ to learn for users, and probably easier than ff.net's annoying upload system.

I also like the idea of individual users being able to have personal blogs - seems like a good way to make it a living community rather than just an archive in its purest form. It's also apparently pretty easy to set up a digg-like system using Drupal, if we were interested in such a thing (I've seen it discussed) and the Sugar sites have a Bookmark feature similar to that used by ThisNext which is one possible way for people to keep rec lists.

[anatsuno.livejournal.com]

Question from an ignoramus, what is ThisNext?

[quivo.livejournal.com]

I've been fiddling on and off with Drupal for the last year or so, so I do have a fairly big basket of pros and cons to share.

Pros:

• 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.

Now, for the 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.

(Continued in next comment)

Sequel to previous comment, in which I rant a bit about posting formats

[quivo.livejournal.com]

(Continued from previous comment) 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. Shall we let people post using HTML, or try to help by providing support for other languages like Textile or Markdown? How will we allow for migrating stories from FF.net and other archives, and how will we allow for people who want to copy and paste from Word and rtf and openoffice documents? The truth is, reformatting stories is hard work, and converters that don't mangle your story's appearance can be hard to come by. This is one of the main reasons why I still post to fanfiction.net: almost all my writing tools (MS Word, OpenOffice Writer and Scrivener) have had the ability to export in .rtf, which keeps everything displaying just how I want it without muddying the waters with bad HTML and XHTML. Reformatting stories is not how I want to spend my time, and goes from feasible (with drabbles and stuff under 2000 words) to absolutely maddening (seriously, imagine reformatting a 100,000 word story by hand- which I might end up doing because most programs do such irritating things to files during HTML conversion). And writing in html or other markup languages is out of the question, since I like to see how my stuff looks as I'm writing it.

Now, Drupal provides some answers with modules that allow for Textile, Markdown and even wiki format to be used in posts, but I wasn't able to find an rtf converter of any sort that I could plug in to Drupal. Also part of the issue is that Drupal doesn't come with a WYSIWYG posting format; you have to intergrate TinyMCE or one of the other posting interfaces. I haven't tested those interfaces so far, so don't have an opinion to offer on them, but I will say that there is a reason people use writing programs, and accommodating the output of such programs will definitely be an issue.

Apologies for the tl;dr if stuff I've said has previously been mentioned, and sorry if I sound like I'm ranting or being negative. Drupal is a great tool, make no mistake, but it takes some getting used to.

PS: If Drupal books are needed/desired, I'd be happy to send the one I have (the one by David Mercer), since I've pretty much wrung the use out of it myself.

Re: Sequel to previous comment, in which I rant a bit about posting formats

[almostnever.livejournal.com]

Wow, thank you for sharing the benefit of your experience. I've added your bullet points to the body of the post.

I've also noticed your comments over at Henry Jenkins' blog and appreciated what you had to say. It's great to see you participating in both these discussions.

Re: Sequel to previous comment, in which I rant a bit about posting formats

[kerravonsen]

how to handle posting of stories

Very good point.

Would it sidestep the issue if people would be allowed to "attach" story files in their preferred formats? The posting interface would allow one to upload the file, and when uploaded, the system would just display a link to the file, rather than integrating the story into the CMS itself.

Pros:
- no battling with conversions or reformatting
- story displays exactly how I want it
- simple click-and-upload
- there wouldn't be any irritating navigation stuff in the story file, readers could just have the pure story

Cons:
- what file formats would be allowed? From a readers point of view, they don't want to be battling with document formats that they can't read. Personally I would want it to be restricted to text and HTML, with perhaps PDF also.
- there wouldn't be any handy navigation stuff in the story file -- mind you, that's the case for text-only archives (where the stories are all required to be in plain text format) and people don't seem to mind.
- people would upload bad HTML

[jetpack-monkey.livejournal.com]

I'm a Drupal geek if you need any assistance. I'm about to relaunch my horror film website using Drupal and I maintain my own personal fanfic on a Drupal site (http://www.monkeyswithjetpacks.com).

The only thing you're going to run into with Drupal is that it is so wide open for so many different uses that there's a tricky learning curve to it.

[projectcyborg.livejournal.com]

I run my personal sites on drupal, and I LOVE it. but speaking from experience, having a Drupal developer on "staff" would be crucial. precisely because it's so flexible and modular and open source, I've found it necessary to do constant hacking to get all the various components to play nice. and updating, while supposedly a breeze, is a total nightmare when you get third-party modules involved (half the time the ones you need aren't updated, or their updates don't work).

so while I think Drupal is an excellent general CMS, I'm not sure about the logic of using it to run a fiction archive -- as opposed to one of the several existing archive-specific CMSs like media cow (http://media-cow.net).

[ladyjestyr.livejournal.com]

I've just had a bad experience with Drupal - have had a site hacked twice in a month. I don't know if this was due to holes in Drupal's security or what, because to be honest that was the last straw for me to switch back to Wordpress (as the site in question didn't require a complex CMS).

[kerravonsen]

Would it be worth the effort of investigating other tools besides Drupal? I'm just wondering if it's a bit premature to say "Drupal yes/no?" without knowing what else is out there.

Mind you, Drupal does have a very impressive set of features.

[almostnever.livejournal.com]

We're definitely investigating other tools. This is just a preliminary report to get an idea of the strengths and weaknesses of this package.

There should be several more reports like it appearing on the community soon as we do more research on what's out there.

[filenotch.livejournal.com]

So, um Drupal owes a lot to Scoop (http://en.wikipedia.org/wiki/Scoop_(software)) and SLASH (). IIRC, Scoop was built off slashcode, and Drupal off Scoop. FYI, the most famous site using Scoop is probably DKos (http://www.dailykos.com/).

The three systems do share a need for a real programmer to customize and maintain.

[filenotch.livejournal.com]

link should be Slash (http://en.wikipedia.org/wiki/Slash_%28weblog_system%29), and yes I like the idea of a fanfic archive run on slashcode.

[msilverstar]

The one thing I worry about is scale -- while Drupal theoretically scales up, I think it's important to talk to people who have really big amounts of data and enough traffic to overflow a single server. Also an automatic failover system would reduce the stress on the admins considerably.

[kerravonsen]

It might be worth talking to the Gossamer archive folks, since they seem to have their load split between multiple servers.

[melodyclark.livejournal.com]

I read through quickly to see if this had been mentioned and I didn't see it, so forgive me if it has already been covered and I didn't see it.

If you go with a CPanel host, you can ask for something called Fantastico that will allow you to auto-create Drupal sites. Admin from there is fairly easy. Fantastico also usually has a number of other CMS programs (a couple of which I personally like better than Drupal, but all things are subjective).

You might open a cheap hosting account (Hostgator.com is good and has a cpanel offer with Fantastico) and play with the various CMS available.

[almostnever.livejournal.com]

I didn't know about Fantastico, that's very helpful, thank you!

a couple of which I personally like better than Drupal

I'd love to know which CMSes you like better. The archive is a long way from making a decision about this, and more suggestions for appropriate software to investigate would be great.

[elements.livejournal.com]

One issue with Drupal plugins is that not all plugins are available for every version. It's up to the creator of each plugin to upgrade to compatibility with the new Drupal core version. If you want to upgrade your core, and depend on a plugin that has not upgraded yet, your options are a) convince someone to upgrade it; b) pay someone to upgrade it; c) upgrade it yourself.

I know someone building a new site in Drupal who is having to code a lot of a plugin upgrade independently. It's taking a lot of hours.

I think Drupal may still be the best bet, but that's just another caveat. If the project were to be built on Drupal, I think we'd need a few admins to commit to spending significant amounts of time learning the system.

[margot-iris.livejournal.com]

hello- Drupal's great, no arguing there, but have you all had a look at Textpattern (http://www.textpattern.com)? I've used it to build a fanfic archive (http://www.faramirfiction.com) before.

[damned-colonial.livejournal.com]

Just wanted to let you know that though I'm a little late to the party, I've read this post avidly and thumbtacked it and would like to talk more about Drupal and the like.

One point you touched on very lightly is that Drupal is open source. I am pretty strongly of the opinion that whatever we go with, it needs to be open source. Not just the thing we base our site on, but any modifications/customisations we make. We should be considering how to package the whole thing up for download so that people can grab it, play with it, improve it, contribute patches, or run their own archives on the same software. I've posted some more on that subject in my own LJ (here (http://damned-colonial.livejournal.com/414885.html)) if you're interested.

[pitartist.livejournal.com]

Hope it's ok to join the conversation. I think a fanfic archive is an awesome idea, and Drupal is the best software to do it. But there are a few things I wish I'd heard before starting an archival site with Drupal:

*Taxonomy: I chose Drupal over other open-source CMS softwares because of the taxonomy feature, and specifically because the taxonomy could be structured in hierarchies, so that relationships could be created among the content. One problem with this is that there is no good way to display the taxonomy hierarchies without the *category module* - BUT it's best to install that and go with it on the front end. Once you've created your taxonomies, you don't want to have to go back and re-do them all in the category module (that will make you mental).

*Installation: If you go with the Fantastico installation of Drupal, there are some things that aren't part of that package which are crucial - like the update.php file, which you have to run when you update a module. It's much better to download Drupal from drupal.org than to figure out what's missing and install it later.

*Management: You should be clear on the front end whether you anticipate having a lot of user-generated content. A lot of people seem intimidated or put off by the Drupal interface, and they end up emailing content to an admin instead of uploading it themselves. Also, to have everything consistently tagged (and avoid the "tag soup" that someone mentioned), everything will need to be reviewed by the same person or people who understand your specific taxonomy/tagging system. This is fine but A LOT of work for admins. Remember too that if you just link to text rather posting an entire story, the content won't be searchable, which I think is a huge downside.

*Browser issues: In my experience, Drupal doesn't work nearly as well with Internet Explorer as it does with Firefox. The layout looks funky on IE, and I haven't been able to fix it, even by changing the theme.

*Aesthetics: Drupal themes (premade site layouts) are not sexy. Some are ok, but there isn't nearly the number of cool themes one would think. Also, the Drupal forum leaves a lot to be desired. There are modules to integrate with vBulletin or phpBB but these just provide common logins - the content will not be integrated.

*I agree with many who have commented that Drupal IS buggy and many modules are more than a little challenging to get working. But I still think it provides by far the best open source solution for an archival project. I don't think it requires a Drupal developer, just some few folks with a LOT of time and dedication.

[calic0cat.livejournal.com]

I haven't slogged through all of the comments here; however, having worked with both Drupal and the current 3.3 release of eFiction (http://www.efiction.org), I've gotta say that a fiction and art archive, Drupal ain't. Not by a long shot.

Frankly, I'd say that the best bet if you wanted to use Drupal overall would be to bridge the two or to take the current eFiction release and customize it for integration as a Drupal module. eFiction *already* supports round robins, for example. It supports admin-defined classifications, whether they be genre or pairing or whatever. It has some RSS support already and more specific feeds could certainly be added. It uses the Smarty Template system, which *can* also be used by Drupal, at least in theory (I haven't tried this myself). eFiction's image support is not great but I commissioned a Coppermine Gallery bridge a while back and the two can be integrated pretty darn well, thus drastically improving overall capability.

Drupal's image galleries suck. Big time. The Acidfree Album module is currently the nicest and simplest option that I've found for using images in Drupal but it's far from perfect. If you're going to archive fanart, you need something more like Coppermine. Once again, you could bridge the two or write a module to integrate Coppermine into Drupal, but I really don't think that any existing Drupal modules are up to the task.

I've also been told that Drupal's built-in forums aren't very powerful for large sites. They're fine for the site that I'm running in RL since it's a small non-profit club that probably will never have more than a handful of active topics and a dozen or so forums at most, but they're apparently not that great for a truly large site with many forums and active threads.

In addition to eFiction bridged with Coppermine, another option for the archive side of things would be Fabulister (http://www.fabulister.com), the script powering Lexicon (http://www.transformersfanfic.com), the massive Transformers fanfic and fanart archive. The script was commissioned by Charlotte Brogden, the archive's maintainer, specifically for fanfic and fan art. It's GPL but I'm not sure if the source code has ever actually been publicly posted, though I'm sure that Charl would be happy to make it available to this project.

Even if you're not interested in Fabulister, you may want to take a gander at the original 13-page feature list (http://www.fabulister.com/index.php?cat=11) that it was designed and built from. That may be of use in determining features for the new archive.

I'm not saying that Drupal shouldn't be part of the picture - but I don't think that it's the whole picture. It may make a good frame for the site as a whole, but I really don't think that it's a good choice for the fic and art archive and I can't see the point of designing a new module from scratch for that purpose. Why re-invent the wheel when there's several perfectly good wheels out there that can be modded to fit the need?

One other sidenote: regardless of the backend software used, you'll probably want to look into some sort of import script to pull in fic from existing archives such as the various eFiction and Automated Archive versions. Generally speaking, when people get out of the fan archive hobby, they don't have the time and/or interest to manually transfer the whole thing to a new system; you're going to need a quick-and-easy method to pull the stories and art over or it's not going to happen.

[calic0cat.livejournal.com]

Almost forgot: if you want to see an eFiction 3.3/Coppermine 1.4.12 bridged site (albeit a rather small one), you can check my site (http://www.calic0cat.net). If someone from the project wants to play around with the admin or author end of things, drop me a note and I'll change settings and provide access to a test site that I keep for experimenting purposes.

Netflix Takes Center Stage on Xbox

[(Anonymous)]

Microsoft made a splash at the E3 Media & Business Summit with its announcement of a partnership with Netflix that permits users to watch movies and TV shows using an Xbox 360 console.

Drupal Development

[inforlinx solutions (from livejournal.com)]

Thank you for sharing this post about the best techniques for Drupal Development, This is very useful for Drupal Development and Drupal Development. Thanks again :) Drupal Development (http://www.inforlinx.com)

pozycjonowanie stron Łódź

[(Anonymous)]

I believe, that you are not right. [url=http://urbisoft.com.pl]pozycjonowanie stron Łodz[/url]