Welcome to WebmasterWorld Guest from 126.96.36.199
Forum Moderators: ergophobe
My question for those that have experience, is what is it NOT good at? Most comments that I have read so far indicate that it is a little complex to learn in the beginning, but the way it works makes sense after a little study. Some people say it is by default ugly, but sites like TheOnion, MTV UK, et al look pretty good to me.
If you have a particular thing that Drupal doesn't do, please be specific. I am yet to deploy my first Drupal site, so I am trying to be thorough in my research. Thanks
But obviously that's a site specific issue and really any system built with cached pages would have the same issue I think.
As far as looks go, you wouldn't be able to tell our new site is a "Drupal" site. And the site I have on 5.x doesn't look like a Drupal site either.
First off, I think it helps to see Drupal as a development framework more than a CMS. It functions well as a CMS out of the box, but the reason to choose Drupal over Joomla, for example, is because Drupal is a more powerful development platform.
So if I were building a list and was going to arrange it based on power and customizability (top to bottom) and convenience and beginner-friendliness (bottom to top), my list would look like this
- Cake or some other framework
- hosted blog at blogger.com
Wordpress is flexible, but nothing compared to Drupal, but in a couple of hours you can have a nice looking site in Wordpress that your non-techie friend can use. But if you need the power, Drupal has it with APIs for the form system, the menu system and so on and so forth.
So Drupal weaknesses... One thing I must mention here, I am not comparing Drupal to other systems(despite the offhand comment) but simply pointing out where Drupal could improve. It's quite possible that a given CMS is worse than drupal in any of these respects:
1. There is the famous learning curve.
Getting your head around nodes, terms, taxonomy, menus and so forth can be a lot. What this means, though, is that Drupal has much more built-in flexibility than WP or Joomla, but things are less automatic. You determine the relationships between your page titles, your URLs, your meta titles, your hierarchy and your menu structure. These can all be set up independently in drupal (only separating h1 title and meta title requires a third party module).
Personally, that was the main reason I chose Drupal over joomla when settling on a platform, but it does take some study for yoru first site to figure out how it all goes together.
2. Usability issues
They are making usability a priority for Drupal 7 (likely out late this year) and have been doing a lot of user testing, but Dries (Drupal founder) was shocked to see the results of the initial user testing and how much difficulty beginners had with even basic tasks. Things like when you enter your password on creating an account, if the password strength is low you get a big bright red message and many users see "Error" and think they've done something wrong and back out of the reg process.
If you give someone a lot of privileges, the backend can get a bit crowded and forms a bit complicated as well, which presents some usability issues. You can manage this by altering your forms using the API (some serious skill needed there) or using modules like Vertical Tabs and BeautyTips. Commonly, though, people say that stripping the backend is part of any commercial Drupal job.
For non-admins, who will only have basic content creation rights, it's not too bad, though.
3. Ten ways to do everything
This sounds like an advantage, but it can be an obstacle to getting things done. You want images? Do you want to embed the Menalto Gallery? Or will you use the built in Gallery? Or Acid Free, brilliant Gallery, Gallerix, or just CCK Imagefield and define your own gallery content type? And how will users include images in posts? With G2_Image or TinyMCE or IMCE or Image Assist or...
It can get dizzying.
4. Image management
You'd think that with what I just said, there would be at least one awesome way to handle images. This is getting a lot better and is another major area that core developers are improving, but as one example, I would like users to be able to add a subgallery based on the context (i.e if they're in subgallery 2.2, from that context they could either create subgallery 2.3 or 2.2.1). It's no doubt possible in Drupal, but quite complex.
Also, I would like the original files and derivatives arranged in a way that relates to the gallery hierarchy. That's not the case, though there is now a way to create subfolders, so it has improved somewhat.
Anyway, I feel like it's close, but still a little disatisfying compared to the better dedicated gallery apps. That said, I have a site that integrates Drupal with Gallery, but Drupal has progressed to the point that if I were building it today, I would build it all within Drupal and if I had a zillion free hours, I would actually change it over at this point.
5. Code bloat
The general approach in Drupal is that a designer should be able to style any element without having to do any coding other than CSS. So that means that there is a massive collection of classes and element ids in the code. You can strip this out, but the default is to include it and stripping it is a fair bit of work. It's not bad with a basic install, but as you add modules and views and blocks, it can start to really add up.
6. Server load
Drupal has pretty good caching (though obviously it's not making things easy for Bradley!) and so for anonymous users, benchmarks faster than Joomla from what I've seen. But as you start to add modules, you start using more and more memory. This is true for any dynamic site, but because Drupal has phenomenally powerful modules like Views, Content Creation Kit and the like, you can quickly end up with a pretty heavy app. Of course, you can also, with almost no custom code, build a Facebook clone with Drupal. As the saying goes: with great power comes great server load.
Again, that's not a comparison to other CMS necessarily, but compared to custom-built app, Drupal will have greater load.
I hope that's helpful. Despite what I said about image handling, you can do most things you want and get some nice lightbox/thickbox effects very easily. I can answer a lot of those questions if you have them.
In terms of look and themeing, I would suggest that you have a look at some of the framework type of themes as well as the Acquia theme. Acquia gives you a lot of flexibility out of the box.
Framework themes are themes that aren't meant to look like anything at all out of the box and you build up what you need. The ones that come to mind are
And even with plugins to do some work, it's easy to end up with (for example) two title fields for people to fill in (both called "title") and cumbersome processes for people to do anything WYSIWYG. And flexibility = too many options in some circumstances.
I'm building the first Drupal site that I've tried where I want to allow community members to create complex content. I've been working on the content entry process, but damn it's hard to get anything that resembles the simplicity of Wordpress. On the other hand, the site in question just couldn't be done in WP as far as I know.
>>two title fields
I've only seen that when you have advanced profiles with the Content Profile module and you have to specifically use something like autonode title to suppress one of the title entry fields, or of course if you are asking for different titles for the h1 and the <title>.
Where have you seen that?
>>And flexibility = too many options in some circumstances
Have you seen the so-called Duplicate Module Hall of Shame?
two title fields
It's with the Page Title module. But in general I find the "create content" process to be far more complex (and sometimes counter-intuitive) than should be necessary - and seemingly impossible to improve without either yet more add-ons or source editing, neither of which I particularly like.
Duplicate Module Hall of Shame?
Thanks for the link :)
I'm on my first really hands-on Drupal project at the moment, and while I'm having a much better experience than with probably any other CMS, I still feel no more than three quarters there. There's a really danger of ending up with module soup as a way to combat core-editing (which seems like it will be more like maintaining a separate branch then a 'click and run' CMS).
I'm probably asking too much, I think ;)
But still, by necessity I've been involved with lots of content management systems (from commercial to open source, to ones made from the ground up) and I'm still happiest with Drupal so far.
The video is on my list, haven't had a chance to watch it yet, I'm afraid.
far more complex (and sometimes counter-intuitive) than should be necessary
Indeed! One of my top peeves along with the code bloat that comes with adding modules.
Getting the content viewing to look the way you want is not to hard. Getting the content entry to make sense and be usable is a challenge. This has gotten close to the breakign point and recent third-party usability audits have made even Dries, the creator of Drupal, to just declare this unacceptable. There are some improvements coming for Drupal 7, but I'm starting to wonder if it's too little too late and I don't think you should expect serious overhauls before Drupal 8.
and seemingly impossible to improve without either yet more add-ons or source editing, neither of which I particularly like.
That depends on what you mean by source editing. You do not need to edit core. You can achieve a lot of this in your theme (template.php and .tpl.php files). But like James Walker said in the talk that BradleyT referenced, you end up creating a form and then processing it several times, and eventually caching it. Not exactly elegant, but you don't necessarily need a module or any hacking to get this done.
I have to ask - why Drupal? For me, the answer is that if you want to do something complex, Drupal is a good framework to build on relatively quickly. For normal content management (i.e. a site that is not editable for most users and managed by a core team, dealing mostly with relatively simple content - text, images, embedded video - I think there are more straightforward choices.
Have you looked at the Concrete 5 user experience videos? Or Silverstripe? Just checking them out and it's a very different model from Drupal.
But then, I hate the new WP admin interface too. Still, the thread title calls for a bit of negativity, eh? ;)
I'm happy with drupal as a choice for this project though. If nothing else, when 6 months done the line someone says, "but why can't we do this?" I'm pretty confident the answer will be "we can!" even if it might be a slightly rocky road getting there :)
SS failed to install because I keep my testbed strict and they had used PHP short tags. Fixed that and then gave it a try. It follows a similar content management model to ModX ("assets" "pages" etc), but ModX makes more sense to me. Also, I was kind of surprised that SS won Pakt most promising, yet to add an image to a page, I have to go over to the files/assets interface to upload and categorize the image before it's available.
Concrete5 - I didn't find it intuitive in fact. Changes that I expected to be sitewide were page specific. I had to watch the videos in order to figure out how to change a template side wide and retroactively. I clicked around for a long time and could never figure this out. It *is* intuitive for the people who will be merely editing content on the page, but I wasn't sure how permissions work (can I differentiate b/w people who can change a page layout and people who can only change text?).
Perhaps if I put more time into C5 I could do things similar to what I can do in drupal, but that would take a lot more playing and I just don't have the time yet. I still have to get back to testing WordpressMU as well.
One thing that is great in C5 is the ability to build user input forms on the fly. That's a killer feature.
So like you, I'm back to drupal - the mess I love b/c I can get things done and so much is possible.
the answer will be "we can!"
discerning the difference between themes(templates) and theming
I can fix any pre-existing Drupal theme(template), as well as build new ones (and I can also do theming, which sounds weird, as that is NOT design), BUT that doesn't mean I can necessarily provide a TEMPLATE to suit absolutely everyone's or 'your' requirements (for free anyway) and/or that I could provide to the Drupal repository
After you theme over and above incorporating core modules you hit an upgrade probem - (which is why you have to always switch to a default theme for upgrading!) -If you do go with a provided theme and then you want to add another module..are you going to blame the theme producers or praise Drupal community for having thought about your needs before you and providing yet another module for free?
If I haven't done any better at explaining it, which I suspect I haven't, perhaps that's why Drupal can't do it either?
To my CSS/Design/template mind that is what Drupal are not good at BUT they've done a dashed good job of getting there :)
[edited by: SuzyUK at 9:24 pm (utc) on April 25, 2009]
I can build a theme that requires certain modules to have full functionality, but if I test for module_exists before taking action, then I should be able to turn modules on and off without breaking the site.
Drupal allows for varying degrees of separation between logic and presentation and if you start hacking around, you can easily break that model, but that's true for most systems.
If you want to provide just presentational elements, you create a theme and subtheme along the lines of the Zen theme. Then you do any overrides and other PHP in main theme, but you only give the designer access to the sub theme, which has templates or even just a CSS file if you want to go that route.
When I think WP themes, I think pretty design that just work with a couple of clicks, i.e. download and install
I think Drupal themes and I know I'm going to have to get into the PHP (tpl.php files) just to keep them running
Yes I know Zen too but, that still needs maintaining, a lot of maintaining - in fact the last time I looked at that theme I thought I needed a degree in PHP just to understand what they were trying to do with the CSS
which is of course my point, the two should not be dependant on each other regardless of the fact that you and I both know how both works
I have a theme I built in 2006, which I very nearly released, but am glad I didn't.. the upkeep of it, for myself has turned out to be quite enough, let alone the for Drupal community. That would be an (unpaid) full time, unappreciated job - especially considering the Drupal release rate!
The reason there are not pages on the WWW full of pretty Drupal themes (paid or otherwise) is that we just can't unless we are checking the next version and minding our themes as opposed to serving our clients
Yes sure the color module (core) is fab, but hands up those that are using it (widely!) with anything but a core theme?
running before walking IMHO, I love Drupal to bits, it is one amazing piece of work, and I can CSS anything so I'm not altogether worried, just saying that a theme or template is a pretty front that most folks just want to download and work with without worrying that the next upgrade will break it
I test for module_exists before taking action, then I should be able to turn modules on and off without breaking the site.
and that is a prime example, I do not hack core, have never done so - I as a themer *should* have no interest in if a module exists or not. However not all modules are created equal, sometimes you turn them on and a site design breaks. I with my themer hat on has to be aware that this can happen in order to create a somewhat robust solution (release a theme)
a case in point: I've recently found a fault with Views that would bounce back to a designer, or many contrib themes
Personally, I've already taken control of my own designs/themes, no matter the modules being used, through my .info file, but until D6 who knew or knows how to do that.
Some people say it is by default ugly, but sites like TheOnion, MTV UK, et al look pretty good to me.
It is ugly by default, and those sites have people working on their theme constantly. Likely teams who are proficient at both PHP and CSS. Those themes are not OS (nor should they be) which I think is reason enough to question what Drupal is not good at. If Drupal is to go to the masses then this layer has to become easier.
[edited by: SuzyUK at 8:45 pm (utc) on April 26, 2009]
- drupal is not plug and play. For most applications where it would be, some other platform is generally a better choice.
- drupal is more of a framework. It occupies some middle ground between Cake (PHP framework) and Joomla. The goal is to get it easier to use out of the box, but there are days when I wonder whether or not the better approach would be to make it do *nothing* out of the box and just let it be a CMS/portal/ dev framework.
- something like 4400 modules and a desire to make drupal do anything and everything may be bringing it to a breaking point. Did you see the video that BradleyT posted? It made it sound like Walker and Eaton weren't even planning on working on D7. That's like... I don't know Tedster and coopster not reading WebmasterWorld.
When you get into drupal and see all of the hooks and callbacks and this and that... it's dizzying.
Gallery recently decided that they had reached the breaking point and decided to retrench, cut features, slim the code down and rewrite the whole thing from scratch using a completely new framework. At a certain point, I think the same will happen with drupal.
At the same time, I still haven't seen anything out there that let's you build complex, social/community sites so quickly... but I would guess it's coming.
It made it sound like Walker and Eaton weren't even planning on working on D7
I don't think D7 will happen, at least not in the usual release sense.. it seems like a fork that isn't and one which could better addressed, perhaps with Drupal Acquia?
the thing is that Drupal is amazing, there is soooo much you can do with it, it's unbelievable, the 'core' hasn't yet been fully tapped (except by a a tiny few IMHO!). Which makes my point relatively minor, but my themeing worries are a barrier to entry which *might* dissuade the masses. I think my frustration is also born out the same frustration with that many serious (PHP) developers have reached?
at some point you take a chance on a software, because you believe (or can make it work?), but at some other point you just want /need it to work, because scalability becomes the next issue. scalability is what I think Drupal core developers are really up against right now
[edited by: SuzyUK at 7:31 pm (utc) on April 27, 2009]
For example, you have by default: comments, url rewriting, file attachement, authoring information, and an infinite number of features like this.
These features, can then be tied to any kind of content you add. So each new features can benefit from comments url rewriting, file attachement etc etc..... Modules by default can make use of already existing features, which makes the system exponentially feature rich.
For example, when you create a content, you don't see like in other cms, a different form because module was developed by this or that developer: all new content is centralized, and benefits from all existing feature.
In joomla one day I added a directory module: it was handled completely differently than rest of the system and forced user to register separatly, has its own content creation form somewhere else: not in drupal: any module integrates in the system almost as if it was built in by default in the system.
This is the key concept to understand about it which make it completely different than anything else.
Also, with drupal, you can very easily create any kind of content. Want a "Company" content type ? Want a "People" content type ? Want a "Video" content type ?
In few clicks you define your content, perfectly integrated in admin of the cms, each with its own field, permissions, settings and already benefiting from all the built in / added features (comments, file attachement...... )not only can you create your content type, but can use enormous base of module.
Another key concept about theming: drupal has a single main template: you define zones, and tell which features should load here or there, and when. For example, you may want a module display a block in your "left column" zone only for non registered users, or for registered coming from that specific page. Possibilities are endless.
The main template with zones, is far far superior than anything I ever worked with (of course you can dig deeper and define template for every bit of a module and use conditional statements).
Drupal is really different: a real, flexible toolkit. I can't possibly use anything else since I tried it.
One problem: sometime you must install a module, to have another module work. Even if the module update notifications is really well done, you can end up with huge numbers of modules, requiring your attention and support (for updates, fixes, and security patches) from benevolant, sometimes arrogant "free open source" developers. Both a strengh (countless features and modules) and a weakness.
Other problem: drupal management of files is very weak: by default you can attach files and things like this, but system needs to be more centralized: all files should be sorted in a "multimedia" library.
Also no suppport by default for WYSIWYG, and a pain to integrate images in your content as you type (again, file attachement weakness) or you must rely on modules for such a basic task.
[edited by: brakkar at 8:35 pm (utc) on April 27, 2009]
Most Drupal security issues come from third-party modules and the power of drupal modules is much greater than WP plugins and expose Drupal much more (many more user interaction, community modules).
Basically, modules that take input, especially XML-RPC type of stuff, will be targets.
So Drupal core is quite solid these days. Drupal modules are a mixed bag depending on the skill of the authors.
Possibly. I think it will, but you're probably right about the "not in the usual release sense". They're doing code sprints and all that, but they backed off on the annual release schedule they had before. Drupal 6 was ridiculous - most modules hadn't been ported to D5. Some just leapfrogged it. I think a lot of modules will never update to D7, which will almost necessitate a fork.
>> scalability is what I think Drupal core developers are really up against right now
Maybe, but Drupal runs some huge sites. Once you need to scale, I think profiling and such is necessary.
>>These features, can then be tied to any kind of content you add.
Yes, they can, but getting profiles and images to work as nodes is still quite a hassle. If only profiles were a first-class content type without having to muck around with the Content Profile module... the bane of my existence lately.
>> very easily create any kind of content
That remains, to me, one of the killer drupal features.
>>drupal management of files is very weak:
Agreed. Another area where improvements are promised for D7... and D8 perhaps. But still an issue.
>>no suppport by default for WYSIWYG
True, but I think it's gotten easier to integrate with the new WYSIWYG and related modules (latest image assist). I've got some bug reports in on those and I think they're ironed out now.
Most in the know stuck to D5. I think they are going to have a major headache if they go ahead and drop support for D5 when D7 is released.
I remember an enormous thread on d.o in '07 called "the developers must be stopped" and that makes a fascinating read as to the state of mind of the community vs. the dev guys. Here is is, hope it's ok to link it:
There was a very similar thread last year, although I can't remember the title of it.
What Drupal needs to do is to tackle the underlying issue that creates these threads: that the upgrade process is like pulling ingrown toenails with a red hot set of pliers. If that was facilitated and made less painful, people wouldn't cry so much about having to drop one version and go to another every year or so.
To keep a constant theme, the learning curve on Drupal is steep. It takes 40 hours to learn something that will take 10 minutes to resolve. Having 10 or 100 methods of accomplishing a single task does make it more complicated to select an approach and then learn how to implement it. And it isnít always consistent where to establish configurations settings. In some cases it might be in permissions, in the next it might be in content types, the next in a module or perhaps a comination. Thereís no one place to set configuration options.
Drupal is complicated. If youíve work with it enough, youíll appreciate the flexibility the complexity provides. I would also classify it as a Content Management Framework rather than a Content Management System. You have to build what you want. Right out of the box though it has greater functionality than most other systems and those functions are much more tightly integrated.
Where does it excel? If you have a large site or have complicated user controls. In the forums Iíve seen sites referenced that had 500,000 or more pages. You canít do that with every CMS. Also, if youíre building a commercial portal, Drupal is robust enough to handle the functionality and traffic. Weíre building our new site with Drupal because there is an ecommerce and membership component. These are areas where Drupal thrives. So far I havenít found anything that it couldnít do. I canít say for any other CMS/CMF Iíve worked with. Though I do believe that the site would have taken 1/3 of the time in another CMS. To be fair, Drupal was the only major CMS that could do the job.
Another area where Drupal excels is in modules. Drupal modules interact much better than the modules (plugins, etc) on any other CMS I've worked with. With other systems if you add the wrong combination of add-ins the site breaks. Determining the correct combination on those platforms isn't easy.
Though the addition of a module may reveal a dependency on one or perhaps several additional modules which in some cases may also require additional modules.
Here is an interesting comparison between Joomla, WP and Drupal: [cmsshowdown.com...]
Note the development time that each required. The ďsimpleĒ application took significantly longer than the more complex CMSs.