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.
Comments
214 comments
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 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.
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
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.
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 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.
Drupal 8 should fix most of that.
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 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 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 :/
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.
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.
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 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.
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 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 will make me less lucrative which will drive down my daily contractor rate :-)
yours faithfully, a happy drupal developer since 2006 :-)
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.
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...
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 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 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.
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 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
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 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 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
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,
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
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,
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
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,
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
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...
Sounds like you've experienced my #1 reason -- Drupal "Developers!"
There's a great many really competent people working in the Drupal community. But there are an awful lot of people selling themselves as Drupal developers who really don't have a clue about how best to make the system work in a supportable, maintainable way.
I agree with you -- if you're not comfortable using git, configuring servers, doing all the dev-ops stuff, you'd better make sure you have someone handy who is, and treat them well. That stuff is critical to the success of any large Drupal site. We started out with a strong Linux system administration background before ever getting into Drupal, and had full-time systems administrators administering servers for other companies as well as our own. We still call that role "Systems Administrator," though the people we have in it become Drupal devs as well -- perhaps dev-ops is a better job title for them (and I count myself as one of them...)
But then again, people come to us for security scans, performance and scaling consulting, and more, and one of our key products is an ongoing monthly maintenance plan -- we make money doing dev-ops work. So we take it seriously!
Typical article and comments by non-developers and non-coders who think they should be able to "upload via ftp" and everything should already be done for them. Just because you learned how to use FTP doesn't make you a "coder" or a "developer". If there's a bug, fix it. Simple as that. Don't blame others for your lack of planning, experience, or creativity.
Wow, after a long weekend stemming the tide of ~1000 spam comments and users, an actual, real comment!
@Drupalista, did you actually read the article, or just the headings? If you had actually read it, you might realize we're very pro-Drupal, very capable of addressing any shortcomings, and actually doing what we can to recognize real drawbacks that many uninitiated Drupal customers have experienced, while offering solutions.
Drupal has a mixed reputation out there because so many projects have gone awry. And they've largely gone awry due to "developers" not competent in how to build in Drupal -- like you said, people who have learned how to use FTP and call themselves a developer.
And the other factor is not understanding the full nature of the project the customer wants delivered, or having a realistic budget for it -- "I want something like Facebook, and my budget is $2000."
With proper budget expectations and competent Drupal developers, we think it's a great platform.
"I want something like Facebook, and my budget is $2000." is exactly my circumstances here.
John, do you think Drupal is the right tool to build community sites? I'm trying to bring a system (made by third-party developers) to the finish line.
It was built on Drupal Commons. Could you share some tips for newbie like me? At the moment, I am treasure-hunting every day trying to find where this and that piece of code come from. I used to code in CodeIgniter where everything is in your sight.
Hi guys , really nice comments here, i am new to drupal, i really loved the whole architecture and the way things are done there, but as soon a smy site is finished, SPAMMERS have almost ruined the whole site even with CAPTCHA enabled comments.
Please can anyone help me with this - Am almost losing my mind here !
1) Ensure you have Mollom.
2) Have recaptcha if the issue persists.
3) Finally ensure login to post the comments. You can use the Facebook/Twitter login in the site.
AND
Funny site is made with Drupal and comments Why Drupal Sucks :-) Very Funny!!!
I totally agree with the point about caching. It's really a mess when it comes to troubleshooting. But it also has a silver line: it works well. I have some sites that I don't even look at over weeks and still they have up to date cache.
A developer asked me to help him with some advanced development work for a university site and I "shipped" the functionality (it was about content moderating) as a custom module and they were quite happy. I wasn't allowed to access their site in anyway so at least I could add some rep to drupal hooks system. But it costs server resources.
Nice article and comments. Keep it up!
Hi there,
me - beeing a CMS integrator over 10 years think: Most CMS Systems sucks. Especially the big open source ones. I do Drupal multisites, multilanguagesites with workflows and so on and it sucks ^^There are so many times we´re discussing Drupal and it always results in "Drupals structure is not good since the beginning of time" we have developed a CMS and we had to rebuild it in the past years even we have dipl.informatiker (real coders) who are thinking about things before they do it. Most of the systems out there were something like a news database that grew. Sry i have to laugh but the drupal developers never heard about oop when they "developed" Drupal. So why do i drupal? Well it´s cool in some ways and after a really hard work and much modules it behaves a bit like a good CMS. But the development time IS yet high cause there are more screws to turn to have a good result.
And it seems better than typo, WP and the kiddy-system joomla so Drupal is like a one-eyed under blinds.
Once i thought, we have 2012 and the systems are a bit better. They are, but i think systems like CONTENS are way better.... if they had stopped dev in 2005 (and they did not).
2nd reason why we use drupal is that there are many addons out there and it´s popular ( well and we have not only customers who spends 50.000+ in building a website^^).
For those who are beginning with a cms and have customers where you are able to say "use the cms we have for you" give PimCore a try.
It won the Most Promising Open Source Project Award ( i think in 2010/2011). PC has a good structure. There are good possibilities to do things. But the award is not only saying that PC is good, it also says that there are only stinky OS-CMS out there ^^ (yes it does!).
Well me for myself know some cool (!) systems out there but unfortunately they are not ready to use (in my perception of usage) or are not growing fast enough or were simply not told the award referees^^ (Anyway.. we have 2012!). Surely there is the one or the other four star system out there which i don´t know. Sorry to you!
Ah and I have one more thing for your list: the learning curve. It takes much time to handle the Drupal api (for example) (which makes -as a sidenote- obsolete to talk about typoscript). And everytime you introduce a new module you have to learn again because you´re not only adding features, you change Drupal behaviours.
Greeetings
Lars
I just love these XYZ Sucks! threads. Ruby/Python/windoze/crApple/Java/PHP/jQuery sucks!! Is there anything that doesn't suck?
Of the 6 criticisms above, most of them have nothing to do with Drupal per-se and could be applied to any number of other technologies. The fact that Drupal developers can be hard to find or that PHP has a history of poor security aren't really criticisms of Drupal. Drupal caches lots and uses lots of memory. Well, these are issues with all CMS platforms. I don't know absolutely, but I bet Drupal, Joomla, Wordpress have similar resource requirements out of the box.
Bottom line, it's a trade off. If you want dynamic content generation, customized user pages, configurable widgets, etc... there is a price to pay. If you have mostly static content, there are many options to reduce memory and database usage (boost module, for example).
CMS haters gonna hate. They typically favor custom solutions. A lot of snobby, cms-hating developers think they're better off building up a rails solution from scratch. Well, talk to the company that buys into that in 5 years, and see how swell of a time they're having maintaining that, improving it, finding people to work on it. I've done it both ways, and I'll never build from scratch again unless there is a solid dev team and endless funding in place to do it right.
Building a large site is a lot of work. CMSs handle much of that work for you. All the time you save not building an authentication system, content interfaces, forums, etc... should be spent taking the time to learn how to use your CMS properly.
And quitting hating so much.
Your site is on Drupal - so - er, hmm, well... WTH? :) But I totally understand the frustration. With new versions, people hope to 'release' themselves of the developer-debt they've left behind while picking up some new liens on slicker technology - without the forethought on "gee, how are we going to carry-forward and make modules fit into the new system?". :) Instead - it's a... "hey, let's make it so good they'll WANT to do it..." and as you pointed out - the challenge with most developers (including myself...) is if it ain't broke - don't fix it! And why would a developer push their module/plugin/theme to a new version that hasn't even been seasoned as of yet... (ok, i'll stop here before I go change all my drupal sites to something diff ... possibly static html sites? :) :P ).
"Your site is on Drupal".... FUNNY.
John, you are self-contradictory. If you think Drupal is suck, why you use Drupal? You can use Joomla or Wordpress. But I don't think they are better than Drupal.
Going to 'Drupal Rock Star Developers' does NOT fix the core problems of the platform. We spend close to $ 100 K on a custom site, hiring some of the top Drupal designers and developers, very involved in the community, and authors of various popular modules. What we learned is that most Drupal devs don't know shit about OO programming, unit testing, deployment, respecting deadlines, reading UML diagrams and so forth.
After enduring 3 years of an unusable site (a large portion of our 30,000 members also author content, but can't figure out their way through XDrupal's admin mess and don't have the patience for its abysmal performance), we've decided to bite the bullet once more and move away.
I also have to laugh at the amount of excuses from the Drupal community regarding Drupal's piss-poor performance. You make it sound like it's a developer problem, yet your own static web site averages 800 ms per request on 100% static pages. The simplest web sites in you guys' portfolio gets 1000ms response time on most pages (and that doesn't account for any external files, I'm only referring to the initial request). That's just unacceptable.
Drupal is a mess, developed by PHP amateurs, and any business or non-profit should stay away from it.
Either you have simple needs (a blog and a few content types), if so Wordpress is something worth looking at. For all other complex requirements, find a hosted SAAS answer that solves 80% of your problem, and consider changing your business processes to fit the software instead of the other way around. That way, the custom work you'll have to pay for is simply an integration job.
Hi,
Thanks for your comment!
Those are definitely valid criticisms. But you haven't pointed out a better approach -- do you really want to risk your entire business to a SAAS vendor who may go out of business or pull the plug on something you rely upon? I would argue that SAAS carries a huge, often unrecognized business risk in that you don't directly control the functionality of your site, and you're relying on the SAAS vendor to get it right -- with what might be a very difficult migration if the vendor decides to take the platform in a direction that doesn't meet your needs.
So I think any organization that cares about risk management should be very, very careful before going with a SAAS platform. At least with an open source or custom solution, you've got full control over what your site does, and nobody can take that away from you -- you can always decide to roll back to a prior state.
So what's left? All CMS solutions, as well as frameworks, have some performance implications -- they tend to get optimized for one kind of performance, and suffer in other areas. I'd say where Drupal is optimized is in terms of developer time to get to a feature-rich, functional prototype very, very quickly. And in many cases, developer time is the most expensive thing to pay for.
If you're developing from scratch, you can optimize for page load speeds, have minimal code in page generation, and eek out actions in fewer milliseconds. Do your customers really notice a difference between a site that loads in 1/10th a second vs. 3/10ths a second? (Yes, our average page load time is more like 8/10ths a second when you visit pages not recently cached, but for our home page and popular pages with fresh caching, we're seeing more like 300ms.)
If you're using a framework like Rails or Django or Symfony, it's going to take a bit longer to get a functional prototype with as many rich features as you can get with Drupal, but over time I'd say the total cost is going to be quite similar, given competent developers. With a Drupal site, much of our time is spent on simplifying interfaces, removing clutter, smoothing out the user experience on a system that largely works out of the box, aside from a ton of tiny integration bugs that always crop up. With a framework, you tend to have to build more in the first place, but you can also leave out the cruft as you go, and keep it simpler.
Regarding what "Drupal Rock Star Developers" know or don't know about programming practices, you can extend to the entire web development community. You'll find a huge number of amateurs turned pro on every platform out there, a vast number with no professional training. That's not a problem with the platform, that's a problem with web development in general. True, Drupal isn't OO (but take a look at what's going into Drupal 8, where you can actually do much more conventional OO programming). But I think of it as more of an event-driven architecture, with its extensive hook system. Deployment is a challenge, when you have structural configuration stored in the database (again something promised to change in Drupal 8). Unit testing is built into Drupal 7 core now, and we're making quite a bit of use of the simpler UML diagrams to plan out what we build and make sure we're on the same page as our clients.
In short, if you have a complicated problem, a $100K site might not be a bad deal. You can very easily spend that much on a single in-house developer, and many custom applications are built by teams that can burn through $200 - $300K a year at least. Lots of enterprise applications cost more than that in yearly licensing fees alone, and then you're still spending more than that on implementation.
There's no magic bullet out there. I've seen enough under the hood of proprietary systems to know that just because some software is commercial and expensive, it can still be total crap.
Your developers are more important than the platform. And if your problem is complicated enough to need a major amount of their time, it's not going to come cheap.
Cheers,
John
There's too much crying going on here. Drupal developers contribute their work to you for free and now you want to cry about it?
Hmmm no, based on my experience, that's not how it works at all. Drupal devs make money as consultants, good ones charging about $ 175 to $ 250 / hr. Every custom module developed for the project gets released as open source - I was told by Drupal devs that's part of Drupal licensing model. So technically, those modules are not 'contributed for free'. It's more of a pulling of resources in order to avoid redundant work. In the end, everybody wins - devs, clients, and the community. But let's stop with that whole 'Drupal devs are all saints' rehtoric.
Sorry John, but these things apply to lots of software. Besides, everything has pros and cons, I don't think it is fair to say it sucks because of its cons.
For us, the single biggest nightmare with Drupal has been using it to implement a discussion forum. Requiring administrator approval for new users is the ONLY way we've found to avoid being deluged by literally thousands of Chinese and Russian spambots that have new Drupal account creation down to a science.
For companies that have a dedicated list of users, Drupal is fine. For those that want to interface with the public, I say RUN.
Disclaimer: I work almost exclusively with Drupal.
Yet I can still see why people might hate it. To really get the benefit out of the tool, you have to spend a lot of time with it.
If I wanna hire a dev for a job, mostly I would end up with one that does Drupal exclusively, which is a problem in itself. You have to work your way into the Drupal API, all the gazillion modules, workarounds and best practices.
So if people are using multiple tools and just wanna use Drupal for one or two projects, I cannot see a way for them to succeed. The people that complain here mostly fall into that category, I guess.
But as others said: this goes to blame any complex framework. We simply have not come far enough to have industry standards that are so widely adopted that you can switch from one CMS or Framework to another and expect to have the same workflow. The situation may be better with more low-level Frameworks like CakePHP, Symphony, Zend or Rails, but I stil guess you won't expect to adopt a new one and launch an important project with it within a months time.
So as sad as it is: If you wanna succeed with Drupal, you will need to put in a lot of time and basically build your business on it. Or at least have a solid Dev division (this means more than two or threee people) in your company that has that expertise. Else you are most certainly going to be disappointed.
Working with Drupal I have seen as many ways to develop Drupal as I have seen developers of Drupal. As a reluctant developer of Drupal my approach has been a hard sell to clients because I am not so much developing as un-developing or trying not to change Drupal. As a non developer, I do not have the flash and pizazz of other high and mighty developers for clients that seem to prefer big bloated complicated sounding ways to do things. I have found however that my sites perform well and do not break.
Thank you for showing the rest of the world what I came to know most painfully. Back in 2008 we paid a drupal developer to develop a cutting edge technology driven website, comprised of the drupal platform, php, mysql, with a custom database with a pretty extensive but simple algorithm,
It took almost 7 months of development to be able to do a launch. The guy we worked with, Bram M. of Game Face Webdesign, LLC was just god-awful and used over 30k of our money to build a cob-job of a website that in the end didn't function properly and looked like crap.
The website was to bring alot of people in and I'm convinced it would have definitely done just that.
But, he messed with the registration process, he changed the core code. There would be times if you hit the wrong button in the CMS it would change the theme and crash the whole website and lock it up. The only way to get the website back would be to do a set back on the server.
Years later and after much heart-ache AND months in court trying to get at least a little bit of our money back (which we did win in full), I'm stuck with a website that cost a fortune, that is stuck in some old fashion drupal program, and that no developer can figure out because he killed the core code. To fix it would cost a lot of money, we'd have to completely build the site from scratch again. As a start-up company, we only had that one shot.
Man, it would be my ultimate dream for a developer to help me pro-bono or based on future income. Doubtful though.
Coralyn, I would be interested to know more about this website and its functionalities - would you be able to provide a link or even leave a contact email?
But Drupal is still one of the best platforms out there. If the whole community were to abandon Drupal I would probably be the last developer standing to support it.
I usually find lots of biased opinions on Drupal and long lists of supposed problems that are not quite very accurate.
Yours is a very good list of problems with Drupal that anyone that is considering using it should take into account.
I myself love programming with python and I'd really like to spend all my working time with Django powered sites. The problem is our team can build Drupal websites in no time, thanks to all the excellent modules available.
Most of the projects we deal with need nothing else than Drupal. Django is nice, clean and considerably easy to learn and maintain, but even with its problems Drupal has the great advantage of having so many features ready to use.
I think Drupal CMS has problem with the flexibility and site architecture as compared with other CMS.
But, don’t think it is not powerful. Recently, there are 19,964 modules, 1,605 themes, 534 distributions and 23,111 developers in Drupal worldwide.
I've had great success with the following techniques regarding Drupal cacheing.
http://www.rklawson.com/blog/2012/04/14/caching-drupal-7-varnish-apc-an…
Using Varnish, APC and Memcache, with their related modules show great promise. Sites that I have implemented this on have extremely fast page load times.
APC really rocks in small vagrant box. Turn off all other caching, just use drupal apc module.
This is what I've got to say. Drupal's issues are learning issues. For one Drupal 7 shouldn't have been allowed to interfere with Drupal 6. Drupal 6 was when Drupal began to mature and instead of consolidating the gains made in Drupal 6, all the developers saw was the problems Drupal 6 had and then turned to focus their attention on Drupal 7, which also resulted in a split effort on the part where instead of improving and honing their Drupal 6 modules the developers turned their attention to Drupal 7.
Even at this stage a lot of Drupal 7 modules are not as good as their Drupal 6 counterparts if they exist at all? Take this module - http://drupal.org/project/select_or_other. A lot of Drupal 6 modules did the same job and much better, and it is still being maintained along its question able path. The edit list below should be a lookup list which will select the item being added if it exists or add it if it doesn't. It is as though the developer never knew Drupal 6 to base the module on it, what you may know as http://drupal.org/project/taxonomy_super_select which has a good write up here. http://pages.uoregon.edu/vid/2011/01/21/put-taxonomy-super-select-check…. This is the kind of module that should be adopted and incorporated as standard into Drupal, but somehow it seems to be overlooked in the rush to develop Drupal 8.
It really begs the question whether it is meaningful now to describe any particular version as Drupal. It seems now to be a name associated with a group of developers rather than a clear cut product. Drupal 8 looks like it is going to be so different that other than being able to load your data into it. it will be questionable to regard it as a successor to Drupal 6 and 7. Using Drupal is more a question of what developer community and philosophies you work with, rather than a clearly defined product.
As you can tell I have engaged in my fair share of Drupal Sucks debates, http://drupal.org/node/1603830#comment-6384644
http://devblog.brahmancreations.com/content/back-to-drupal-humbly-taill…;
http://devblog.brahmancreations.com/content/do-php-and-drupal-have-a-br…;
http://drupal.org/node/1299736#comment-6168028.
My conclusion is simply this - if Drupal is going to be an end user tool after Drupal 8 is finished more effort should be dedicated to end user install profiles. They ought to decide on a version which is more or less frozen for upgrades so that all effort goes into replacing existing parts with better written parts transparently. Without development of stable and durable installation profiles Its days as an end user tool are more or less over. After Drupal 8 the community needs to consider whether Drupal 10 should be written in PHP. The language is so awful. It has already turned into a developer tool and for them to learn a new, simpler clearer language shouldn't be difficult for them. The community is their strength, not their unwieldy legacy codebase. Ditching a lot of it will be a boon.
Hi, Frank,
That's a really great point. I keep hoping that we'll smooth out the upgrade challenges between major versions, but inevitably it ends up being a migration/rebuild than a straight upgrade, because how you solve a particular development challenge ends up being substantially different between the different versions. Perhaps an easier migration than from other platforms entirely, but to a certain extent, you need to rebuild your theme, re-create the functionality in the current set of preferred modules, constantly adjust your recipes with new best practices.
I still find myself asking, well, what is the alternative? Drupal may suck, but so do all the alternatives, they just suck in different ways! And sometimes even in the same way -- take the Python 3 upgrade, for example. I've been doing web development since 1995, and Drupal development only the past 5 years or so -- I've worked with or been exposed to a lot of other platforms. And you're right -- what's compelling about Drupal is the community and philosophy.
I'm terrifically excited about what's going into Drupal 8, but it really is a different application than 7, and 7 is an entirely different animal than 6. The problem with ditching the old stuff is that people are building businesses on this, and you can't force a major upgrade every couple years without having major defection from the platform. At least the time frame seems to be lengthening -- we're telling our new customers they'll be able to run 3 - 5 years before they need to be prepared for a major upgrade...
Is there something wrong with the page numbering of the comments? There is a problem which seems difficult to fix in Drupal.
A case of the cobbler's children?
Cobbler's children, indeed. Haven't had a chance to clean that up yet!
I'm sorry John but my conclusion that Drupal sucks big time.
For example using your own javascript takes a lot of preparatoins other
than just including it.
In 1 of my D6 projects I had to add hierarchial select. To do that I had to make
a lot of coding due to form cache issus.
I use now Codeigniter in my projects, developing is much faster and flexible.
Hi,
Thanks for your comment! We often find that some simple tasks do take a lot longer than expected -- but we also often find that for some really complex tasks, "there's a module for that" and development goes much more quickly than expected.
There are widgets that will do hierarchical selects for you, no Javascript necessary. Yes, cached forms can cause problems with Ajax callbacks -- I'm not a fan of the Drupal patterns for doing Ajax myself, I think they're generally bloated and confusing but adding Javascript to Drupal is not at all difficult. Drupal 7 with its renderable arrays are a big improvement for attaching custom JS behaviors to elements. And Drupal 8 with web services at its core promises to make Ajax a much more first-class experience.
I generally find Drupal to be great for rapidly developing a fully functional, large-scale application. Usability is where you end up spending a lot more time in Drupal, to the point that getting a really polished, usable end result is likely to be similar cost on Drupal compared to a framework like CodeIgniter -- with Drupal you get working but confusing things in very quickly, then spend a lot of time polishing out the rough edges and tracking down strange conflicts. With a framework, you spend a lot more time developing functionality, but you can keep the user interface strong and consistent as you go.
Overall, I stand by my original argument -- the end result is going to depend far more on the developers doing the work than the chosen platform.
Cheers,
John
As this article says, it hates Drupal! But heck we love it! And we highly recommend it. Drupal is not for the faint hearted, and we totally understand you. ;)
Yet another poster who didn't actually read the story ;-)
PHP SUCKS!
(Says the developers who got thrust into a project primarily consisting of PHP--something they likely know nothing about but if they do, then they forget that every language sucks sooner or later.)
DRUPAL SUCKS!
(Says the Wordpress, Joomla, Concrete5, et al people who know nothing about the general architecture of Drupal, it's API, etc., etc. or those who simply forgot how complex CMS platforms can be... It's nice being humbled, right?)
Hi,
after many issues with performance issues (cpu utilization), i started testing with plain setup /standard setup of drupal-7.20, when i tested by browsing the plain website (http://192.168.110.215), in putty using 'TOP' command it's showing (httpd) 30% of cpu usage, and i created 3 concurrent users using jMeter it gong more 90%, if it behave like this, my application will not go live any more.
I appreciate your suggestions and instructions, i have to do for this.
Regards,
K.S. Vedhamsh
I'm been using drupal for years now and compared to what I was at the beginning and what I am now, I can tell you there's a huge difference between an expert drupal developer and a professional PHP programmer who is just gonna start your project with drupal for his first time.
Reasons I always shouting this to friends who want a simple/huge web site are mentioned at this very article/comments.
Your #1 reason is actually every client biggest problem here, means(mentioning drupal long learning curve, how to use API, how to handle and configure your server and...) a drupal beginner developer can burn you to ashes and an expert drupal developer can make you gold real fast.
If you don't want to pay for expensive team don't ever play with drupal, this is the best advice I can tell to customers here.
And about #2-6 reasons, compared to MVC framework and every drupal developer goal which is to build every site capable of everything real QUICK it's a head up. It's a fact of knowing how to use it, you may like or hate it.
And I always see people complaining about modules versions and updates. Not telling this isn't a problem but working with every other CMS or framework you almost need to write a module from scratch. I mean if a drupal module doesn't have what you need, we can always edit and develop it the we want and if you want to develop with Yii you got to develop almost everything from scratch. That's the beauty of drupal, hundreds of developers with thousands of code standard modules.
Drupal is an answer to Wordpress Joomla in terms of speed and simplicity and is worth a look when trying to decide between the two CMS's. What about security ?? Drupal has a good reputation for security. The advantage of Drupal in this scenario is the ability to export the entire Drupal site at anytime so you can load it up on your own Drupal installation should the future ever require it. Drupal runs over a million sites, including WhiteHouse.gov, World Economic Forum, Stanford University, and Examiner.com. Demand for Drupal talent is growing, and opportunities abound for developers, designers and artists, and related disciplines such as database and system administration. There are some very solid technical, organizational and economic reasons why Drupal makes seriously good sense, especially at the enterprise level.
Regards..
Carmen from Drupal Web Services
Thanks for posting!
A few things to clarify:
But you're absolutely right about there being solid reasons to choose Drupal, and that's why we're a Drupal shop...
I appreciate the writeup, but your article would carry a bit more weight if your page counter would actually work.... You should really get that fixed.
That's a really strange comment! But it did spur me to figure out why the pager for the comments was showing 9+ pages of comments, when we're currently on page 2.
And it turns out to be a conflict with the pager in a view block, for the latest news. Fixed... If anyone else runs across this, here's the clue: http://drupal.org/node/1172378#comment-5614982
Let me make a metaphor here...
Drupal is like... Windows.
It's powerful. It's can do many many things. But unless you have an expert, who charge you a lot, you cannot enjoy Drupal.
When people say something bad about Drupal, the general comment of community are: "You don't have an expert" or "You probably do it the wrong way".
WordPress is like Mac.
It can do lots of things, but not as much as Drupal. However, it did its job perfectly, wonderfully, and beautifully.
Never any complains from user of WordPress, no matter he's a beginner, or an expert.
For Drupal, only expert would say good things about Drupal. Beginner always ended up cursing the tools.
==================================================
I have tried to enter the realm of Drupal several times. But for every try, I stop it because I feel something wrong and switch to other.
My technical background is capable of me to learn Drupal very well, I strongly believe. But the system is just... don't quite right.
'm not saying the software architecture. It's perfectly okay. It works very well. It's creator proves it. The community proves it.
But whenever I found myself spending so much time just for learning the very very basic feature of Drupal, I found that my client is not going to maintain it in the future. At least not at a low or reasonable cost. Even creating a listing page of articles requires expert level to do it right and nice. Without knowing the system thoroughly, there must be surprise pop-up someday, which frustrated my clients for many hours, and bring hair loss to the developer who is responsible to fix it. At this point, I believe it's a wrong path, to me and my client.
Yes, Drupal can bring good salary, and pretty secure job to it's developer. Just like Windows certificate owners. They have better pay, better job security. People who "literate" in Windows always encourage their boss and client jump into this.
But, dear Drupal lovers, if I ask you: "Does Drupal make the overall development environment a better place?"
What is your answer?
Hi,
I do joke that Drupal is like Windows in that if there's something that seems wrong, the first thing to do is clear the cache, just like you would reboot Windows. But I think the similarity ends there.
Drupal certainly has a huge amount of complexity, and it's challenging to manage that complexity when you add on a bunch of contributed modules. But it's also gotten drastically better, release after release -- and that complexity is necessary for a lot of sites that would be silly to do in WordPress.
If you're struggling to do simple things in Drupal, I'd say try out the newest version and see if you can do those easy sites now. Drupal 8 promises to add a ton of usability improvements with the new work going into Spark, allowing in-place editing of most of what you see.
The thing is, simple sites has never been the exclusive target of Drupal -- Drupal is designed to tackle challenging sites with lots of moving parts. If you're trying to build an application that does a lot more than a simple brochure site with a blog and news site, you're probably going to find it a lot quicker to get functional in Drupal than you would in Word Press. If your needs are modest, then WordPress is great, and has certainly been a much easier platform to learn how to use.
Linux is a much better analogy. Linux admins get substantially better pay than Windows, and can generally get more actually done because they've had to learn about the underlying architecture of the overall ecosystem, rather than getting certified on a handful of tools.
Drupal, while having plenty of flaws, absolutely makes the web development world a better place. Sure there are cooler tools out there, and I do have developers getting bored with PHP and the loosy goosy nature of the web. But as a rapid development platform, with a huge amount available to you at the start, it's a great choice for developing a complex application.
We find it great for adding features to support e-commerce, CRM, membership management, community management, and much more, areas where you start hitting walls with WordPress pretty quickly and end up bolting on third party solutions that don't integrate well.
Can you please tell me which one is the best in terms of both robustness, functionality and ease of use.
At the time of writing this comment Drupal has, hold unto your hats folks, more than 5200 bugs. That is defining a completely new level of suckiness.
So this isn’t a CMS or framework anymore. It’s a bug farm.
The first online interactive ant farm. Download now, just go oooh and aaah as the error messages pop up on the screen.
New in 2013: The how long untill your server melts prize.
Help now with fixing these bugs. All your work can be thrown away in the next version. This is called a feature.
There is no documentation because the doc team can't keep up.
Where do you even start fixing this mess?
We hope you enjoy working with this software. Come for the software, stay for the community, cause the software no work so good.
Just to provide a solution and not only gripe:
I would seriously, and I mean seriously, considering not using Drupal 7 at the moment. I would wait at least until Drupal version 8 (or 9,10,14,well maybe 20).
As it stands now one can have 'fun' tinkering with the code making it better, but you would have to be absolutely suicidal to use this on a production website.
Although I do have to say those captchas you're using on your website are epic fun.
Well answered. I mean that. I do hope I'll be able to give you some insight that you asked for.
I'm not going to debate every system side by side at this time, because it would take too much of my time. Besides anyone reading this in six months time it would/ could be outdated. When people are looking for a web presence then they should look and compare the available options at that time. There are too many factors to get into in a web comment. I'm sure someone like you can understand that.
According to this http://drupal.org/project/usage/drupal Drupal only has 854,921 users at present (give or take a few) so from those figures I don't see millions of organisations using Drupal. That's actually a good thing for Drupal at this point. The amount of people that 'hate' Drupal (and I mean loathe) is too many.
With systems seperating content from markup there is a lot less hassle to conver to other data displays. That is being addressed in Drupal. Drupal is most definitely behind the curve on mobile. That is also being addressed.
Yes, the web is on the move. Developing constantly. There is a module for that.
People or computers need to be able enter or edit the data, it needs to be stored, and it needs to be displayed.
Nothing more and nothing less.
if your goal is that you can't write bug free software then you will never write bug free software. It's the same with the cop-out all CMS's suck Drupal just sucks less. If Drupal doesn't have the goal to achieve the highest standards that there are, then it should just throw the towel in the ring, because you will always be building crap until you do.
It takes too long sometimes for bugfixes to go through the system. Sometimes up to (or maybe even longer than) 3 years (that's way too long). People in the community are spent? The model isn't working?
Besides a wild west, there is a gold rush going. Everybody and their aunt wants to be the next internet milionair.
That is a tremendous amount of pressure on the community as a whole, to provide for free. We've all met them (not developers, but you know the help vampires wanting a multinational type site in 2 hours for free of course).
The wild west part in open source is that taking Linux as example: it seems there is a new distro everyday. The same with CMS's. I know there are people that would be thrilled if WordPress and Drupal for example merged, and it would just work, no hassle, reasonable fees, and decent customer service. Why does every developer feel the need to roll their own? (We really need to work on our social skills).
Overdevelopment of software is a huge issue. If it works and nobody's complaining: leave it alone.
Look at gnome 2, gnome 3. They recently changed the interface Itunes, I was looking for 10 minutes trying to figure out where the frikking iPod went. Look at Windows 8, there bringing back the old interface (smart move) because sales tanked. In software not all progress is good. Spent less time inventing new features, and more time polishing the product. Drupal should be like a Swiss watch. Period. There is no reason it can't be.
Part of the problem maybe the potential that people see. However writing the code, and making it all jive together, is a whole other story. Maybe PHP isn't the best thing in the world for that.
One could even ponder if there should be such a thing as W3C for the open source CMS world. This in order to have some standards. You shall do it this way and work together, unless you have a very good reason not to.
It is always easier to complain from the sidelines. On the other hand open source is best of breed, and does Drupal have what it takes to cut the mustard? I think Drupal starting to work with other projects in the end is a good thing. Who know, ten years from now, all that is left in the CMS everyone is using is one little snippet of Drupal code, but you know that is fine. Wouldn't you rather have years of fun developing instead of crying out in pain and frustation again.
Open source said we can do it better than Microsoft. When you have the resources, manpower, funding, and support from the community (including companies) to the point where Microsoft is no longer an issue then you better bring it.
Hi,
I'm not sure I see any new insight from your post. We're ultimately a practical, results-oriented shop. We do Drupal because we get practical results every day from it, and it's a huge win from a marketing perspective in that there is a lot of demand for Drupal help. I fully recognize its shortcomings and flaws, and the whole purpose of this post was to set them out along with how we compensate for them.
That's really funny -- on the one hand, you imply that Drupal needs to have a long-term, stable release like Red Hat is for Fedora, something an enterprise might be able to trust and use for the better part of a decade. On the other hand, you're commenting on a 2 year-old blog post and unwilling to identify a single system that actually fills that Red Hat enterprise role. I didn't ask for a broad sweeping comparison across all possible CMSs -- I'm just saying, put up or shut up -- name a CMS or Framework that you think is more worthy of production use than Drupal. I guarantee it will have some drawbacks we can point out, and then actually have a discussion out there.
Our conclusion is, in spite of its many flaws, Drupal is a great fit for the kinds of projects we do, and it's heading in a really exciting direction. While we're currently supplementing Drupal with Dojo Toolkit for data visualization and node.js for more "live" data feeds, Drupal is the cornerstone of nearly all our projects. Believe me, it's a love/hate relationship, there's plenty we don't like about Drupal.
But the real reason I think people hate Drupal has nothing to do with the platform and everything to do with their expectations and process of developing a sophisticated web application -- the worst thing about Drupal is it makes a lot of things look easy, without actually making it easy. It lulls people into thinking big sophisticated complex apps can be put together quickly and easily, but getting across that last 10% of your project is really 90% of the work when you find you can't get there from here. The hate comes because the total cost is way bigger than they expected. That cost isn't necessarily more than it would be on any other platform, when done by an experienced team with proper planning. But it isn't necessarily less either, in spite of how easy it looks to do. You primarily shift the costs from building to testing, debugging, and usability improvements. We still think it's a win, because it is a good platform for incremental development, on an agile basis, with a huge amount of value able to go live very early.
P.p.s.
O.k. the 'cite' marks don't have any quotemark CSS to them. You're quoting by using the blockquote tag from what I can see looking at the source. However blockquote isn't in the list of allowed HTML tags below the comment box.
Could you please add blockquotes around the quotes in the last comment?
To be fair that could happen in any CMS or to anyone. You know there is a handy page with some Drupal themes where you can see all the markup styling, think there may even be a module for that. It can help avoid such mistakes in the future.
Added blockquotes.
All not TRUE! I'm running community site on Drupal 7 with php memory limit 32 MB, using mongodb I have up to 20 db calls per page, 40 milisecond generation time, 8,5 MB php memory. That's no Drupal sucks, just many contributed modules sucks.
1. The problem I have with Drupal is it is a memory hog.
2. Modules are constantly having bugs and not being corrected by maintainers.
3. Webmasters that consider themselves "GODS" take weeks and even months to review code which leads to developers getting frustrated and no longer wanting to maintain their modules. There are some real ego nuts as Webmasters.
4. APIs are time consuming and difficult to learn for the common person. A two-three year learning curve is normal from the community I've seen.
5. The documentation is really messed up. They are trying to sort it out but too much to go through and not user friendly to the newbie.
I have found an alternative and even though nothing is perfect, Django is pretty close.
Django is in python so there is a few days learning curve but it certainly is easier than trying to do HOOK_theme_HOOKER_alter_IFUNDERAFULLMOON_tpl.php crap. Go to Django and see for yourself. Drupal you were like the girlfriend I am happy I didn't marry.
My least favorite part of drupal is the in page editor. Adding content is slow and every time that you save something it slowly saves and redirects you back to the page that you were editing. You then want to tweak something a little more and you have to re-open the editor and repeat the process. There are many things that drupal works well for me for but I wish that it had more of a dashboard like wordpress. The pop-up page overlay seems slow and inefficient to me. I like to have two separate pages open, one on each of my monitors. I can then edit content on one screen, save and refresh on the other without ever having to exit the editor. If there is a setting or a module that could fix this problem for me, please advise.
First, turn off the Overlay module. I can't stand that myself. Then the Edit link will take you to an edit page instead of the overlay, which you can have in another browser tab as you mentioned, to tweak and update as you'd like.
If you use the "edit" link on a page, it will add a "?destination=" tag to the URL, which returns you to the page when you finish editing -- you can remove that link to stay on the editing page. There are other ways to get to the edit page without using that link.
For Drupal 8, there's work being done on a new "Spark" editor, which is more of an in-place editor, much quicker and nicer than the overlay. It's still possible to edit on a separate page and reload.
next...rules
There is Drupal core functionality called 'triggers' and 'actions' and a module called 'rules' that extends this functionality. Using this you can tell Drupal where you want it to go after creating content or just about anything else.
Also, spark is available in some form for Drupal 7.
Coming from a background which involved developing when the only markup was HTML... then through the CSS revolution... I feel much the same about Drupal as I do when I read that first CSS article... CSS rocked and so does CMS. Granted that it should be used on a per case basis, but when the client wants nothing to do with the website other than calling you up to update it, why would a competent Drupal developer choose to base a client's site on anything but Drupal? The functionality can kill the performance of a site, but only if you've bogged the site down with an inordinate number of modules and hooks. Granted, a basic, traditionally coded site can be optimized to run lightning fast with few snags, but a Drupal site based on the same content can run comparatively fast... with the added benefit of limitless potential functionality and dead easy updates.
Take this very site, for example... this very module that is allowing us to have this dynamic interaction. On Drupal, it's a matter of a few clicks and some CSS (if you so choose). Now imagine that this site belongs to your client for whom you hand-built a 6 page special with HTML, CSS and a few scripts. They say, "We changed our mind. We want a blog with commenting, taxonomy and a few related adverts." You now have one of two choices... 1- Programming hell... or 2- reconstruct their site as a CMS.
So long as I plan on retaining my clients, I will base their site on Drupal and give them the option to upgrade and maintain their own site, or hire a competent CMS developer to do it for them.
Gone are the days of trying to match your programming skills to your design skills. CMS gives us options. Options are good.
1. The problem I have with Drupal is it is a memory hog.
2. Modules are constantly having bugs and not being corrected by maintainers.
3. Webmasters that consider themselves "GODS" take weeks and even months to review code which leads to developers getting frustrated and no longer wanting to maintain their modules. There are some real ego nuts as Webmasters.
4. APIs are time consuming and difficult to learn for the common person. A two-three year learning curve is normal from the community I've seen.
5. The documentation is really messed up. They are trying to sort it out but too much to go through and not user friendly to the newbie.
I have found an alternative and even though nothing is perfect, Django is pretty close.
Django is in python so there is a few days learning curve but it certainly is easier than trying to do HOOK_theme_HOOKER_alter_IFUNDERAFULLMOON_tpl.php crap. Go to Django and see for yourself. Drupal you were like the girlfriend I am happy I didn't marry.
I'm late to this conversation but I must agree with the original post. Those truths are still around two years after D7 was released.
I've been developing in Drupal 7 since before it went public (not site building but coding custom modules) and I'm just now feeling confident and comfortable. I can now turn out custom modules rather quickly. I now see the vast scope of projects that can be accomplished, and I have an intimate knowledge of exactly how much work it takes to reach those goals. I recall reading about the Drupal learning curve when I first started, but not actually believing it. Well, I believe it now. Two years later I'm finally able to really use Drupal, rather than the other way around...
Your first point is mistaken. Drupal keeps a registry of which hooks have been implemented by which modules, and this registry is only updated when modules are enabled or disabled. The same is true about hook_menu, module.install, and several other parts of the system. It keeps a registry which is only updated at certain times. Meanwhile, like all modern CMSs, Drupal has a cache system and can use other cache systems. When non-logged-in users are browsing a Drupal site, most of what they see is cached. The developers actually do know what they're doing, and there is a reasonably robust review process in place for anything that might be changed "in core." As of today, July 11, 2013, Drupal 7 is quite viable. Upgrading from Drupal 6 to Drupal 7 can be tricky, especially if there are a lot of custom modules. I've upgraded 2 sites from D6 to D7, and one site from D4 to D6 (by way of D5 first), and indeed sometimes you have to replace a module that's no longer being supported. Fortunately there are many ways to skin most cats, and Drupal 7 has support for all the things we most commonly want to do now. D7 and D8 also include some extra things in the core that required modules in earlier versions.
Hi, Scott,
This article was written in late 2011, when D6 was still widespread. But I still stand behind the point -- all .module files for enabled modules are loaded into memory in every single non-cached request. And many, many hooks do not make use of a registry -- true, hook_menu and many of the theme and module hooks do, but lots of other hooks don't use any registry, and you're still loading all .module files regardless.
I haven't had a chance to debug D8 yet, but my impression is D8 is finally getting it right, with the whole menu router system registered and only the files that need to get loaded getting loaded. No more loading up 100 module files for a simple web service call.
Nothing in my article is saying that Drupal isn't viable -- quite the reverse (is that a triple negative ;-)) I also agree that there are some very knowledgeable, smart, competent Drupal developers -- although many got that way by making mistakes earlier in Drupal's history...
I'm tremendously excited about the future of Drupal -- the key initiatives going into Drupal 8 address pretty much all the things I didn't like about Drupal when we first started using it (and in spite of its shortcomings we have adopted Drupal 100%, promote it heavily, and are completely a Drupal shop).
Gentlemen,
I have very limited technology knowledge.
I have a site which is being developed in Drupal. My developer was developing in the live URL / site directly. (no one knew of our existence so dint face any issues).
I had to change developers midway through the project and when the new developer wanted to develop locally, he had a lot of issues when even trying to host it locally- links not functioning etc..We found around 25,000 instances of the original site URL hardcoded...
So what he did was to find and replace all 25,000 URLs with the local site URL in the database itself.. now everything worked fine.
Once the site was perfect locally we moved to live site again by replacing all URLs back to the live site URL..
**Question 1**
When i checked with my original developer why he had hardcoded - he mentioned that as we wrote a lot of custom code - Drupal automatically created these links. Is this possible?
**Question 2**
I want to know if this will affect performance or have any long term issues?
**Question 3**
After all this mess in the site, is it possible for any new developer to take the code, analyse and understand what we have and optimize the site to perform better?
If it cant be done, my only option is to scrap the website and build from scratch, which i am not too keen on.
About My Site:
It is a simple site with 4 sections (databases). When a anonymous user visits the site, he gets to view a few sample content (chosen by admin) from each section. If he registers he gets to view all the content from each section.
Your responses will be very helpful.
Thanks..!
Hi,
1 -- it's possible that some module the original developer used was set to store absolute links instead of relative. Pathologic module does this, for example -- and can also un-do these types of changes as well, which allows you to work on different copies of the site without changing the underlying links.
2 -- I wouldn't worry about performance in this case. You do need to be able to test it and developers need to be able to work in copies that have links going to local pages, but this can be done.
3 -- It's certainly possible. The question is, is it cost-effective? That's going to depend on how bad a mess it really is. We've rescued a bunch of sites that were put together very horribly. More often, these sites are in older versions of Drupal, and so we do most of the cleanup when moving to a new version of Drupal -- if we're scrapping most of the old work anyway, we might as well move you to the most current version possible.
How we would recommend proceeding varies based on what state your current site is in, what you're trying to accomplish, and what budget you're working with.
The site is working fine at times and at other times it is completely not loading..
from a few expert opinions these are the issues:
1. There are hundreds of modules which one one is sure if is being used or not..
2. Knowing this can this site still be expected to be fixed?
Thanks.
It depends...
Many of our sites have over 100 modules enabled. It's rare for any to have more than 150. Drupal 7 sites usually have fewer modules than Drupal 6, which has fewer than Drupal 5 -- over time we're using fewer more powerful modules and don't need so many single-purpose ones.
What can be done about your site? Totally depends on what the problem is. This is where "Dev-Ops" comes into play, analyzing what is causing the site to not load. Too much memory per connection? Too much memory in use on the server? Bad code? Database corrupt, or missing a necessary index?
There's almost always a solution to these kinds of problems, and there's usually some very low hanging fruit if you're on your own server. If you're on a shared hosting plan, there's a lot less you can do about performance-type issues.
I think you are true. Drupal is the worst cms i have ever met. Terrible planning coding everthing. It sucks. I use a new thing named budapeste
Hi there,
Nice article. I pretty much agree with everything.
In my previous company, we hired 3 Drupal developers, 2 of them were really active in the Drupal community and also contribute to the project. As SGL pointed out, we found at that Drupal devs know nothing about all good practices but procedurale way of coding. We had impression to went back to 90's with those guys (their level on Druapl is really good though).
Anyway, I think that the point is, the right tool for the right job. From my experience, most of projects manager choose to use CMS because they are thinking on the short run. However, if it takes months to build a site, it's life can be count in years.
Using a CMS is good when you only have to implement the template and add some module without any extra big modifications. Once you find out that you need to do lot of changes in order to make it work, the framework will be more appropriate, especially in term of maintainabilty in the futur.
We recently had this problem in my actual company, which BTW, use Drupal for EVERY f**ing THINGS (it is annoying). Anyway, they made a big map base on OpenStree map with a big search engin in order to find places on it. The project took 1 years before get done. Now the client is asking to plug a commercial application on it which need to be 2 ways data binding. The fact that Drupal database architecture sucks a lot, make it really impossible in a maintainable, and proper way to achieve this.
Even with this mistake that they noticed, they still want to rebuild it using again Druapl. I guess we can't teach an old dog new tricks :(
Thanks for your comment!
There's no simple answer here. We still think Drupal is a great platform for just about any web-based system, and a great choice even in the "rebuild it" mode.
Not all Drupal developers are ignorant of OO practices -- many of us came to Drupal after lots of other experience, and had a bit of a shock at the lack of OO. That's changing hugely in D8, though. And even so, it's just a different development pattern to learn the "Drupal" way.
Have you tried doing an API module for the commercial application? We regularly build a module that either consumes a web API or provides one (usually via Services module). Two-way data binding isn't really any harder in Drupal than any other platform -- you still need to work out how to manage conflicts if an item gets updated on both sides, but otherwise, we hook up to other applications pretty routinely.
Cheers,
John
The only reason I like Drupal as it involves a lot of coding and customization. Since I am into PHP for more than a decade, I really love coding. And since Drupal has several modules, everyone of it can be customized, hence I like customizing modules as per the requirement.
Hello there,
It's nice to read an honestly written article about Drupal and not feel like I'm about to embark on an all out flame war in the comments. Just my 2 pennies regarding Drupal performance, I've found that if your server(s) is/are configured properly it doesn't really matter what CMS you use as long as you're using the correct infrastructure and software to support it. Case in point, switching from Apache to Nginx was a great benefit to performance for us as well as (mentioned previously) deploying varnish caches and trimming/tweaking/optimizing the server platform for our needs. I am a faithful Drupal die hard purely because of its power out of the box and find it superb for creating deployable architectures for clients needs, eg Drupal profiles. Tools such as Drush and modules such as Rules, Views, Services etc make the platform far superior in terms of developer cost and time (if the project is worthy of more than a blog) compared to a complete custom system or indeed a simpler CMS. What a lot of the commenters on here do not seem to realise though is that the community on drupal.org is by far the most dedicated and professional compared to others I've experienced, with strict coding standards and (usually) committed maintainers.
thank you to all who have provided input whatever it is, this could be a good learning for me. for sure, there is something not without risk and each person has his own way-self. thank you.
This web is Drupal...
I agree with the comments of the original post, yet I still like Drupal and what it is capable of.
I have worked in Drupal (and many other CMSs and frameworks) for about 7 years now.
With my current project (built in Drupal 6) I have come very close to dropping Drupal all together.
I have converted the core of the site into Drupal 7 via drush, which was a pain in the ass.
I have downloaded and migrated most of the modules, which took hours of trying to figure out what I needed and what the upgrade path for each of them was. Then the bomb dropped...
The Image Extended Fields and File Upload Extended modules were dropped due to the Image API being brought into the Drupal 7 core.
So here I sit with 4500 articles that have an image attached to them that simply will not migrate.
When I do migrate the fields, the images are no longer attached to the nodes they were uploaded to.
I have spent 16 hours trying to find a solution, and, short of delving into a 6 to 7 DB mapping and running a script against the DB (which I doubt would fix the problem) I have no idea how to even start solving the problem.
Yes, it's open source.
Yes, things change.
But now I am stuck at Drupal 6 because two modules that were actively maintained are now dropped.
I guess I am one of those "bad developers" that you are describing because I painted myself into a corner.
Regardless, I appreciate the time you have put into your comments, and the original post.
At this point, I am VERY reluctant to use Drupal on any future projects.
Hi,
I really think Drupal 8 goes very far towards addressing all of my complaints around Drupal. Upgrade pain between major versions is by far the biggest downside to Drupal.
But it gets much, much better with Drupal 8, for two reasons.
Take a look at migrate_d2d (Drupal to Drupal). You can probably use the site upgrade you ran as the new site, set up the proper image relationship to the node, delete the current node content for the type(s) that didn't make it, and set up a d2d migration with a prepareRow method to do the heavy lifting, and bam! you're done...
That is definitely a case of "delving into a 6 to 7 DB mapping and running a script against the DB (which I doubt would fix the problem)", but migrate is a great framework for doing exactly that, and migrate_d2d is smart about Drupal 6, makes it so your starting point is pretty far along. And you can roll your migration back, repeat, update existing, and a bunch of other things that allow you to continue using your D6 site and keep your new D7 site up-to-date, side-by-side, until you're satisfied that D7 is ready.
Why Drupal sucks is because:
- People think it is a DMS (Design Management System), it is hard to explain to 99% of people that a content management system not a magician's hat, a content management system is a platform to manage content how hard is it to understand english, any extra feature is a bonus.
- I am not aware of any platform that you feed it UML diagrams and it will spit you a website
- People think that Drupal is supposed to do most of the work and they only need to pay 1,000$ to some developer to do some minor tweaking.
Hi,
Am I missing something here? I don't see any criticism of Drupal -- it seems you're just criticizing people and their expectations... Seems to me that what you're saying is people suck, not Drupal!
Cheers,
John
The text was written almost three years ago, since then a lot has changed.
"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."
This isn't true at all. This is cached in the 'cache_bootstrap' table, under the "module_implements" key, storing what modules implement which hooks. Add a new hook to a test module and you'll see it isn't picked up until cache is cleared.
As the previous commenter noted, this article was written 3 years ago... Drupal 6 certainly loaded every .module on every call, and Drupal 7, at least the last time I stepped through it in a debugger, did as well unless you were hitting the page cache -- which is bypassed for authenticated users. It might cache the hooks, but at least 3 years ago, it included all .module files during bootstrap, not at hook invocation time.
Drupal 8 looks to address pretty much all of my criticisms, I am very excited to see it coming along!
I couldn't install Drupal (I can't even remember what the problem was). Then I learned about Acquia and downloaded it. I installed Drupal but couldn't even find the Control Panel. So I decided to ask on their support forum and discovered I wasn't allowed to post - even though I registered with the site!
Then someone told me to check out another crutch designed to help people install Drupal, Drupal Pro. I was a bit chagrined to discover that it requires yet ANOTHER crutch - Virtual Box. Guess what? I can't even download Virtual Box for Mac. I kept getting some kind of download error.
So I've pretty much concluded that Drupal must be some kind of joke.
Ha ha! Joke's on you! Nobody really uses Drupal. Those million high profile sites out there are all liars, even the White House! This site, too, is actually powered by gerbils.
If you can't install drupal then you have either had a stroke or don't know how to use a computer.
If drupal is that bad then why you are using drupal as your site ?
Did you read the first paragraph of the post?
yet your site is built with Drupal. FAIL.
Sigh Yet another poster who didn't read the story, or even the comment immediately above this one. FAIL!
A BIG FAIL FOR YOU lol.
USE YOUR EYES, READ FIRST, AND THEN USE YOU BRAIN TO THINK AND FINALLY PULL WORDS FROM YOUR MOUTH.
This original post was in 2011 so I can agree with most, but its 2014 so most of this is not true anymore.
6.) Drupal is a memory hog but most hosting nowadays comes with over 1 gig of memory. Got godaddy it runs drupal for $5 a month. I host my sites on digital ocean with SSD and 4 gigs of ram with 2 cores for $40 a month.
5.) It gets old when people bash on PHP. I forgot we are all suppose to move to python, java, or .NET because all developers follow incredible design patterns and are concerned with whether or not the language is strict or loosely type. I mean my main concern when building a simple microsite was whether or not PHP can understand UTF length or not, or whether my design patterns match up with Liskov Substitution Principle or not. While you are deciding to build in backbone with java rest service and 5 layers of multithreading ill be finished with the site.
4.) Drupal 8 should be on track to fix this, no arguments there
3.) I dont agree with this as basically every site ive built used tride and true modules. If it was abandonned make your own, we are developers right?
2.) Caching is easily dealt with using varnish, APC, nginx. Enough said.
1.) This is easily said about any language, framework, or CMS
Hi, Chad,
Thanks for your comments!
I might write a follow-on, but I really don't have that many complaints about Drupal these days, I'm really excited about where D8 is going. But I don't necessarily agree with your assessments...
It's still a hog ;-) I do think when they get around to it, D8 should be a lot less "hoggy" now that there's full support for classes getting registered and only loaded when actually needed. That and the replaced variable system should be a very good improvement.
I'm not saying anything of the kind -- I did say that I like programming in PHP. The UTF-8 issue crops up to bite you hard, though, and sometimes in very hard-to-troubleshoot ways. We most recently ran into this when importing content from CSV files that did not turn out to be in UTF-8 (while Drupal assumes everything is).
The bigger challenges we have right now with PHP are more around long-running processes with lots of client connections. Things like chat, map updates, collaborative editing -- for these kinds of things we're turning more and more to node.js as a supplement for PHP/Drupal, not a replacement.
Hallelujah! It's about time we got a fully object-oriented architecture that will let us upgrade an object/plugin at a time, rather than having to upgrade everything simultaneously.
With Drupal 7, we've had several uber-modules arise that eliminate the need for a great many one-off modules we depended on in D6 and earlier (which was the context for this article). Rules, for example, is a huge win. Commerce, flag, panels, Media...
Even so, most of the maintenance challenges we find are the lack of consistency when upgrading contrib modules -- things often break, regressions appear, the code quality just is not that high. Yes, we're developers, but if our costs are higher to maintain solid quality, the Drupal ecosystem as a whole potentially suffers compared to the competition. This is an area that will likely always need improvement -- and the same can be said about every other modular system out there.
Yes, but the original point stands -- caching adds complexity, and often leads to difficult-to-troubleshoot issues. Caching is the solution, but it adds its own set of challenges, and costs.
:-)
I wonder if the Drupal certification efforts will end up helping in this regard.
Thanks for commenting!
just googled this...
lookee here: https://wordpress.org/plugins/overwrite-uploads/
nice !! can we do this in drupal without Hacking Core? Not at the moment, it's 2014, it's been a decade... a couple mars rovers have been launched and we have not addressed this...
It's 2014. Disk space is cheap. What are you talking about?
Right now, Drupal does the "safe" thing -- when you upload a file, it assumes you don't want to clobber any other file that might happen to have the same name. And when you download it, it gets the same name as it was originally saved as. Anyone who creates a different page and uploads a different file that happens to have the same name, gets their file back when they request it. What is wrong with that behavior? Who cares if the two files get different names when stored on the disk?
This WP plugin apparently changes the behavior so that if another file gets uploaded with the same name, it clobbers the first one. That might be useful if you are collaborating on a document -- although even then, if you clobber the previous document you've lost that earlier version.
If you really want to replace a file on the filesystem that affects everywhere it is used, you could probably use something like IMCE to upload a replacement.
Otherwise you can train users to use something like Media to attempt to find an existing file first, before uploading a new copy.
To me, an overwrite-uploads setting is an invitation to data loss, something we strive to prevent. In this case I think Drupal does the right thing, and there are options if you really want to do this, but it really encourages you to work out the user stories in much better detail before you go clobbering other people's data.
no properly docs, tones of issues in plugins, old/ugly UI, no methods for often used things. A lot of configurations brings a lot of complexity. Admins/managers users had been happy if they would have seen wordpress instead drupal on business websites/blogs.
But there is no relation to PHP, PHP is old and stable enough, and cheap!
And as for caching... not an argument, just need to be configured properly.
Long time ago we evaluated drupal at a time where it was above all... but still too complex and many companies tried to use drupal in important portal projects... with a lot of pros and cons...
Today we just tested drupal again... deployment was rather easy... plugins and templates with minor issues... but then simple things such as getting rid of a dumb feature like breadcrumbs swalled 2 mandays of work.... till we decided to cut it out like a cancer by reediting templates.
Are Drupal Developers Web Developers? In older Drupal Versiosn Breadcrumbs have been a simple module, you moved it within a block where you wanted them or just disabled then.... this is for me a very current exampel, that drupal has a first super impression and than starts ready to become a pain in the ass for such simple things...
Joomla for example did major transitions and developed a really sound user interface... auto update functionality and so on... but has minor issues which sometimes are also hard to be understood. Joomla has plenty of issues with standart user rights on files, memory issues if it comes to larger files such as images.... Wordpress is pretty cool for blogging.... but it tends to become slow and bulky if it has to run bigger sites... in Terms of community building .... we tried all combinations and plugins - we also tried ELGG which looked promissing at the beginnign but sucked really int erms of data base handling and memory management - it simply became totally slow and needed bare metall boost of CPU and storage to keep a community alife. We are currently evaluating OXWALL for communities which is a peace of cake - easy deployment - fast install of plugins - all templates customizable in seconds .... this baffled me ....
Drupal has still a lot of potential but in Version 8 focus on simplicity ... compelxity is gone in times of mobile devices and responsive design..... a simple breadcrumb - and drupal is dropped - management decission! Why must that be?
For me as a Drupal-user (in the End the Important Thing is to use it), a big surprise arriving on Drupal is the identification of pages (nodes), that is made with their paths...
The better exemple and most common fonctionnality of a website, is to make a link, yes a web-link, an internal link. In Drupal, you have to write the path of the target page by hand (alias or nodeID) !!! Even with some modules like CKEditor Link or others, the link is finally a text-field with this path.
So if you change the path (for exemple because you move a page to another section of the site, or want simply to change it), the links will no more work... !!! That's simply crazy.
Other problem : with CKEditor Link, you can search for the nodes you want to link to (little improvement to the copy-paste of the path). But if you have two nodes with the same title (for exemple in several languages, a very common exemple), you cannot make the difference between them and don't know which one two choose (because the path is not given there)...
I just don't understand why there's not an interface to go through the contents and select it to make the link, so that the link is saved with the nodeID in background, even if you prefer to use the alias for the user. Typo3 is built like this. You can move a page in the structure, rename it, etc. All the links will always be ok.
That's a big luck in Drupal and I'm interested in what you'll answer to that. Cheers, Rad
Hi, Rad,
Try Linkit module, it does what you're looking for: http://drupal.org/project/linkit .
It saves the node id in the link.
Also I recommend using the Redirect module and set up your path aliases so that when an alias is changed, it automatically adds a redirect from the old path to the new.
Cheers,
John
Thanks John, this module seems good. but...
This basic thing should really be in the core. Otherwise the webmaster has to "solve the problem", look for the best module over all the others, etc. To me that's a reason why Drupal sucks. And there's other exemples, one is the management of files, pictures (yes I know there's Media, IMCE, Multi-Upload, etc.).
That's my opinion, but you already gave the point : you need some good specialists to use it... also for some basics like this.
In the end, i have to say, even though I like Drupal very much. So easy to build and manage complexe databases without coding !! :-)))
Yes, that's always been the case -- part of being a competent Drupal developer is knowing what supporting modules out there you need to make a site really functional.
Drupal 8 does seem to drastically change this... we just deployed a test internal site on the new D8 beta, and while it doesn't address the link issue you bring up, we were able to build the entire site, pretty much fully functional with most of what we needed, without using a single contrib module. Drupal 8 core really does seem to be a pretty big game changer, for many things we used to need contrib modules for:
... while there's probably going to be a lot of contrib modules in most of our D8 sites, it's totally possible to build substantially more than a basic web site today in Drupal 8 without contrib.
drupal is flexible but hard to learn. i can do php/modules and can adminsiter a drupal site.
the memory hog is true BUT people tend to use a billion modules on their page so no wonder. i fix my memory problems with using boost as i have no registered users. my hoster supports up to 256 mb memory limit.
i will stay with drupalt and i love its community.
you can use smaller cms or frameworks but then mostly your customers must agree that you need to build a lot of modules yourself what drives the price up up up :)
regards
marco
And Alfresco and SharePoint, and Life-Array, and C#.net whenever I can.
They all suck at some level, except C#, that doesn't suck, or Perl for that matter.
Its good to know what the potential issues are up front. You hit most of them and hit them right on the head!
Nice work.
I have lived through a lot of these issues exploding in my face and when things go wrong, it is a nightmare, and one that you helped make happen.
I like where Drupal 8 is going and if it gets more people interested in CMS and programming, then thats great.
I will share your thoughts with my CMS class at Depaul, I want them to hear the good and the bad about these tools.
It will be nice to have another voice sounds the alarm other than mine.
Thanks
Mike H Chase
Hello John, Nice to read your points. But I could not get aggreed on some points. Its not the point of drupal or technology, even if u chose any technology and and your system is not well configured to solve your problem then problems comes. just imagine Facebook uses your local machine for all its users. I am sure it may get crashed. But if your application is demands you have to config your servers.
My thoughts:
1. Drupal memory (proper configuration solve this, bit analysis required)
2. PHP (Its lightweight, practically checked)
3. version wars (It not new, use any framework)
4. Abandoned Modules (as time changes you improve)
5. caching (very easy, 10 ways available with free tools)
6. Developer (5 technical challenges and you gudge. and I am experienced people need experience and attitude to solve problems)
Drupal sucks because it's not programming.
Before I knew Drupal, I was wondering why the industry only look for "Drupal" developer instead of PHP developer. So if you do Drupal, you do Drupal hooking (or hacking) unless you write some code for the core. The Drupal architecture was originally developed by Russian programmer who created XCart; there was OOD concepts in PHP back then. So he created this hacking mechanism and bootstrap binding. I am not sure how this is related to Drupal but I was surprised when I found out the similarities. But again, it is a unique approach but it's not at all ideal. It is confusing and archaic. I feel that moving to 8 adding Symfony is a good idea but I looked at the core source code and still too many global functions and hacking (I mean hook) functions. So much for adding Symfony components, right? I hope that we will be able to write Drupal by using Symfony object structure so that we become a programmer. But I don't know if that is going to be possible.
Drupal community sucks because there so many non-programmers loading up the stuff on the Drupal community site. It is so messed up, it has become the worst reference website. I have never found a good Drupal resources on the community website. Mostly I get them from other bloggers. Only time I go there is to download some modules.
Read through properly, yes, very very useful!!! I like Drupal l but sometimes I do feel a bit sucks because there are too many different ways to achieve the same solution. Really sucks!!!
Anyone has posted or said bad words to the awesome author, should say apologise and read through properly again lol.
I agree with what you said!
I develop on several CMS platform and drupal is by far the toughest, it's nearly like learning another coding language all together.
The primary problems I have with drupal are:
1) Learning it as I go. There are no books, no real guides on "how-to" with drupal. There are things I can guess or know from experience on other platforms, but there are many things unique to drupal, and they change. Often. And the few guides that ARE out there are already out of date. You sort of just have to "do it" and although I know how to fix what I break and build it out for the future; it's a nightmare if I am in a real time crunch.
2) The updates. On one site I use a distribution and in that case it's obviously inadvisable to individually update each module(I mean, I know I cannnn) so when I write my own commits and patches I always run them through the issue queue of that distribution. This doesn't make for "timely" updates but I still think it's the best practice.
3) Drupal 8. Personally I am dreading the release of Drupal 8 because I have just finished migrating my sites from 6 to 7. And now 8 is here. I realize they are trying to make it better,faster,stronger,etc HOWEVER why not give us a chance to catch up and develop on 7 for a little while?
And someone commented above that the community changed after Drupal 7,and it really did! Many devs don't commit their work that could save a lot of time. I am not complaining about writing fixes but it would be a time-saver if people would take a moment to do that. But I get the feeling a lot of the "developers" you mentioned don't know GIT!
All in all, I don't hate Drupal, but I just can't use it for most of my clients. All clients want these days is wordpress wordpress wordpress..YAWN..at least drupal provides a little bit of variety :)
Why I believe that Drupal is the best Open Source solution to build professional level websites, e-shops or online applications and why you should dig in it and do your own research about it. Here is my points:
1. Standing on the Shoulders of Giants. Your website benefits from the work of many great minds who laid out the foundation, built great modules, and left easy ways for everything to be customized for your needs. Hiring a team of developers of this caliber of can be difficult and expensive.
2. No Lock-In. Your website and data will not be stuck inside a proprietary system that only a few select companies or individuals know. And while Drupal-specific developers are currently in high demand, there is a much bigger pool of PHP developers who can get up to speed on Drupal relatively quickly and assist you with your ongoing support. Also, depending on your needs and comfort level, you can find Drupal expertise in the form of freelancers and all the way up to large companies to help with your Drupal needs.
3. Extensibility. A programming methodology may not seem like a business case argument, but actually Drupal’s extensibility means that it is usually not necessary to rebuild a website when new features need to be added. The modularity and extensibility also facilitates the option of phases during development in order to break down cost into manageable portions.
And much more............
There are many items on the menu...Drupal being one of them, Some diet version, some full fat..All have their own mouths to feed.
Constructing any good recipe is easy, but building a nice cake takes experience. There are many ways to achieve the same thing. Some people just don't like ready meals....(wordpress) or don't have the required skill to bake a masterpiece with Drupal....too much filling.....cache up a bit... its a matter of taste, skill, trend, appetite , size of your belly (server) and size of your pocket.
Infinite solutions leading to the same result. For me I bake with Drupal, still have undercooked or over done every now and then...but as with most well contributed OS stuff....it just gets better and better ...
P.S Last post looks like spam... theres a module for that ....LOL ....honeypot.....Bocha, ....the power of Drupal..LOL
Regards
Alex
I love this post - pure SEO genius. No matter what Drupal problem I am trying to solve and no matter what my Google search is, your blog post always appears in the top 10 search results and is entirely useless to me. This should be the #1 reason why Drupal sucks - that it is so difficult to find relevant information.
Ha! Thanks for that...
What sort of information are you looking for? Perhaps we can help...
Cheers,
John
I have Drupal 7.x installed for our site. I am facing a problem. While creating Content Types, the words "Content Tabs" is being displayed as hard coded letters on the top of every page. Even user with Admin right can't remove it. Surprisingly, I con't see any reference of this problem in any of the drupal forums or youtube videos.
Kindly suggest any resolution on this. Thanks.
You're not finding reference to this problem, because it's not a problem with Drupal. It's a problem with your site, sounds like some debugging code left by your developer that has now become visible.
Maybe, with a more close community of experts, more QA, and premium support from Aquia for enterprices, the drupal core and the way they do the new releases, could be more controled.
By now, the real developers should give a chance to eZpublish http://ez.no/
Is far from easy, but was made for software engineers to software engineers.
After too many years of delays, I'm finally, systematically completing my evaluation of Drupal as a reasonable CMS for certain of my planned websites and as an eventual way to make a little money popping up websites for small businesses. As part of the usual kangarooing on the Web, I ran across this website and this particular post and thread combination. The original post is deeply thoughtful and insightful! The replies vary greatly in quality and legibility, as is to be expected, but John Locke's counter-replies are almost invariably polite, professional and amazingly informative. Frankly, to judge from quickly looking around at other original posts here, this entire website is one of the Web's rare islands of clarity and insight on relevant technical matters.
I know this may seem a little peculiar, but I decided long ago to adopt Drupal and WordPress as the two major publishing tools for my websites with the aim of *first* carefully, meticulously studying and collecting a range of additional modules, plugins, libraries, daemons and themes and *then* in that order finding ways to use them all although obviously not all at once in any specific installation. I won't bore anyone with the headache-inducing methods I employed to evaluate often highly abstract modules from the outside with little understanding of what they meant in the real world. Suffice to say that for Drupal, my small collection of evidently effective, reasonably or even hugely popular and well-supported modules, libraries, daemons and themes seems to be nearing what might be jokingly called a "version 0.98" collection -- ready for the real work of reading hundreds of pages of documentation from scattered web pages and a few selected books and struggling with the inevitable bugginess of actual deployments with widely varying requirements. Some websites will go on a shared Linux hosting account, which means forgoing the delights of Drush, and some will go on a small rented server that necessarily requires rather more setup work as the cost of the flexibility and power of caching reverse proxies like Varnish and search engines like Apache Solr.
BTW, yes, I know that Drupal 8.0.3+ is supposed to be the bee's knees with extra unicorn farts, but decades of reading the news at technical sites has left me with a deep suspicion of extensively rewritten releases of major projects. They invariably take at least twice as long as expected to emerge from a dense fog of critical bugs and lingering, deep annoyances such as missing functionality and poor documentation. The highly popular Drupal 6+ branch seems to have had eight years of security support from its original official release, and given the implications of the cataclysmic changes between Drupal 7+ and Drupal 8+, I fully expect security support for the Drupal 7+ branch to last at least through the end of 2019, nearly full four years from now. The rabid early adopters and the big-budget businesses and the well-funded non-profit organizations are welcome to suffer the outrageous slings and arrows of painstaking development and debugging of core functions and of dozens of the most important contributed modules while we little people watch the show from our legacy Drupal 7+ systems.
I would be interested to understand how your six point relate when the all the sites you manage were maintained within a Drupal 7 multisite environment.
I think it is time to start new branch or distribution called "Drupal framework" or "Drupal for developer", where must be limit of the number of public modules, to leave proper space for developers to develop own system functionality. To "drop the hogs fat" from drupal.
This is a double-sided sword. Drupal is community driven. Without any form of regulation over how poorly modules are written, this leaves a flood gate wide open for bad coding practices to enter into the stream and can create some extremely nasty blowback! Case in point is that a developer creates a module that does cache management and submits that up to the module community. Another dev does that same thing, only his/her module completely trashes any benefit that the other module created. Now, you have a dev at a company or doing a personal site that unwittingly installs both. Usually this happens because an issue has arisen that this latest module "appears" to resolve. But Drupal core...nor the module devs bother providing any provisions that prevent the two modules from stomping each other into oblivion and now you have a Drupal site that is totally acting way worse than the original problem you were seeking to solve.
Until this gets fixed...no changes are going to become the magic hat that spews forth the holy grail.
cuz Larry was assassinated by the Drustapo.
I have been using Drupal 7&8 for past 2.5 to 3 years now, although I agree that some of the points mention by you are valid, but for me Drupal is still the best due to its impenetrable security modules, for these reasons Drupal is known as the most secure CMS, even worlds leading governments prefer Drupal for their official websites, see this blog: https://www.cloudways.com/blog/australian-government-prefer-drupal/
Let's pretend Drupalgeddon 1 and 2 did not happen. Who on earth is able to patch website within 5-7 hours from the time vulnerabillity goes public? I mean, if you developed 1-5 websites you can do it without proper testing. What if your agency developed and maintain 50-150 websites?
drupal is a complete and utter nightmare.
so many buttons, forms, custom clickity-click procedures and shit that should have stayed code...
Drupal still seems wholesome to me though...
The developers have totally run amok.
A more productive use of your time than hating Drupal would be realizing the many different ways that Drupal Hates You More.
https://www.youtube.com/watch?v=L5sHLkA97FE&t=1976s
Stop Writing So Much F***ing Code. Give me a TURNKEY system that accomplishes something with just some standard HTML theming and a bit of tweaking and doesn't change so effing much, look at tiny little unknown project Scout CWIS for example. WordPress sucks in this respect too. Both WP and Drupal are only used to fund professional coders and an professional specialization and job market, not to actually deliver something of value that isn't an eroded pile of sh*t at the end of the day where it's not possible to tell the difference between an easy task or a hard task, ever, because you are swimming in raw sewage.
Today is Feb 2nd, 2019 as I make my comment. WordPress has almost 60% market share now. I don’t think that’s any accident or any less “professional “. I agree with every point the author makes, aside from continuing to use Drupal. And what’s also worth noting is this article was authored back in 2012 but still true today. And now, as of late 2018 Drupal only enjoys a 5.9% market share. As the WordPress user experience continues to improve as it has (and it’s already a pleasure to use), there will be even wider adoption.
It really depends on what you're trying to accomplish with the site. We support several WordPress sites now, and with the changes around making Gutenberg the default editor and deprecating the classic editor, WordPress is heading in the direction of being a layout builder like so many SaaS platforms.
Drupal, meanwhile, remains a much better solution for managing lots of content. Are you trying to build small, graphically beautiful sites, or lots and lots of content (or other data, like products, employee directories, event management, ?) WordPress has solutions for all of these, of course, but as soon as you get away from core page building, you're talking about a much smaller set of sites, and you're starting to get into Drupal's strengths.
Drupal 8 today addresses pretty much all of my original criticisms, so in most ways, I would say this article no longer applies.
But I disagree that WP is going to continue to expand -- we're seeing a trend back to hand-built sites, with heavy front end development in React or Vue, and a move away from sites where you browse from page to page to more fluid, "cinematic" experiences. In many ways both WordPress and Drupal might see some decline -- although making them "headless" and used as a content repository makes a huge amount of sense -- and this is where WordPress's direction might not be as good a way to go...
Disagree all you want. The very message I got in my inbox had all kinds of formatting issues, making it difficult to read. Oh sure, as a developer, you can fix that for sure. But that’s partly my point. Developers love Drupal but the rest of us do not. And yes, WP is indeed taking off and is indeed much more than a blogging platform. And indeed is just fine for managing large amounts of content. And these entities seem to feel the same: https://www.wpbeginner.com/showcase/40-most-notable-big-name-brands-tha…. And finally, I’m having difficulty even posting this message. Your captcha seems to be having problems. WP right out of the box would work feline in this situation too, even if using an old version.
Also, you should view what this message thread looks like on mobile. Very difficult to read.
Everything has its pros & cons, however there are few features which Drupal needed to get fixed like their visual effects, array everywhere, performance along with the memory usage. Also not agree with one of the point which you mentioned for e-commerce as e-commerce industry is growing rapidly.
I think you should consider reviewing your article. ;)
Definition of Drupal: worst piece of code ever written.
@Anonymous
Obviously you have not seen very much code...
Wordpress sucks if you build a large application, wordpress can be used just for blogging, simple website , if you want to build portal that is something more stable, scalabe and strong System, then you should go with Drupal, Wordpress plugin sucks... Drupal modules are free , stablised, reviewed, standard in terms of quality, wordpress plugin breaks in between even the paid plugins are breaks and sucks in between
I often see/hear the same comment "by being an experienced Drupal developer you'll develop websites way faster than using other tools, frameworks and such".
I ask you: At which cost?
I've known people who work with Drupal for over 5 years that still can't develop that fast.
That's for one simple reason: Drupal is HARD. It's hard to learn about many modules, test them, integrate them, have experience from lots of sites using those. Sometimes we even have to "guess" certain modules' behaviors to be able to use them properly, without having to write custom code.
Oh, and when you have no option but to write custom code, you also take ages, IF you wanna learn the right way, and not just be a copy-'n-paste developer. By right way I mean making sure you follow the standards, future proof, write a well-documented code, focus on modularity, reusability, UI/UX, etc.
Drupal 8 came in to facilitate some of the process, but Symfony introducted another level of complexity, which we are forced to learn as well.
It's an occupational hazard, and I can't really believe it's faster to spend several years to only learn Drupal, through the ways the article describes, that is, mistakes, module issues, the community, patches and whatnot, than to quickly learn a stable framework and develop something from scratch.
Not to mention that the current Drupal framework is high-level to an extent of accustoming developers to "easy" coding. They actually become lazy developers, if they were already not ones.
The real challenges Drupal offers are modules integrations, racking one's brains with their/core bugs and having to learn "Drupal-way" abstractions of what should be easy and low-level for developers.
If you can afford an in-house team of engineers to implement Drupal, then why would you torture yourselves by using the Wordpress codebase instead? You wouldn't. OTOH, if you can't afford a team then your site gets sucked in the Wordpress vortex and you inherit a different set of problems, whatever they happen to be, which is different than the problem of the mundane being ridiculously expensive.
No new comments remain in this discussion.
Add new comment