A couple weeks ago I wrote a post on why customers complain about Drupal -- the short version is that they either had incorrect expectations, or "developers" who were in over their heads. Nothing wrong with Drupal there. There are some very legitimate downsides to Drupal from a technical perspective, however. Here are our top 6, and why they're not enough to keep us from recommending and using Drupal for nearly all our work:
6. Drupal is a total memory hog.
Under the hood, Drupal has a really powerful hook system, which auto-detects and auto-loads functionality. All a developer has to do is follow a specific naming convention, implement a specific hook, and the code gets auto-discovered and called in the appropriate spot. This power comes at a cost -- Drupal has to load every single enabled module on every single request to see if it implements a necessary hook. Since PHP is process-based and doesn't have any long-running threads, this means there's a performance hit.
On low-end commodity hosting, there may not be enough RAM available for the web server to load a large Drupal site. Generally we need to allow PHP to use at least 128MB per request, and on some large sites running lots of modules, even more. If you only have a couple GB of RAM available, you could run out with 20 active requests.
Fortunately, hardware is relatively cheap, and with the various caching strategies we typically use with Drupal, we can get sites speeding along. But this does mean you need quite a bit more hardware to run a large site than you would with a static site or a leaner, more efficient framework.
5. It's PHP.
I actually really like coding in PHP -- it's easy to learn, easy to understand, and pretty powerful. But it has a number of flaws. Historically it has had a slew of security problems due to a bunch of convenience things that went so far as to conveniently include remote code in every request, if you passed a certain GET parameter! These are pretty much a thing of the past -- PHP 5 did away with most of the glaringly easy ways to hack PHP sites. But PHP has kept the reputation for having shoddy security baked in...
I would really call out 2 weaknesses of PHP: no threading/inter-process communication, and very poor Unicode support. Lack of long-running threads, worker threads, or other things along those lines means that a huge percentage of the Drupal framework needs to get loaded on every request -- it can't just sit there in RAM waiting to get called. Drupal does not really have a way of registering functions that implement hooks -- it does cache many of them, but not all.
The Unicode issue almost seems criminal. We've had UTF-8 for way over a decade now, but PHP cannot accurately tell you the length of a Unicode string? This is supposed to be fixed in PHP 6, but for the time being, this means doing much localization work in PHP involves having your own string management functions.
So our assessment: Security issues are no longer worse than most other available languages, caching can mitigate some of the lack of threading (and it does make it a lot easier to program), and Drupal works around the lack of UTF-8 support with its own functions (but why should it have to?).
4. Version wars.
Drupal 7 has been out for 10 months now. Drupal 8 is in development. Drupal 5 is no longer supported. And we're still building most of our sites in Drupal 6. Anybody who has built a Drupal site starts out with the big question: what version should I use?
Drupal 7 isn't yet the slam-dunk answer. The reason? There are still a ton of very useful modules that are not yet available for Drupal 7 -- and many that are not even close.
Drupal 7 is a far better platform to develop on. However, there is so much already done on 6 that we can roll out D6 sites much quicker for our clients, at much lower cost, for all but the most simple brochure sites. We have done 2 D7 sites so far, and over 50 D6. D7 isn't even faster it turns out -- the main reason for going to D7 is that D6 is going to get left behind when D8 gets rolled out -- but at the current rate that's still a couple more years.
Drupal has a horrible reputation for painful upgrades. I would say that's largely an issue of the past -- most module maintainers provide decent upgrade scripts, upgrades tend to happen with no data loss and very little functionality change. But as a highly commercial platform (not proprietary, mind you, just used by lots of businesses) customers need to pay to get modules updated to the new releases, since most of the development of contributed modules is done by companies like Freelock, who get paid to do the work. And as long as it's cheaper to roll out a D6 site, and few other compelling functionality reasons to upgrade to D7, not many clients are willling to foot the bill to get the job done.
3. Abandoned modules
Or worse, modules that get replaced by an entirely different approach.
In the early days of Drupal, most site building was done by people programming custom modules on top of the Form API and the various other parts of the Drupal internals. Enough of these were generalized and shared back to the community that the next phase was characterized by thousands of single-purpose modules -- install exactly what you need for each feature you want to provide, and perhaps need over a hundred on your site.
Now the number of modules you need is getting far less -- we have more general purpose, extremely powerful modules like Views, Rules, Display Suite, Features, and Context. As a result, the single-purpose modules are becoming obsolete, and developers pretty much abandon them.
This is actually a good thing -- these power modules really let a site builder build exactly what they want. But they also each have their own learning curve -- it's not as simple to drop in and turn on the functionality you want, you generally need to configure the behavior you want after installing the power module. This makes the Drupal learning curve even tougher for people who just want a site -- if you don't know how to use the power modules effectively, you can easily get frustrated when you find exactly the module you want -- but it hasn't been updated for 2 years. Or if you've been using a module for years, and it's no longer supported -- and there is no clear upgrade path to something else.
This is where Drupal has turned professional. Site building in Drupal takes a lot of knowledge to do rapidly. And that's not knowledge even the best non-Drupal developers can get quickly -- so much of this knowledge is very specific to Drupal. Knowing which power modules can address the shortcomings of Drupal core, knowing when it's time to drop in a power module, knowing how to use the interface -- these you can figure out. But how do you even know the power module exists?
That's why good Drupal freelancers and shops are expensive -- they're in demand, and they can do amazing things very quickly. We may have a high rate, but we know how to get the job done...
2. Caching
Caching in Drupal is perhaps the biggest thing that mitigates the memory hogging, the performance issues, and so much more, making Drupal as fast as most any other platform out there. But it's also a curse.
In short, if your Drupal site is misbehaving, a surprising number of times clearing the cache fixes it. Drupal caches things at a lot of levels: during a request it caches every node it loads. The menu/URL system that drives every request is cached. Blocks and pages can be cached -- but by the time you reach the page level, you can no longer use caching if you have anything personalized on the page (such as shopping cart contents). Drupal also combines javascript and css into compact files.
Then there's system caching. We run a PHP opcode cache to get more out of PHP. We tune MySQL so that most of the database is cached in RAM. On some sites we set up file-based caches to skip Drupal entirely, or set up reverse proxies. And then there's Memcache for yet another layer of caching.
The problem with caching is making sure it gets regenerated when something changes. Generally the system is pretty good about clearing out changed data, but there are definitely lots of cases where this doesn't happen correctly.
Caching is really a band-aid for the poor performance of Drupal, the dark side of having so much programmer power. The upside is that it works surprisingly well, and makes Drupal competitive. But it takes knowledgeable system administration to get the maximum performance, or to scale to handle large traffic loads. And it is a source of quirkiness, a bit of an X-factor that can make problems harder to identify and locate.
1. "Drupal Developers"
How do you know if you've found a good Drupal developer? Lots of people claim to develop in Drupal, but there's a huge range in the quality of the result you get, and it's very hard to tell without working with somebody a while whether they know the platform well, or whether they're going to be learning at your expense.
We are all going to be learning at your expense. Development is about solving problems -- once they've been solved, they don't need further development! This is largely a question of experience, but I think there's an element of talent as well -- the talent to see where the crux of a problem lies, and be able to sniff out the heart of the matter. That's a talent, but more important is experience. We have learned a ton by making mistakes. We know how to roll out changes to production sites without breaking them (or at least keeping the broken time minimal). We know how to undo our changes if something goes awry. And things go awry in complicated systems more often than we would like. Experience has taught us to build systems to protect every move, much like a rock climber scaling a tough wall -- while there are a few "rock star" climbers who may free-solo El Capitan, most people who attempt that end up dead. Smart climbers use protection so that if they make a mistake, the rope stops their fall.
Making changes in sites that are already live is quite similar, and to do this smoothly, the protections need to be there from the start -- you don't scale half the wall before putting on your harness and trying to find your ropes.
The problem with inexperienced Drupal developers is they don't know how to protect themselves from the future. In Drupal circles, there's a phrase "killing kittens" -- if you're modifying Drupal core code, that's what you're doing -- something terrible. And the reason is that the next upgrade will clobber your changes. There are safe ways of changing just about anything you need to do -- but "Drupal developers" who are just trying to get your site launched and don't care about long term consequences don't bother with doing it correctly.
A lot of our business comes from cleaning up the messes left by developers who did not build in a future-proof way.
That's our list... do you have any others? Can we help you out of a jam from one of the above? Please comment below -- we moderate comments to keep out the spam, so it might be a few days before we post it, but if you're leaving something constructive it will show up.
Wow. Agreed! I'm still glad I
Wow. Agreed! I'm still glad I went with Drupal though. I imagine things will get better over time!
I dont understand why a major
I dont understand why a major version upgrade from another Drupal must be a royal pain in the ass! When only one thing, zero coding or anything I work with a few clicks WordPress site.
It's because Word Press's
It's because Word Press's engine is like a tiny Lego motor, so upgrades are a matter of snapping it out and snapping in a new one. They just don't change that much.
Same thing goes for changes within a major version of Drupal.
But when you go from one major version of Drupal to the next, it's like changing the entire kind of engine. Drupal 6 had a regular gasoline engine, peppy and good. Drupal 7 moved to a diesel powerhouse, capable of hauling big loads, but also a bit of a hog. Drupal 8 is looking like a hybrid diesel-electric engine, efficient, powerful, capable of powering 300-car ferries.
With each of these engine changes, you pretty much need to rebuild the entire vehicle to make the new engine fit, change the filtering systems for the fuel supply, and much much more.
To What Benefit?
To What Benefit?
Well Said
haha -- very well said!
well it's 2018. D8 is out…
well it's 2018. D8 is out for 2 years , most modules I would like to use are not in stable release for D8. In D's best time 2015-2016 D7 had 12% of php CMS market, it has gone down to 6% in early 2018. Seeing where it is going, having to hit the wall with my head to learn D6, then hit another wall was when moving to D7 and now I would need to hit another wall to learn D8.... I made a decision... I will not be learning D8. Goodbye Drupal
You sir - are so RIGHT!
There's no point in learning Drupal, with all the architectural decisions it's a framework that doesn't relate to scalability principles, best coding practices, design patterns, OOP, TDD, etc... If one wants to use Drupal - fine by me, to me Drupal is like Cobol... Old, bloated and unnecessary evil with extremely high learning curve. Worst thing is - there is NO way to just inherit a site and read the code... as it's all just one major HACK... I have worked on 3 big drupal sites (for a total of 2 years now) and they were always "unmaintainable" in the long run...
Almost all big companies have unmaintainable sites
@tinnerdxp
I don't think having an "unmaintainable" site is an issue of Drupal on it's own. I've worked with Drupal, AEM and WP, and if you ask me it's the "crazy" developers that want/need to create custom code that will work with one version but will break stuff in the next version. Sometimes this custom dev is needed since there isn't a solution provided by the platform itself, other times devs aren't aware of everything that is available or just want to "play around" since they think their solution will be better. I've worked with dev teams (30-40 people in total) that deliver less stuff in one year than some individual could do in a couple of days.
Been years
Face facts, it's bloatware that tries to be more than it is, using technologies no longer required to achieve something far worse than what other frameworks achieve faster, easier and with better logic and flexibility.
You could literally move to a JavaScript Framework with an API and get way better results than Drupal will ever deliver and at a fraction of the cost.
You forgot the biggest one
No, storing everything in the database is the #1 reason Drupal sucks. Trying to coordinate database versions among a team of developers across dev, staging and production environments is the single biggest pain point in developing a Drupal site. Drupal might actually be a decent platform when this problem is solved.
Hi Jason, Thanks for
Hi Jason,
Thanks for commenting. But there's a module for that!
We use Features module to coordinate staging structural changes that are in the database, to export configurations to code.
It is a bit cumbersome, and doesn't cover everything -- but more and more it covers the vast majority of what we would want to deploy between different instances of the site.
Combined with drush to update or apply the features quickly, and git to merge in any conflicts, most database changes are completely manageable.
I would definitely agree that deployment on Drupal is challenging, but that's a flip side of the power and flexibility that comes from being able to change the data structure on the fly through the interface -- and with the current tools, a lot less of a problem.
I am glad you have answered
I am glad you have answered this post. I would not have been as tactful as you have been in my answer. Incidentally, this ties in with point #1 that you have made.
I see someone talking about "teams of developers across dev, staging and production" without having even heard of features. To me, that sounds like a big pile of steaming manure.
Thanks for the great post, keep on drupaling!
Drupal 8 should fix most of
Drupal 8 should fix most of that.
There are so many things
There are so many things wrong with Drupal I really have no idea why any decent company would use it.
We tried it where I used to work about a year ago, we had numerous issues with it, a couple of which were:
- Modules not getting bug fixes / support, which then meant we had to delve right in and in some cases it would have been quicker to simply write the module ourselves.
- Flexibility, or rather lack of, primarily due to the terrible performance / heavy resource usage, we found it quite limiting in what sort of site Drupal was suited to, ideally it seems to be for content sites that have enough traffic to warrant a dedicated server and where most of the content is not updated that much so caching can act as a crutch. Which was pretty useless for a lot of "social media" sites which are updated a lot as Drupal's performance was simply unacceptable. Same goes for when we were being nice and doing say a site for free, for a small charity, they don't have the money (or traffic to merit) a dedicated server that Drupal seems to need.
- It is a badly written mess, not just in terms of code, but the actual mechanics of many aspects of it, for instance implementing the design, all our designers who are quite at home with templates / HTML, could not stand the bitty, over complex, all-over-the-place nature of Drupal.
In the end we went back to a framework, they perform better, are written better, they are easier to debug, are more flexible and once you've got a some basic common modules/plugins/admin written then they are quicker to develop with.
Hi, Simon, Thanks for your
Hi, Simon,
Thanks for your comment. Much of what you say is true -- modules getting out of date, heavy performance/resource needs, and some over-engineering in many places that make it more complicated to do things than should be necessary. And I'm finding with Drupal 7 that some of these things are getting worse, not better.
But at the same time, I disagree that going with a framework gets you there quicker. I would say that if you are proficient and experienced building on Drupal, you can get a lot of functionality deployed very, very quickly compared to a framework.
The main reason to use Drupal is to get moderately sophisticated sites up and providing value to your organization quickly. To do this successfully, you definitely need to be very knowledgeable about what works and what doesn't, what modules to use and which to avoid, and when to just write some quick custom modules from scratch. But you also need to be knowledgeable about a framework to develop something solid there, too -- and I would argue that you have more work to do to get a moderate level of functionality built and deployed quickly.
For large custom sites, either Drupal or a framework can get extremely successful results, with different development challenges along the way. With Drupal, you're going to be dealing with caching strategies, memcache, custom modules -- but it certainly can scale up to the largest scale. With a framework, you have to build more (and if you're not careful can still end up with performance issues).
Cheers,
John
"- Modules not getting bug
"- Modules not getting bug fixes / support, which then meant we had to delve right in and in some cases it would have been quicker to simply write the module ourselves."
Oh no, that means you have to write some code yourself :/
Having to the write the code
Having to the write the code yourself rather flies in the face of a major alleged selling point of Drupal - i.e - that there are all these modules that provide functionality saving you the time / effort, but of course that would require them to be kept up to date, which seems a big issue with the non-core modules.
Which leaves you in the position of having to write modules yourself, I can do that in frameworks, that are much better written, more flexible, can be run on half the number of servers (sometimes less) and are generally more pleasant to work with.
That is why it is called open source
So that if you want a solution you could be part of it instead of waiting for others to fix it for you :)
But one needs a spec
But before you can fix software, you need to know what its author intended it to do, which means you need a specification. And so many Drupal modules don't have one. Have a look at some of the PDFs for packages for the statistical language R. Compare with the documentation for an average Drupal module. With Drupal, I'm too often in the world that computer-scientist Tony Hoare described 40 years ago in "Software Design: a Parable".
Are you submitting yourself?
A complaint about missing bug fixes is one thing, but the question is if all the complainers who had to fix it themselves are then also contributing their fixes? Drupal.org is a community and I get the feeling that after Drupal 7 something went wrong with it. I think that there are working drupal systems out there with bugfixes that were never committed back to drupal.org. When the community breaks, then drupal.org breaks and we all suffer.
Over complex, all-over-the-place nature of Drupal
That about sums it up. The biggest problem I had simply learning Drupal was dealing with modules used as examples in the learning books I was using that were out of date and not maintained. Then, when I finally learned the software, I discovered that I was going to be spending (wasting) a huge amount of time testing and maintaining modules. It is truly module madness, even with GIT.
Upgrading Sucks
I cannot understand why upgrading Drupal from one major version to another has to be such a royal pain in the ass! When I work with Wordpress sites its only a matter of a few clicks and zero coding or anything.
I'm so done with Drupal I cannot tell you. :-(
Ummm... you clearly haven't
Ummm... you clearly haven't used drush. Upgrading even major versions is relatively painless in drush - you'll still need to deal with the fallout of modules that are no longer compatible, but that's to be expected.
Ummm... you clearly haven't
Ummm... you clearly haven't read (or rather understood) what 'DC' was saying. When someone says there's a feature in WordPress that isn't in Drupal, this isn't an opportunity to jump in with some command-line solution. I mean, your answer in itself points to one of the biggest problems in Drupal: namely, the fact that self-described 'developers' really have no idea what a user-friendly solution even looks like. Pathetic.
It's not quite that simple.
It's not quite that simple. Yes, WordPress can make very nice user-friendly solutions, for their relatively simple problem of providing a blog/news/brochure site. But for any site more complicated than that, upgrades are never a simple button-push process -- at least not without carrying a big risk of something going drastically wrong.
Drupal has an entirely different philosophy of upgrades. I would argue that most Drupal developers (at least competent ones) are working on far more complex sites than a typical WordPress site, so the assumption is that upgrades should be done very carefully, in a test environment, with code management and deployment processes in place. Not a single button click-and-hold-your-breath type of operation.
In this context, a command-line solution is far more preferable -- it lends itself to scripting, automated testing, and catching things that break before they become embarrassing problems in a production site. To me, WordPress's single-button upgrade process carries so much risk in it and puts so much out of your control that I would be terrified to use it. See this post for more...
Not to mention
Not to mention, how can you call yourself a developer if you are as scared of the command line as that guy seems to be. Maybe he should just stick to WordPress where he can just click his buttons and not have to worry about writing any code.
Time investment
Where i work we are maintaining several Drupal sites.
Out of all the sites we maintain many of which are built in Wordpress, Joomla, Expression Engine and so forth, the company accountant had the most unbiased view. ous
From a purely economic perspective our accountant sees the word Drupal most frequently in over budget timesheet entries. This involves many developers spanning several years so I see this as a legitimate issue.
If you are a Drupal guru and work primarily with Drupal I am sure there is not a problem you cannot solve. For the rest of developers who work on a wide range of platforms that would not be the case.
Sorry, I've been neglecting
Sorry, I've been neglecting the comment queue, and it's nice to see some real comments instead of just spam!
@ DC a couple points: first of all, upgrading in 7 can now be as easy as Word Press -- go to the update page and click the update button and all updates will get downloaded and applied. However, this is a very bad idea for security reasons -- if your site is set up on the server to allow updates, it makes it pretty easy for an attacker to plant code up there and hijack your web site. This is part of the reason we see a lot more exploited Word Press sites than Drupal sites... and now that Drupal does it too, I fear we're going to see more compromised sites.
@ Peter I would ask whether the Drupal sites are doing much more than the Word Press/Joomla/Expression Engine sites. Not all sites are equal, and it may be that your Drupal sites are trying to address a much more complicated problem. Or maybe your developers are learning Drupal on your dime (or otherwise suck).
Please stop using Drupal, you
Please stop using Drupal, you will make me less lucrative which will drive down my daily contractor rate :-)
yours faithfully, a happy drupal developer since 2006 :-)
Managing client expectations
I often see Drupal developer get a little too enthusiastic and telling clients that Drupal is made out of angel farts. This can make life miserable for everyone, especially those who have to clean up the mess later.
My only wish is that when building a website with any CMS, developers are honest with client about a CMS versions end of life, which is typically 4-5 years.
I am currently fixing a Joomla site that requires a complete rebuild to upgrade from 1.5 to 2.5. Drupal isn't the only CMS that sucks. All CSM suck after a while.
Drupal or no Drupal
I've been using Drupal a few years ago, and did a site or two.
In the last year I started developing with Codeigniter and Fuelcms and since I love coding I had lots of joy.
Now, I am going back to Drupal, since I have an opportunity for work with Drupal.
But I get so frustrated trying to do simple styling, simple jquery calls or other things around the site, that at the end of the day I'm ready to chope somebody's head off. I find myself sitting for hours reading tutorials, books, blogs, posting in forums and still don't find the solution for a simple problem that would take me an hour to solve not using a cms.
I don't know, I keep moving between using cms and not using cms. I guess nothing is easy in life...
Hi,
Hi,
This sounds like you've hit the learning curve wall on Drupal. It has its own patterns that make it extremely powerful, but also make things much harder if you don't use those patterns. And... these coding patterns change, sometimes substantially, between major versions.
But I would say, stick with it -- Drupal 8 is becoming much more like other frameworks you may have used. In fact, it is basically becoming a Symfony application. Aside from becoming much more object-oriented than it's ever been in the past, there are a huge slew of improvements -- configurations managed in code, a REST server in core, page-wide context objects, an entirely new theme engine using Twig... really exciting stuff from a coding and site management standpoint.
No system is perfect, there are always tradeoffs. But if you're a coder who ran screaming from Drupal in the past, take a look at what's going on in Drupal 8 -- you might find a system worth revisiting!
OMG exactly my sentiment!
OMG exactly my sentiment!
I used to play with CodeIgniter and I love it soooooooo much.
Now having to code with Drupal Commons, I've been having nightmare for a week...
@Signal,
@Signal,
I can sympathize with you. After programming with Codeigniter for 6 months I felt comfortable that I could build anything I wanted, now I have a new job using Drupal again and I am a year and a half in and still struggling. Instead of coding I read about, and install modules and then use drop-downs and check boxes menus to try and maneuver Drupal into doing what I want. And unfortunately Drupal is a great solution for what we need in terms of managing user roles, users, scaling, speed (using boost module), and ease of use for content editors with wysiwyg editors.
Managing client expectations
I just wish developers would be upfront about end of life. All CMS have an end of life and many clients do not realize that.
the choice
The choice whether to use Drupal CMS should be given to the client instead of forcing them to use one and dictate the technology instead. Who decides that Drupal CMS should be used? Clients probably don't have a clue and instead hear someone saying Drupal is the solution for all of their problems, then quickly jump on board to find a developer.
Each application is different and has different needs. These needs need to be taken into account before selecting a technology. We ended up rewriting half assed Drupal mess too many time. Sometimes Drupal is the choice, but not always, be careful what you wish for.
Sayonara
Hi, I think you've packed
Hi,
I think you've packed three different issues into this response:
All legitimate concerns.
For #1, choosing and architecting a solution is definitely a more strategic decision than finding a developer to implement it. While there are things Drupal doesn't do -- desktop applications, or native mobile apps, etc.-- we think Drupal stands up well as a web application framework, and in the right hands it can greatly reduce development time. It's not extremely performant, but there are lots of ways to scale it as needed. And so for us, people either come to us because they have selected Drupal already (which is a huge number of our customers, and a big reason we've chosen to specialize in it) or because they have a problem we can address with a Drupal site, and they are selecting our team.
Frustrated website owner
Hey guys,
I've been trying to get a solution going, and maybe this is the right place, seems like everyone leaving comments really knows their stuff! I myself am a CPR instructor first, and business owner second.
So I have kind of a mess of a few websites:
http://www.funcpr.com is the old ugly main one
http://www.funcpr.com/newsite is supposed to be the newer design
http://www.funcpr.com/newyork is the NY site where we have classes
http://www.funcpronline.com is the online training side that will have user registration to view content, then a shopping cart to pay for a certificate.
We even have a back end that we use to keep track of students, clients, and schedules, and I've really wanted to add access control for instructors and clients that can only view their data, but no clue if there are modules for that.
This is done with a programmer coding in PHP and JS, and a mysql database. I have zero coding knowledge, but I'm tired of relying on the programmer for every little feature to add that I feel a good CMS will offer, either by default or with a module.
The "Products" we sell, are actually spaces in CPR classes, so we show a schedule, # of spots available, etc. Currently, I don't use a shopping cart for this, just a custom script done by a programmer, so no fancy newsletter, facebook integration, nifty payment gateway, and other bells and whistles that are found with a cms and good shopping cart.
So I'm thinking of bringing the website over to Drupal, and when the purchase needs to be made for the class registration, a shopping cart will be used, so I can add functionality in the form of modules ON MY OWN! I realize the custom pages can't be altered on Drupal (by me at least) but at least I'll be able to add functionality with a shopping cart module, right?
So what say you, experts, not sure what to do. I thought about wordpress, but heard with more of a complex website like mine, it might not be the best idea.
Any info would be greatly appreciated. Wheew! Finally done :)
Jason
Hi, Jason, I'll connect with
Hi, Jason,
I'll connect with you offline, thanks for commenting!
Meanwhile, here are some thoughts:
1. Yes, absolutely, a Drupal site can do everything you're looking for, and more.
2. You should be able to change content pretty much anywhere on the site, if it's built for you well.
3. I would not suggest playing around with modules on an e-commerce, production site -- there are a lot of crappy ones out there that could open you up to problems.
4. Before doing a custom e-commerce site, read this post about the costs: http://www.freelock.com/blog/john-locke/2011-09/hidden-costs-e-commerce… -- you are entering another realm of cost to do this well, without exposing yourself to a lot of risk.
Hope that helps, and feel free to contact us directly at 206-577-0540 or through our contact form (http://freelock.com/contact).
Cheers,
John
What will you suggest
Hi John.
I ever played with Drupal for some months a year ago. It's very powerful, but I faced the upgrade problems when Drupal 7 were released. Yes, Drupal suck!
I'm an amateur in web design. I use WordPress but now I wanting to try and learn others that are more flexible and powerful than WordPress. What will you suggest me? I know a bit about PHP but don't want to dig it deeper. The software should be beginner friendly, easy to update and powerful (like Drupal has CCK, Views, Rules, etc).
Handoko.
Hi, Handoko, All systems suck
Hi, Handoko,
All systems suck in one way or another. The important thing is to recognize clearly the shortcomings, and how to deal with them.
So in spite of the title of the article, we love Drupal here, and would completely recommend it for nearly any web project.
And Drupal is getting easier and easier with each version -- try Drupal 7, you'll probably find it quite a bit easier to use...
Cheers,
John
i love drupal
i myself work with drupal since 6. now i am with drupal 7 and a lot of things changed. i love it.
the ui is much better and since cck is in core its great. but its right, drupal takes time and for just a blog it would be a little bit overdose.
the learning curve graphic :)
http://athousandnodes.com/sites/default/files/styles/large/public/field…
greetings
ike
Pure Economics
Our accountant told us cannot use Drupal anymore due to the fact that over the last 3 years, with various developers, every project that involved Drupal lost money. Project using Wordpress, Expression Engine and PyroCMS have been and still are profitable.
Now we have former clients coming back asking us to help them "upgrade" since that nasty orange box now appears on their outdated site dashboards. In many cases it is simply impossible to upgrade without rebuilding the sites since many of the older modules no longer work with Drupal 7. From an economic perspective we simply can no longer go down that road.
Developers who "LOVE DRUPAL" take that long learning path and end up in a place they think of as the Temple of Drupal. Non-Drupal developers (accounting for 96.5% of the community - http://trends.builtwith.com/cms) see them simply as people who do not use OOP or MVC and are generally difficult to work with.
All I know is that if I was a Drupal developer (or a Flash developer), I'd be keeping my options open by learning something else.
Hi, Peter,
Hi, Peter,
Thanks for the comment. I would ask two questions about the Drupal projects that cost more:
In many cases, the problems that people choose to solve are not the simplest -- the complexity of a project can have a lot to do with its eventual success or failure. It might well be that the Drupal sites that did not pay off were ones that would have failed in any system, with improper planning.
If you're doing a complex web application, proper planning is critical to its success, as well as a full understanding of the system. Not just how it's to be built, but how its users need to interact with the system.
Having come from a non-Drupal background with plenty of exposure to other systems, I see how Drupal has a unique architecture that can be confusing/counter-intuitive to many experienced developers. And there are a great many Drupal site builders or freelancers who don't have a full understanding of how best to accomplish things in Drupal. Both can lead to a crappy end result -- the experienced developer may engineer additional systems that take a lot more time to develop than leveraging the Drupal API, leading to much higher costs, whereas the non-developer "Drupal developer" will get stuck somewhere unable to smooth some rough edge the client really needs smoothed.
I do think a Drupal site will cost more than a Word Press site. That's because competent Drupal developers are in great demand, and charge more for their services, whereas there's a flood of lower end Word Press developers driving those prices down.
However, as the complexity of your need goes up, the cost of doing it in Word Press quickly rises to match or exceed that of doing it in Drupal.
I would say Expression Engine is more on par with Drupal, though it's a lot smaller market and there's less power available out of the box (if you consider Views and Rules and some other critical modules to be "in the box" for Drupal), but it's more of a niche player -- we get a ton of business because we specialize in Drupal. I'm not familiar with PyroCMS.
If you're comparing to an MVC framework, I think you can get to an early deliverable far quicker in Drupal if your need is at all content related. For more specialized sites with very specific workflows, the cost of a competent Drupal shop compared to a competent shop around a framework of their choosing will most likely even out over time, and won't make much difference in the long run -- frameworks might get a slight edge if your biggest design principle is simplicity, while Drupal gets the edge if you want to support adding a lot of additional features/connect to other services.
Whatever the case, you don't want to be the first Drupal project for a developer or shop, just like you wouldn't want to be the first Rails project for a developer or shop -- it takes experience to be able to consistently deliver a quality product. It also takes a proper development process that includes planning and testing, and an appropriate budget.
We lose a lot of potential projects when we quote a price, because our recommended budgets include planning and testing. We gain a lot of business from failed projects, people who have gone with a "cheaper" alternative unable to deliver in the end.
So Peter, we'd be happy to assist your former clients with their upgrade needs. We offer ongoing maintenance plans, and set proper expectations about ongoing budget necessary for sophisticated sites. There are a huge number of very successful Drupal sites out there -- most of which have regular attention from dedicated staff or a firm like us on retainer keeping them going. Yes, that's a higher cost, which means the site needs to deliver more value to the organization. With its better security controls and broad applicability, we think Drupal is a great platform for custom e-commerce needs, client portals/extranets, vendor management tools, companies with a moderate-sized marketing team with an appropriate web strategy, and much more.
If all you need is a blog and a brochure site, and you don't already have Drupal talent on hand, Word Press will be cheaper. But I'd still encourage you to check out Drupal Gardens as a way to easily start with Drupal in a place where you can easily export and grow into a more sophisticated site down the road.
Cheers,
John
The topic
I do not agree with some stuff from your reply. The e-commerce is still growing and mistakes like those might happen.
______________________________
Edwin from free xbox live codes website.
The right tool for the right job
I agree with many of the points that you've raised, as well as with some of the other posters. The biggest issue that I see, is that Drupal tends to be advertised as a CMS like WordPress, when it's really more of a Content Management framework. I'm a big fan of Drupal, but only when it's used in the right context, and when Drupal fits the project at hand. If you're just trying to set up a blog then you do not need to be looking at Drupal. On the other hand, I feel like a non-developer could set up a fairly complex site, fairly quickly using Drupal along with some contributed modules. Sometimes it seems as though once people learn a tool, they try to do everything with it. You wouldn't use a screwdriver to drive a nail... So why would you use Drupal to build a simple "business card" site.
Hi, Richard,
Hi, Richard,
Thanks for your comment. And it's a great point you raise -- pick the right tool for the job.
But I would modify your metaphor a bit. Drupal's not a screwdriver, or a hammer -- it's a professional tool that takes a long time to master.
In the hands of somebody experienced, Drupal can be a very quick, effective way to get a simple "business card" site launched. In the hands of somebody who doesn't know Drupal well, they're going to spend a lot more time figuring out the tool than it will take to build a site in an easier platform.
I've built and launched simple sites in Drupal, with content, in under 3 hours. And we're working on systems to roll out site skeletons in under a half hour.
If you gave me WordPress to do the job, I can certainly do it, but it would be like taking away my tablesaw and screw gun, and giving me a skillsaw and hand screwdriver.
It's not that Drupal is the wrong tool for the job -- it's just the wrong tool for novices. And professionals of all kinds generally bring their favored tools to the project, whether it's construction or web development -- if you trust the professional, you should let them pick the tools...
Cheers,
John
Drupal7 forum
I have site in drupal 7. The site is very very slow. It consumes almost 100% CPU resources even if only one user is surfing the site.
The site has multiple content types. I have to migrate data from other site so I am using few modules for migrating data.
I am using few more modules like Image cropping, Autosave, Page title, Module for Meta tags etc
I dont think I am using any module which can slow down the site.
Pls help to figure the root cause of slowness and improve the performance of the site.
Hi,
Hi,
We'd be happy to get to the bottom of your performance issue. You can see our rates here: http://www.freelock.com/products/217 .
Most of the time, performance issues are related to not having enough RAM for the resource-heavy nature of Drupal. But if you have enough RAM, it becomes a matter of tuning the database and web server to use that RAM effectively and not swap to disk.
Let us know if we can help!
Cheers,
John
the wrong tool for the wrong job
I hacked webforms module before I knew about, or had time to know about, the Rules module or even content types and theming... 2 drupal trainings, 1 drupalcamp, 2 drupalcons and a preconference tutorial later I still do not consider myself competent at drupal, although they do throw me some sys admin tasks once and a while since I do know vi. Now I have to diff the webforms security update with my hacked version of webforms. I do know command line diff, lol... webforms was recommended for the job by a very very very experienced drupal developer. With all this sys admin work generated from the Drupal zeitgeist(varnish, php-fpm, git, mysql tuning, memcached, mongodb for field storage, blah blah blah) I wonder if I will just slide into devops full time to support the last mile (no actual sys admins will come within a mile of drupal devs) how can I go back to worrying about breadcrumb trails and wysiwigs and theming after all this, but then do I really want to be a concierge to these drupal devs who won't be budged from their macbooks and other nice things which they should not have, after multiple linux trainings are still a million miles from having access and lurking through operations and hosts and getting files moved around, learning or even having interest in chef, vagrant and similar stuff, and doing it without hosing the system and calling devops to fix the mess. Devops is recently being denigrated as a term not to call yourself if you want to be taken seriously, well what is the term to be then? "Loser"? It's good money...
Add new comment