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 cel4145 on
On May 13, Movable
Type announced that with version 3.0 they would be "Getting Their Pricing
Right." The new licensing scheme--which only makes MT available for free
for 1 author and up to 3 websites--is, as Mark
Pilgrim has pointed out, a demonstration that "free enough" does
not guarantee any freedoms in the long term. And so many current MT users are
now searching for copyleft and/or open source blogging software alternatives.
Anyone following the many trackback links from MT's announcement will notice
that WordPress is the most popular GPL'd alternative considered by most MT bloggers.
Drupal gets plenty of mention, but often in the context of being described as
too difficult to install or a too feature heavy system for basic bloggers. Indeed,
for many individual users who keep one blogsite and are happy enough with the
features they have now, WP may be the best choice.
But also within those conversation threads across the blogosphere is a common
critique: MT's 3.0 release is feature light, with comment spam control being
the only new addition. Many MT users had looked forward to increased capabilities
in MT 3.0, only to find increased price. Many MT plugin developers now feel
that MT development is first about making money and community second.
For those people wanting more, Drupal has a lot to offer than might be seen
at first glance. It's not without reason that Drupal has the nickname of "community
plumbing" and is often described as innovative and unique. Take a careful
look at the standard Drupal features
and contributed modules ('plugins'
in MT parlance), understand where Drupal will be by the 4.5 release in just
a few months, project the feature rich environment that could be within the
next year, and realize that Drupal will continue to grow in new and interesting
ways, making it one of the best choices for those interested in blogging as
social software.
For example, consider the following items which should address concerns of
some potential MT to Drupal converts:
- Distributed Authentication. While MT has implemented their TypeKey
centralized registration system as a solution to the comment spam issue,
each Drupal site not only has onsite registration and comment moderation,
but also has a distributed authentication system with drupal.module. Any user
registered on Drupal site X which has drupal.module enabled, can login to
any other Drupal site Y using drupal.module with their username and password.
For example, a registered member "user" at drupal.org can login
in elsewhere with username "user@drupal.org." Someone with the username
"user" at mysite.com can log onto drupal.org with "user@mysite.com."
Drupal.module can also ping drupal.org via XML-RPC; to see many sites that
support Drupal distributed login, visit Sites
that use Drupal.Privacy and dependency issues of centralized authentication aside--and let's
not forget price since TypeKey, too, could one day be a paid service-- distributed
authentication represents Drupal's commitment toward increased social networking
and social software capabilities as also evidenced by discussions
of implementing FOAF, peopleaggregator's
adoption of Drupal as their primary platform, Deanspace,
and Dries's recent modifications
to the profile module on drupal.org. - MT-to-Drupal conversion. The MT licensing scheme announcement immediately
stimulated discussion on the drupal-devel list, resulting in an initiative
to create a better, more user-friendly method of converting MT sites over
to Drupal. While the Template for
MT entry and comment export and Drupal import can easily do the job for
those that are a little tech savvy, the drupal developers have committed to
both- Improving the import/export script, addressing the issue of importing
MT comments (the current script imports them as anonymous). - Combining the best of the import.module in contrib with the current
aggregator module to easily enable RSS import of MT blogs, much as WP
does MT conversions, as well as importing any other website running RSS.
- Improving the import/export script, addressing the issue of importing
- Install Wizard and Site Profiles. One of the most common complaints
about Drupal is that it's difficult to install and setup for a given site
configuration. The Install Wizard to be included in Drupal 4.5 (screenshot),
will make easy the installation of one or many Drupal sites. Furthermore,
after completing the installation, the wizard will allow the user to select
from among preconfigured site installations such as individual weblogs, community
weblogs, or discussion board communities, significantly reducing the amount
of time necessary to get a Drupal site up and running. - Drupal for (MT) Bloggers. James Seng, a long time MT user,
has recently started a Drupal
for Bloggers project. His goal is to make Drupal more MT like. Four
releases, all over the last week, have already made Drupal even more blogger
friendly. Like the influence that Deanspace has had on Drupal development,
many of these changes could eventually make it into the Drupal core or
a Drupal Install Wizard profile. - MT-Style Comments. Personally, I prefer the standard Drupal commenting
system which supports threaded comments. But Drupal site administrators will
now have a wider range of choice in commenting styles. MT bloggers will appreciate
the new enhancements to Drupal comments which implements simple
and anonymous comments.
So before making a decision about which blog software to use, learn more about
Drupal. Realize that it's much more that WP and MT, and an alternative worth
serious consideration. And the price of the licensing scheme will always be
right.
Comments
MT v. WP v. Drupal
One of the major complaint about the new MovableType licensing is that scaling is very expensive. Many current MovableTyle power-users use MT for multiple blogs, multi-author blogs, multiple blogs accross several domain names, you get the point. They use it in a many-and-many deployment. Single user non-commercial blogging is still free using MovableType. How does Drupal make these people feel at home?
Drupal has native multi-author-blogging support. Drupal also supports multiple blogs, either via usernames, or via taxonomy/category terms. Multiple blogs accross multiple domains using one single Drupal installation isn't as easy, yet. It definitely isn't for the non-technical users. In a many-and-many deployment Drupal is clearly ahead of WordPress and TextPattern. Many experiences WP and TP users pointed out to the MT refugees that neither WP nor TP supports multiple blogs from a single installation, yet, as MT does.
Drupal's installation in real world isn't rocket science. But many MT users do not have shell access in their shared hosting and the install.txt that comes with Drupal only says how to install Drupal via shell commands. I think instructions for installing Drupal with PhpMyAdmin should also be included. Pointing out a native installer shipping with Drupal 4.5 is a bit disingenuous. Who knows when Drupal 4.5 will ship when a MT refugee needs a new CMS today?
From a users perspective, I like Drupal's simplistic content posting form, one reason I have been a long time Drupal user. But many MT users are used to the posting form with buttons for bold, italics, blockquote, and others nicities. WP has them too. Drupal's htmlarea module works well, but is still, I think, a bit over-kill, and a user-installed module. I have read many reviews comparing the UI of WordPress and Movable Type and seen how people repeatedly say how similar the two posting interfaces are. Comfortability and familiarity is one big selling point when moving from one CMS to another.
One major short coming of Drupal is that the user-support community. Both MT and WP has an extensive support group. People can post here a support request and it might go un-answered for days or weeks.
I think one has to address the usage of MT when appealing to the MT refugees. Drupal does many things MT does now, and then some. Drupal has native photo album feature via the contributed image.module. It also has a wiki.module. Its breadcrumbs are much better than the bi-directional ones on MT. I don't think people decide CMS on licensing alone, but on ease of usablity and extensibility. If licensing was all the rage everyone would be using slash-code or the *nukes for everything.
Drupal isn't really consider yet...
Good points :-)
IMO, the most important thing for Drupal to be use (not just been considered) for bloggers is to make it easier to use.
Installation of drupal is "easy" enough (altho compared to MT, still a long way to go). The difficulty kicks in *after* installation. Drupal 4.4 provides a nice front page guide but to then _customize_ drupal for whatever they need, that is pure hell.
You want comments..hows the hell the moderation matrix works (imaging yourself a newbie)? Not everyone is planning a slashdot and few even have moderator for their site.
Or how about taxonomy? The only time I use the term is when I dealing with W3C and Semantic web folks. Your ave joe wont know what it means nor understand how it you have to "attach to node" to use it. As I found this gem in taxonomy.module: "// relations: (seem very powerful, but I have to understand it completely)". Lets see..a feature so powerful that it even confuse the drupal maintainer!
Now, move to plugins. Sure a wide range of plugins available. Installation isnt tough, but the problem is: which plugin module? There are 2 for trackback and at least 4 for files uploads related ones. For the latter, none really provides the basic simple file upload feature!
Before anyone thinks I am whinning, I am not. I really like drupal and I hope to see more people using it. But in a mass exodus of MT users but Drupal wasn't a destination, we should really ask ourselves "why not?".
We all love powerful features. But comes with the powerful features, you lose the crowd because few understands it. The reason Windows wins over Unix is not because it is more powerful (haha!): it is because it is dumber, hiding a lot of complexity from its users.
Drupal has a potential to be an Apple: powerful yet also simple to use. We just need to make a conscience effort to think more like a layman and less like a hacker.
customizing drupal...is pure hell
ahhh....but i think there's an easy solution to the customization process. we all know that the reason that drupal is difficult to customize is that it's like a block of clay--has to be molded for the particular site configuration. while the profile system will take care of that for 4.5 assuming that someone contributes profiles (and i don't agree with the comment above yours--it is not disingenuous to refer to 4.5 when drupal very frequently releases), an easy solution is a distribution which configures the site and provides documentation. i'm doing that now for an educational version intended for the college writing classroom. the demo, in progress, is live at drupaled.cyberdash.net.
someone could do the same for bloggers. see, i'm not convinced that the only solution is merely to hack drupal, change it, so that it's MT like as much as possible. rather, reduce configuration time by providing the starting db and necessary modules, then provide documentation to assist in final site configuration; in other words, worry less about making drupal into something else and more about providing the necessary documentation to make the transition easy to drupalized blogging.
now, there are plenty of experienced drupal users that could the same as i'm doing and develop a site for bloggers. my coding skills are minimal. one doesn't have to be a developer to do this, merely be familiar with the configuration and willing to write some instructions to help someone along the steepest part of the learning curve.
for example, your point about taxonomy. easy enough just to create one, with some sample categories/terms, and provide a few instructions on how to change the existing terms or add new ones. most bloggers won't need more than one vocabulary to start off. and once they see it in action, it's no great leap to think about how to add another if they so desire. an example goes a long ways.
profile?
I do not disagree that having profile will make life easier but that to me isn't good enough. But drupal is still far more complex beast then what is needed. If you look at the technology curve, I would say Drupal is too far out for most people. The solution isn't "here is the setup I think you need" but *also* giving them a "cray which easier to mold" (using your anology). To do so, programmers need to remind themselves constantly "does most people need this? how can i make them less confusing?"
btw, I am not trying to make Drupal like MT. I am trying to make Drupal "good enough" (aka easy enough) to be used by common bloggers. It is a small but important difference that I hope people dont get confuse. The result of "Drupal for bloggers" will still be Drupal (albeit easier to use) first and foremost, not a MT-clone or wannabe.
but it's not confusing to use
i'll disagree. i've been running a community weblog site now for close to 2 1/2 years, over one year with drupal. and i've taught 3 college classes with drupal, and worked with 2 other people who have taught 7 or 8, and we've had no problem at all getting college students, most of them freshmen, comfortable with using drupal. in fact, it's been easier than teaching them to use blogger and blackboard. most settle in by the end of the second week of class. and students are one of the most hostile audience's for teaching to use an app like this because most of them are only using it because they have to take the class. so drupal is just not that hard to use from an end-users perspective who is not doing any configuration.
and the two other people i've worked with? the teachers who used the sites and would have been responsible for administration? ask them how easy it is when someone sets up the site for you. i provided some direct support to them to help them along the way, support that can in many ways be covered by documentation.
meanwhile, i know of another drupal user, using cms's and blogs for over 2 years, drupal for over a year, who recently tried MT. she was extremely frustrated by MT's administration section. why? because drupal, postnuke and blogger was what she knew. so one of the main problems is that drupal doesn't work quite the same. not worse. just different. and when a user has pre-existing digital literacies, they expect things to be familiar; otherwise the experience can be jarring.
then my experience, a while back, trying out cms's for the first time. i installed drupal a year earlier before i began using it. got it installed. what does it do? nothing. nothing is configured. so i moved to something else. it was only later than when i came back to it after postnuke began to fall apart when the xaraya crew left, that i found out how flexible and easy it was to use once it was configured. see, i had gained the experience necessary to figure out how to configure it effectively myself, experience that would have been unnecessary with a base site configuration close to what i wanted with some documentation on some simple configuration changes. and by the way, when we switched over our postnuke users on the community site to drupal, they had no problems at all.
so certainly, drupal has places it could be improved. but it's always being improved (the changes from 4.0 to 4.4 have been significant). and it certainly could use some extra blogging features to make it a more robust blogging platform. but i don't just buy that it's a lot more difficult to learn--if preconfigured with documentation--than most users' experiences would have been with learning to use MT for the first time. i've seen enough evidence in observing and helping other people to use drupal to suggest that this is not true. and i'll go with usability evidence through direct user experience every time over feature comparisons and other analysis.
easy to use?
I have been adovcating its use internally within Singapore government and we have 5 sites for a variety of purpose since last year. (sorry, no public URL).
The consistent feedback from all the users is that once it is setup, it is beautiful..the problem is configuring it to do what they want. Using drupal is *never* a problem...customizing it is.
"Fine. Lets pay someone to customize it!". I thought. The few local vendors look at it and decide to give it a pass. The themer we engage gave up after a week meddling with the drupal themes.
End up my team have to do the customization for them. Luckily it is for internal stuff so we can made do with the hacks we do.
I am not sure what class you teach in college but I deal with IT managers, CIOs and "vendor programmers" (not the uber-hacker type) and these are their feedbacks. I wish I could do more with drupal but until it is easier to use, it wont go anywhere here. YMMV of cos.
Usability
My view is that Drupal is (1) easy enough to install, (2) difficult to configure, but once configured, (3) fairly easy to be used. All these items - (1), (2) and (3) - need work but we should focus on (2) as that is were people are bailing out. The learning curve is dominated by (2).
We've made a lot of progress usability-wise but have a long way to go. Talk is silver, patches are gold.
a variety of purposes
certainly. different user bases with different configuration needs.
but i believe the average blogger is likely to have different needs than IT managers, CIO's and vendor programmers. blogging is a little different. given a base configuration setup, there is a limited number of configuration changes that the average blogger is going to want make (theme development aside).
'nuff said. i guess the proof in concept needs to be demonstrated (more later).
Proof of concept: Drupal preconfigured for Blogs
Okay. I put my money where my mouth is :) The DrupalBlog distribution demo. Stock Drupal and contributed modules, no hacks (well, one to a CVS file), with configuration documentation targeted at bloggers. Will make it available for download sometime next week after a little more tweaking. More information here.
hmmm
I don't know that a customized download is needed. Just a well writen start from a base Drupal install. As long as the docs are clear, then the developers maintain one core download and it still remains a lump of clay.
Aslo suggestion. Instead of 'you may want to create an About link'
Show the steps to write an About page and create the menu link.
Create content / Story
Enter content here
Create link like this.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
re: hmm
I don't know. I think a lot of people like MT and WP because it's a blog out of the box. Ever buy something with extensive assembly instructions and wish you didn't have to spend a few hours putting it together? Besides, pre-configurations will be easy to accomplish with the Install Wizard and Site Profile system (Adrian gave me a tour of it a few weeks ago and it looks great).
Meanwhile, thanks for the suggestion. At some stage, I do want to take the guide to the next level and add more instructions in like that. Sort of the next tier of little things a user might want to have explained. Just can't get to that yet :)
Yet, part of what I've been grappling with is the organizational structure. To make the guide most useful it should have an easily discernible path of things that almost everyone has to know, then another level of hypertext of more refined suggestions/tips. First steps to Advanced. Sort of what you need to know to start posting and do basic setup, then what you need to know once you've been using it a little while and want to start personalizing, thinking in terms of novices and their path on the learning curve of understanding the software. In some ways, that's why the collaborative book works well because perhaps top level pages beneath the root page should probably be basic config, and advanced as sub pages.
:)
That's why simple themed how to's work. Simple instruction sets are also easier to keep updated. By the time you get the complicated ones done, the next version of Drupal is out. 3-7 target 'type' sites. After that more general 'design' type articles. Like how was the teh default phpTemplate theme arraived at? (ala http://www.stopdesign.com/log/2003/05/27/in_the_garden.html). I am alwasy interested in how people design things. It helps give you insights you may have missed. It gives you ideas for your own sites.
If I didn't mention it, nice job btw.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
well. phptemplate -> default
was arrived at because I realized that 90% of the time, building a drupal site involved getting rid of all the theme designer's colours / etc. So i decided to make a very basic default template , with the cleanest XHTML markup , and least css to make the thing run/pretty. I refer to it as a 'clean slate'. I want to make a similiar template the standard 'base' template in my proposed template system.
haha
haha, obviously you dont deal with "normal" bloggers ;-)
Good luck!
useability and ease of install
Ok... having read the first 6 posts I thought I would jump in here with a newbies perspective.
I am a Windows System Engineer (ya ya go ahead) and I am very good at what I do. I am not a developer in any sense of the word. I had a basic html web site that was a pain to maintain, so I learned enough about Dream Weaver to use it's templates. I was was still modifying a static page web site and now I needed a program to maintain it properly. Nuke didn't appeal to me, I tried to get phpWebsite to work, did once never could again..... so then I came across Drupal 4.3.
What the hell... wow, it worked, on a Windows 2003 IIS6 box, first try (ok, I had issues with the image module but I got it working and am still playing with the File Store). While it was not easy, it was not hard as long as I carefullly followed the instructions. (Databases happen to be one of my beggest gaps which I am rectifying through a class now). Upgrade to 4.4, coolness, it worked too.
Further info. I have three sites with differing requirements.
1. Personal site with a technical knowledge base that others can contribute too. Hmmmm, blogging and (Wow!) Taxonomy is cool as hell, now I actually have to devote some planning time to layout and vocabulary. Oh and resume of course :) Oh, what's this news feeds... wow instant content and centralized info on some of the sites I used to go to.
2. Sister-in-law's business site.
---hmmmm, events and scheduler for her classes.
---she doesn't want 'submitted by' to be displayed, must learn...
---she is considering a blog (she does knitting) and my want to build a community of her email list .....
3. Dog rescue group. They just need a site that they can have an event calender and some articles and pics that don't change much. No submitted by info at all. Nice to have submits through web page.
It looks like Drupal will not only fill these needs, it will fill them well. Paticularly the Taxonomy for my KB.
Now, areas of issue. Most of these have to do with learning the product. The theme system is confusing, I have finally figured out how to modify the xTemplate theme and phpTemplate is singing it's siren song of css to me (darn, now I have to go spend time on css sites figuring that out too). On some sites, I do not want 'authors' comments to appear at all, on others, I only want them on the blog. Axe gave me pointers in the forum that I need to try out.
The install required a user be familiar with mySQL. The meu system is NOT obvious. I only recently started figuring it out. Once I got to a certain point, it started becoming obvious. I still don't understand th finer points of it (like I saw referenced how to make it only appear on certain pages).
It is very easy in some ways and very hard in others. Most of the difficulty appears in learning the 'vocabulary' of the product.
Perhaps the suggestion I can think of is a few 'turn key' how to's.
1. This is the steps to a blogger type site similar to M-T.Note differences.
2. This is the steps to a slashdot type site.
3. This is the steps to a news publishing site ala wired.
-From this flexibility combine away......
The docs focus on how to use indivdual features. When you are learning a product, you may not understand what individual features combined can get you. For instance, I stumbled across a reference to the calender and scheduler working together.
I am still playingvwith it on my beta site, but the more I play, the more I like. I habe a friend who is now, dude, can you help me do that with mine?
I like Drupal, most of the issues I see are with learning how to use it and the fact that it is so close to being a toolset that you assemble. If there were some directed tutorials (see above) then that could be the basis for getting people off to an immediate start with some of the common types of installs. Using that as a base, they can then add and customize to their hearts content.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Valuable feedback
Thanks for your great feedback. I think your post illustrates some of the key issues and puts them into a context many people can relate to.
I'd like to invite you to help translate your experience into concrete action points. We could use your help. Once the action points are in place, we can start translating them into code.
Oh crap, I seem to have volunteered.
:)
Ok. I will edit and clarify on my post in that thread.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
I agree with this too...
As a complete n00b myself, not only to Drupal, but also to PHP (hey, I like a challenge!), I've been forced to climb the hill pretty fast but that's partly why I chose Drupal in the first place.
I chose it because I was told that you get given a basic format that you have to customise extensively to mold into the system that you want. I've had loads of questions unanswered on this site, but most of the answers were found in my lack of PHP knowledge, and my system setup (some of which still to be resolved, but I know who I can bully into doing that for me)...
As for the suggestion above, it would be a good idea if you can get someone to do it. Maybe in a few months time I'll know enough to look into setting up a blogging site and document it thoroughly but that all depends on how my own site takes off... :)
I think it's more likely that without these tutorials, people will be forced to find someone like you to set up their site for them, it's all about design and concept and combining features and modules (which is where the headaches come), but once that's sorted out and in practise, the system is really good. It's a shame that people get put off because everything isn't covered yet when they shouldn't expect any cms to do what they want out of the box anyway. That's why I've stuck with it - because I know the answers are in here, somewhere...
I have to admit that I couldn't get on with the themes though - I've ended up using the contributed adc theme, which is the most simple theme to modify ( I think) and I've mainly done it with css.
http://www.dash.yi.org
Hiding Author-name
Sepeck:
Sepeck, you are not the only person to ask for this feature. I compiled top-three most requested features from Drupal users almost two months ago, in March, and this topped the list. Followed by native image handling. Good to see that Drupal 4.5 will have native image handling. But ability to hide author-name and time-stamp did not make the list.
Right now the only way to hide author-name and time-stamp is to delete the corresponding codes from the themes you are using. It is rather simple and easy. The wish-list thread lists ways to do it too. One problem with this is that it commits you to an author-less look site-wide. So if you want author-names for some nodes (posts or articles) but not for some other nodes, with an author-less theme, none of your nodes, be it articles, blog entries or stories, will have author-name. This is not the best of solutions. But this is how Drupal works now, and if not added, probably will work in 4.5 too.
Not quite correct
You can make template fragments apply to different node types, so you might have story and book node types not display authors, but have them turned on for blog nodes.
Yes, it would be great to have a theme where there are check-button options on a per-node-type basis.
submitted by
Ax answered my question on the submitted by and I tested it succesfully with the xTemplate theme.
http://drupal.org/node/view/4693
Ax also provided some php code to actually do it by node type outside of the theme. I did not have the time to actually look for the php code to change and figure out how to place it. (I also have not remembered to strong arm my friend who knows php into coming over and walking me through it by offering him dinner).
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Re: DrupalEd and DrupalBlog: Preconfigured Drupal Distributions
"One of the biggest complaints about Drupal is that it's difficult to configure."
More to the point, in my experience, is that the Drupal development community has no use for users.
BTW: Kaironews indicates that I can log in using my Drupal account and I was unable to do so.
re: more to the point
"More to the point, in my experience, is that the Drupal development community has no use for users."
Hmmm...hasn't been my experience. I tend to think that for such a small core of developers, they are very generous with their time offering support.
"BTW: Kaironews indicates that I can log in using my Drupal account and I was unable to do so."
Don't know why. Others have; for example, heather uses her drupal login. And I was just able to with my drupal.org id. Perhaps it was a momentary server connection problem between Kairosnews and drupal.org. Sometimes those things happen.
Dear jcwinnie More to th
Dear jcwinnie
You stressed the word development. WEll If you would re-read that the answer is in that same sentence. There is a development community, who develop drupal. The core tasks shoiuld be developing. And indeed there are a lot of questions asked, much more than anyone can ever answer. PArt of this is due to some questions that are asked over and over. This makes a developer takes an hour ore more per day to answer questions frustrated.
So: If you are not happy with the way the development community works, you could join Drupal and help other users. This can be as simple as writing documentation, answereing support-list questions and post in the various forums.
REgards, and hopefully see you soon on the support lists!
Bèr