Ask YC: How should I approach Drupal?
10 コメント
I've used drupal quite a bit, and other frameworks and languages. My impressions:
THE GOOD: Drupal is great for rapid prototyping. It is the best CRM to use when you need flexibility in the core system. Have multiple types of "content objects" that you need to display and act differently within the confines of a single CRM? Want javascript markup in the titles of SOME kinds of content and not others? Selective preprocessing?
THE BAD: Drupal can be hell-on-earth when it comes to getting multiple modules working consistently. Expect "audio" attachments to work the same way as "video" attachments using the two modules? Forget it. If a project requires A LOT of modules you haven't coded to work happily together avoid drupal because you WILL have trouble and won't know how to fix it. And smooth upgrading is not really going to happen if you have to customize your site (which would be the reason to use Drupal in the first place).
The good outweigh the bad for sites that you want to get up-and-running, or evolve iteratively from a quick start. If you need something that is tremendously polished with easy javascript integration go with Ruby.
THE GOOD: Drupal is great for rapid prototyping. It is the best CRM to use when you need flexibility in the core system. Have multiple types of "content objects" that you need to display and act differently within the confines of a single CRM? Want javascript markup in the titles of SOME kinds of content and not others? Selective preprocessing?
THE BAD: Drupal can be hell-on-earth when it comes to getting multiple modules working consistently. Expect "audio" attachments to work the same way as "video" attachments using the two modules? Forget it. If a project requires A LOT of modules you haven't coded to work happily together avoid drupal because you WILL have trouble and won't know how to fix it. And smooth upgrading is not really going to happen if you have to customize your site (which would be the reason to use Drupal in the first place).
The good outweigh the bad for sites that you want to get up-and-running, or evolve iteratively from a quick start. If you need something that is tremendously polished with easy javascript integration go with Ruby.
I'm sorry to say it but you don't sound like someone who has used Drupal for long at all. First, Drupal isn't a CRM. It's a framework that includes a CMS. For a great CRM that integrates with Drupal, take a look at CiviCRM (http://civicrm.org).
Second, what you say about making modules work consistently doesn't make sense to me, at least not as you describe it. Drupal can be hell on earth sometimes, but it's the job of the developer to decide which third-party modules fit the needs of the project and what needs to be written from scratch. Besides, audio and video attachments are usually wrapped in a Flash player and that depends very little on what module you use.
It also seems that you aren't aware of the best practice (http://drupal.org/best-practices) of not modifying Drupal's core files in order to "customize" your site. Of course modifying Drupal will make it hard to upgrade! Instead of creating a somewhat versionless fork of Drupal you should be using custom modules or PHPtemplate overrides to achieve the functionality you want.
Second, what you say about making modules work consistently doesn't make sense to me, at least not as you describe it. Drupal can be hell on earth sometimes, but it's the job of the developer to decide which third-party modules fit the needs of the project and what needs to be written from scratch. Besides, audio and video attachments are usually wrapped in a Flash player and that depends very little on what module you use.
It also seems that you aren't aware of the best practice (http://drupal.org/best-practices) of not modifying Drupal's core files in order to "customize" your site. Of course modifying Drupal will make it hard to upgrade! Instead of creating a somewhat versionless fork of Drupal you should be using custom modules or PHPtemplate overrides to achieve the functionality you want.
Buy and read Pro Drupal Development by VanDyk and Westgate. The theming chapter alone is worth the price of the book.
The book is very good, but it doesn't really cover CCK and Views, which are two very important modules that form the center of a lot of Drupal sites. Make sure to learn about those on your own.
Visit a user group, if you've got one nearby, and ask questions.
The folks at Lullabot offer tutorials on Drupal site setup, theming, and advanced programming. They're a fun crew and I suspect their classes are pretty good, if you have the tuition and travel budget for them. Their podcast is fun also, and much less expensive. It's not tightly edited -- the individual episodes are kind of long and rambling, and you might want to listen to them with a beer in one hand, to get into the proper spirit.
I keep meaning to watch the screencasts at http://drupaldojo.com/, but somehow I never get around to it.
The non-negotiable hard part of Drupal is the theming. If you're not a programmer, but you have strong power-user point-and-click skills, there's some chance that you'll be able to assemble an ugly, jumbled version of your site. This, I think, is one of the reasons why Drupal sells so well. But then you'll want to change the order of the fields on the Comment Preview page... and you will have to spend two days or more learning the Form API and the theming system. Be sure to budget the time or hire someone who can help.
The book is very good, but it doesn't really cover CCK and Views, which are two very important modules that form the center of a lot of Drupal sites. Make sure to learn about those on your own.
Visit a user group, if you've got one nearby, and ask questions.
The folks at Lullabot offer tutorials on Drupal site setup, theming, and advanced programming. They're a fun crew and I suspect their classes are pretty good, if you have the tuition and travel budget for them. Their podcast is fun also, and much less expensive. It's not tightly edited -- the individual episodes are kind of long and rambling, and you might want to listen to them with a beer in one hand, to get into the proper spirit.
I keep meaning to watch the screencasts at http://drupaldojo.com/, but somehow I never get around to it.
The non-negotiable hard part of Drupal is the theming. If you're not a programmer, but you have strong power-user point-and-click skills, there's some chance that you'll be able to assemble an ugly, jumbled version of your site. This, I think, is one of the reasons why Drupal sells so well. But then you'll want to change the order of the fields on the Comment Preview page... and you will have to spend two days or more learning the Form API and the theming system. Be sure to budget the time or hire someone who can help.
Evaluate the space before settling on Drupal -- if your friend has experience, it should make the evaluation that much easier. There are a number of high quality CMS systems available, and just being familiar with one isn't a sufficient reason to use it.
You may even find that a CMS doesn't provide much for you beyond what you can get with a nice framework in your language of choice, evaluate these before settling on the defaults at hand.
I've written some code in Drupal, and while it has many strengths, its level of abstraction away from just writing simple PHP code in my mind doesn't really differentiate it from a framework... and in the framework space, there are some nicer options available to you.
You may even find that a CMS doesn't provide much for you beyond what you can get with a nice framework in your language of choice, evaluate these before settling on the defaults at hand.
I've written some code in Drupal, and while it has many strengths, its level of abstraction away from just writing simple PHP code in my mind doesn't really differentiate it from a framework... and in the framework space, there are some nicer options available to you.
> just being familiar with one isn't a sufficient reason to use it.
I'm not sure that's true. If you don't need a lot of power or obscure features then there's no lost functionality, and if you're already familiar, you have no learning curve.
I think that already knowing how to use it is a pretty good reason to use it.
I'm not sure that's true. If you don't need a lot of power or obscure features then there's no lost functionality, and if you're already familiar, you have no learning curve.
I think that already knowing how to use it is a pretty good reason to use it.
Depends what you want to build...
1. Do you want to build a pretty state of the art community focused more on the content than on unique features - than it could be a good choice
2. Do you want to build a unique feature driven site? - maybe a traditional framework would be better
3. Do you want to take an agile development approach to building your community - it is a good choice
I would recommend putting your site concept out to the drupal community and getting advice from them (drupal.org)
I would recommend putting your site concept out to the drupal community and getting advice from them (drupal.org)
> I would recommend putting your site concept out to the drupal community and getting advice from them (drupal.org)
the advice from the drupal community WILL be to use drupal. there's no need to even ask.
the advice from the drupal community WILL be to use drupal. there's no need to even ask.
Well, first of all, that's not strictly true. I've recently joined the Drupal community, but I really like Rails and wouldn't hesitate to recommend it to the right person.
But, more importantly, when a member of the Drupal community inevitably urges you to use Drupal, they might also give you specific bits of invaluable advice like "oh, that thing you're trying to do is just Drupal core, plus CCK, plus Views, plus Organic Groups, plus Imagefield/Imagecache. Oops, except that Imagecache assumes X and you want Y... you'll need a bit of custom code. This other thing you want to do is 100% custom code. And those fine-grained permissions you want will add an extra 100 queries per page for logged-in users -- they'll stop working as your paid userbase grows, so remember to hire a hacker to re-engineer them if your app is a success. And make sure to budget extra time for theming, because it's a bear."
But, more importantly, when a member of the Drupal community inevitably urges you to use Drupal, they might also give you specific bits of invaluable advice like "oh, that thing you're trying to do is just Drupal core, plus CCK, plus Views, plus Organic Groups, plus Imagefield/Imagecache. Oops, except that Imagecache assumes X and you want Y... you'll need a bit of custom code. This other thing you want to do is 100% custom code. And those fine-grained permissions you want will add an extra 100 queries per page for logged-in users -- they'll stop working as your paid userbase grows, so remember to hire a hacker to re-engineer them if your app is a success. And make sure to budget extra time for theming, because it's a bear."
Approach Drupal like it's the head cheerleader at your High School with a raging case of gonoherpesyphilaids.
Rails and Django, by contrast, are like precocious eleven-year-olds who are really good at gymnastics.
Django is the shy one. Rails is already wearing the skirt and carrying the pompoms, but the high school girls rebuff her by claiming that she's not tall enough.
(Rails is, of course, also being secretly employed by the Enterprise at this very moment. The metaphor kind of breaks down here, although Ender's Game does come to mind.)
Arc, of course, is entirely free from sin, but that's partly because she hasn't been born yet.
Django is the shy one. Rails is already wearing the skirt and carrying the pompoms, but the high school girls rebuff her by claiming that she's not tall enough.
(Rails is, of course, also being secretly employed by the Enterprise at this very moment. The metaphor kind of breaks down here, although Ender's Game does come to mind.)
Arc, of course, is entirely free from sin, but that's partly because she hasn't been born yet.
Well here's a bit more detail about the project. The actual site and features of the site don't need to be that much more impressive than a basic social network.
We don't need very many features at all, we're just going to need to spend a bit of time trying to hack away at Organic Groups to turn it into what we need.
The nut of the site will be its content. Stylistically, we're going for Etsy without all of their fancy searches.
And in fact, the overall flow will in the end be very similar to Etsy, in that there will be users, some of whom create 'groups', or for sale pages. These owners have the option of making these pages public or private. The private for sale pages will act very, very similarly to traditional groups.
Instead of a PayPal module, however, we can get away with an email form for the time being. Sorry, I'd love to give you all more details but technologically speaking this product is very basic and I'd hate to see someone beat me to the punch :)
We don't need very many features at all, we're just going to need to spend a bit of time trying to hack away at Organic Groups to turn it into what we need.
The nut of the site will be its content. Stylistically, we're going for Etsy without all of their fancy searches.
And in fact, the overall flow will in the end be very similar to Etsy, in that there will be users, some of whom create 'groups', or for sale pages. These owners have the option of making these pages public or private. The private for sale pages will act very, very similarly to traditional groups.
Instead of a PayPal module, however, we can get away with an email form for the time being. Sorry, I'd love to give you all more details but technologically speaking this product is very basic and I'd hate to see someone beat me to the punch :)
Do you need a 'community site' with drop-in modules for stuff like 'post this to Reddit/del.icio.us/YCnews' and 'upload a photo'? Drupal is good.
Is it a custom application with tightly scoped, somewhat unique functionality? Then use something like Rails or Django.
DO NOT attempt to use Rails/Radiant for a full CMS, or Drupal for a mostly-AJAX browser-based app. Trust me on this. You have been warned.
Is it a custom application with tightly scoped, somewhat unique functionality? Then use something like Rails or Django.
DO NOT attempt to use Rails/Radiant for a full CMS, or Drupal for a mostly-AJAX browser-based app. Trust me on this. You have been warned.
I'd advise against it.
What do you really want to do? Wordpress can be surprisingly flexible. You might want to try that (w/ some plugins).
What do you really want to do? Wordpress can be surprisingly flexible. You might want to try that (w/ some plugins).
Why do you advise against it?
Drupal kind of forces the 3-column layout on you. It's not really very easy to extend (from what I've experienced). I've just never seen anyone have a good Drupal experience.
The standard 3-column layout is determined by the number of sidebars and block regions in the theme (not by Drupal). Some themes have as many as 18 block regions (header, banner, footer, content top, etc.) and blocks and widgets don't strictly have to be in the sidebar. It seems that you didn't know this, so I don't trust that your experience with Drupal is very authoritative.
i suggest that you checkout Zend Framework and #zftalk on freenode while you are at it...
Plan A was to find someone to do it for us. For a number of reasons that you all know, that didn't work.
Plan B is now to author the site ourselves in Drupal, a platform my good friend and partner has some experience with. We're deciding which modules we'll need in order to complete a basic, functioning version of the site.
Does anyone have any advice specific to Drupal? What should I look out for? Are there any other late-coming self taught hackers out there who are farther along in the process than I am?
Thanks!