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.
Drupal is an answer to
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!
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
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
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
Drupal is like...
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,
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.
hire php developer india
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
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
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.
... and Word Press had over
... and Word Press had over 3500 bugs a few weeks ago. And Windows regularly releases with tens or hundreds of thousands of bugs. So?
I do think Drupal 8 is poised to be a huge improvement, and really provide some revolutionary new functionality in terms of theming power, configuration management and deployment, usability improvements for editing, and more. But that's probably a year off before it's ready for production -- are you just going to limp along with what you've got now? How much business is that going to cost you? What alternative do you have that's better?
What's your "solution?" I'm not seeing you offering one, in spite of your comment title.
It's easy to throw stones anonymously, with no real alternative.
Drupal is far from perfect, to the point of this blog post -- but it's definitely a viable solution, as proven by many, many organizations large and small who are using it effectively. It may cost more than people like, but what custom solution delivers more value for the dollars spent? It really depends on the problem you're trying to solve, the time you have to get something up and working for your business, and what you need the site to do. With proper planning, Drupal really does fill a sweet spot for organizations that need more than just a simple blog/news/brochure site, and aren't trying to do big data analysis. That describes a huge range of projects!
The solution is not using
The solution is not using Drupal for now.
There are quite a few other options out there. I wouldn't call them limping along, on the contrary. Using Drupal is limping along. Listen, it is not my intention emptily knock Drupal, not my style. Drupal 6 was quite good. Why? Because it had a lot of people developing on it for a long time. It had it's problems, but you could build pretty awesome websites with it. Too much of that was thrown away with Drupal 7. That was a logistical and planning mistake. We all make those, fair enough.
Drupal is so buggy, to the point that it compromises use. For example new in Drupal 7 is the overlay, it hogs resources and slows computers down to a crawl, even powerful computers. Turn it off, and you have the same interface. What's the decision logic behind that? Drupal 7 is full of those kind of weird things. We had to stop using Drupal because we couldn't get projects launched because of all of the bugs. That's bad. Were not dependent on the internet (that's actually a really good thing).
Basically Drupal reinvents itself everytime. Yet most of the time, bugs, and problems are with a new system.
How much time does it take people to relearn the system over and over? Do you think Linux would have been the succes it was if they reinvented it everytime.
Drupal is a bit like Fedora. It's really cool, Linus uses it, but would you use it in production? Not unless you were absolutely mental. You would just buy Red Hat. That is really the message Drupal needs to understand if they want to come of age.
You've stated the negatives.
You've stated the negatives. How about providing a positive choice?
It's easy to tear down a solution, without offering alternatives. If you don't use Drupal anymore, what do you use, and why? People and businesses still have a problem to solve, and they need to pick a technology to solve it. I would argue that Drupal is the worst possible system out there, except for all the others. Name one that's better and why.
The truth is, there are lots of competing systems out there with all kinds of different strengths. We have chosen Drupal as the current best compromise for the kinds of projects we do, in spite of its flaws -- and the original blog post highlighted what we see as its flaws, and how we compensate for them. To say there are alternatives that are better is fine, but where the rubber meets the road is applying them to a specific problem. And the thing is, the answer to "what is the best alternative to Drupal" can only be answered after answering "what problem are you trying to solve?" Show me your better alternative, and tell me why it's better than Drupal, and I'll listen. We can then debate the merits of the two systems side by side, and actually help somebody trying to make a decision.
Your other points do have merit:
Absolutely, there's a question of maturity about Drupal -- but it's not just Drupal. Where's the maturity in web standards? HTML 5 still seems to be under considerable discord even while getting adopted in huge ways. Javascript keeps evolving and changing as we figure out new patterns on what used to be considered a toy language. What platform can you point to that does responsive design, works well for mobile, and has the kind of stability you seem to think is necessary for production?
It is a wild west out there, and the entire environment web applications target is shifting dramatically right now. How can any application be both stable and support the new platforms and devices being rapidly adopted by the world? It's all a matter of compromises, and nobody has it totally right. Name any other platform out there and you can come up with a similar list of shortcomings, flaws, annoyances, and money-pits. The best you can do is analyze the current problem you're trying to solve, the shortcomings of the technology platform you're working with, and create a plan to solve that. Then execute it.
Thank you for shedding more light on the shortcomings of Drupal, it's really a good thing for anyone trying to put together a web solution to fully understand what they are getting into, and ask tough questions. It's equally important for people to realize there is no panacea out there, that all technology platforms have shortcomings. Really what you should strive for is getting the expectations right, and focus on results.
Drupal is succeeding because in spite of its many flaws, a huge number of organizations are getting very good results using Drupal.
Well answered. I mean that. I
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.
Results matter
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.
Hold on to your your horses
Hold on to your your horses there, son. :-) I can understand what you're trying to say, but it's not about that.
Look your trying to prove Drupal is the best, despite it's pitfalls, that's your right.
You're also saying your open for other options. That's very smart.
Yes other systems like SilverStripe, Django, Zend, Cake, Plone, Python, c((+)+)), ExpressionEngine, CodeIgniter, WordPress, ModX, ASP, PHP, Java, etc, etc. all have their positives and negatives.
That doesn't make Drupal any better all of a sudden, or that my argument doesn't hold any weight. Two wrongs don't make a right. Maybe the conclusion could be that the whole web is crap right now. Two piles of crap don't make a diamond either.
So your hell bent on me giving you a comparison, or otherwise negating my comments. Well, I have shown you that is an incorrect way of thinking, but just for funsies let's entertain that thought.
So let's stay with the equal tech for a comparison: Apache server, PHP, MySQL.
We'll also give each team the same basics: skilled workers, good planning and roadmap. Both parties know what they are doing.
Then a roll your own application would far outweigh the headache that Drupal is.
Anyday, all day, all the time.
Drupal.is.a.fricking.mess.
One of the few things Drupal could have had an advantage is with updates. However bugfixes take so long to go through the pipeline sometimes that it negates itself. The bug ques are increasing with hundreds of bugs and not decreasing. Some bugs are holding up other bugs. There are not enough people to fix it, and things are getting behind. The updating procedure can also be a pain. Also trying to customize Drupal can be a pain sometimes, stuck in Drupal enforced ways of thinking (and no that is not always a good thing, by Drupal's own admission)
Trying to break out of that mold to get something done can cost you hours, weeks, or even months of development time: all the while trying to figure out why Drupal does this, and what unholy magic spell is needed to solve it.
Drupal is slower than a custom application, has more code, uses more memory, more depencies not used, harder to customize. way harder to design for. Drupal has weird Javascript interdependencies. Not to mention the absolute mess that the HTML and the CSS are. Module developers can't keep with development. And finally very few people understand Drupal well, like you said yourself, leaving you dangling in the wind if something goes wrong. And with Drupal something will go wrong: it's a question of sooner than later.
Want to expand: write a module, but Drupal language has become so complex and unique that is a time waster compared to just using PHP code all other things being equal. See some of the reasons above.
So, why on earth would you use it then? Conclusion we don't. Not untill it improves.
Time and time again it has been shown that deployment with Drupal costs loads of time and money. Documentation is often poor or incorrect.
What was the upshot of Drupal again? I forgot. Your goals and efforts are noble, yet you still have a while to go before you're there.
If you're using Drupal 6, pray that Drupal 8 will do well, otherwise switch. If it continues down the path of Drupal 7 there is a very good change Drupal will fall into anominity. We made the choice to leave. To tell you the truth, it costs us less money, less headache, and an easier night sleep. It just works.
There are plenty of good platforms and developers out there. To dismiss them as stupid because they don't use Drupal (as often happens) is just silly and plain rude.
@John,
@John,
Here is a good article and comments on what I'm trying to say, that may give you a a better view of the state of things:
http://benbuckman.net/drupal-excessive-complexity
And there any many more similar to this lately. All kinds of people looking to improve Drupal, but also getting worried where Drupal is going.
The other worrying part is who is working on 6, while all this 7 and 8 bonanza is going on?
Let me give you real world working case example:
Linux 101 is not working as root. MySQL gives the ability to assign different rights to users. Drupal claims security to be important, and uses an inordenate time and effort to secure. One of the best efforts in the business maybe even. Then why does it work as root? Why not assign a user with less rights to the front-end.
With a custom solution one can have the web side read only. Handle the comments through e-mail. Write articles offline in a database, and upload those though SSH for example.
O.k. fair enough Drupal chooses another path, and that is fine. It can be useful to login in anywhere in the world to your website and work on it. However look at the amount of code and effort that is needed for that.
With a customs solution, and other products, you can also create a better database structure and interaction.
Would it be easy to do something like that in Drupal if a client wished? No. You're stuck with what Drupal thinks is good for you to a certain extent. So there goes the Drupal as a framework theory (amongst other reasons as well). Luckily Drupal is stepping away from the 'not invented here', and I'm not going to bash a bunch of developers for working on something for years, only to find out later there could be a better way. We've all been there.
However I am claiming the state of Drupal 7 is such that it sucks too much right now to use. In the future maybe yes.
Look if nothing else Drupal was one of the products that led to open source web design. It was like one of the first airplanes. Will it still be around in a few years time? Who knows, it would be sad to see Drupal and the fun it can bring go. Keep in mind the competition on the web is much stiffer now as well. I mean Facebook, Twitter, Google. These are companies with millions if not billions of dollars budgets, and then were not even taking into consideration companies like Microsoft and Apple, and don't forget companies like WordPress either.
Maybe the best thing to do, to a certain extent, would be for Drupal to go back to it's roots, or merge with the rest (and the best) of the open source community. Either way Drupal will have to dig in, and show what it is worth in order to survive in the current market place.
That concludes my comment. Take care. :-)
P.s.
P.s.
The British Breast Care Cancer organisation recently tried to switch to Drupal.
They did an excellent job of keeping track of the progress and coupling back to the community. I think this is something we should all read, and take to heart.
http://www.breastcancercare.org.uk/community/forums/website-feedback/fo…;
http://www.breastcancercare.org.uk/community/forums/website-feedback/de…;
This sums it up:
"Having spent some time trying to fix problems, looking into the issues, and taking into account all the learnings from this current forum we have decided that the forum needs to be completely rebuilt.
It’s not a decision we’ve taken lightly, as in these difficult financial times, any extra expenditure is unwelcome, but because the forum is such a vital and valued service, we know it is the right decision."
"As many of you know, the forum has been a key service for Breast Cancer Care for over a decade, and as such has helped many thousands of people. It is a service we’re very passionate about and we want to get it right this time for everyone on the site today and for in the future. I very much hope you will support us in getting the new forums rebuilt by becoming involved in the user research over the coming weeks. "
http://www.breastcancercare.org.uk/community/fresh-start-forum
Wasn't open source and Drupal
Wasn't open source and Drupal supposed to be there for these kinds of organizations?
I'm sure it was the developers fault, right?
Shouldn't there be some kind of accreditation then for Drupal developers to avoid these kind of messes?
Me thinks, there should. If Drupal is so hard, then someone without a license should not be using it.
It would be great if the Drupal community could take steps to avoid such disasters in the future.
It's not like people haven't been complaining about how much Drupal sucks. There should be steps in place to avoid disasters like this in the future. That money could have been well spent elsewhere.
You're making my points for
You're making my points for me!
Go back and read my original post. What's it called? "Drupal Sucks." And I outlined the very things you're trying to say -- resource hog, lack of planning, abandoned modules, steep learning curve.
I'm not new to this industry. The first time I was paid to write software was in 1984 -- over 25 years ago. My first professional web job was in early 1997, at Microsoft, doing production on content-heavy sites (Music Central and Cinemania, if you remember those, and then microsoft.com itself). For the past 15 years, I've lived and breathed and earned my living on the web -- longer than Drupal has even been around. I've built large custom sites on entirely my code, on frameworks, on Word Press, Joomla, Zen Cart, OS Commerce, Postnuke, Serendipity, Gallery2 and more. I only started doing Drupal sites in 2009.
And the reason we switched to Drupal entirely is that it was the platform we could deliver the most value for our customers, in spite of its (many) flaws. And note one key word in that sentence: "We". Drupal is not right for everyone -- we can make it do our bidding because we are current on knowing its API, we have effective debugging, management, and deployment tools, and most importantly because we plan out our projects knowing the pitfalls and dead ends to avoid. If you don't have that level of experience and expertise with this platform, you're not going to get the same results. That is why I regularly advise people that their development team is far more important than the platform they happen to use -- my recommendation is find a developer you trust, that understands your business and goals, and go with their recommendation on platform.
> There are plenty of good platforms and developers out there. To dismiss them as stupid because they don't use Drupal (as often happens) is just silly and plain rude.
Yes, I agree, and I have never dismissed other developers or platforms as stupid. (Inexperienced, absolutely). However, you appear to be saying Drupal is stupid because of all its problems. I'm just arguing that in the right hands you can get great results, and that's what matters. And in our hands, we can make your budget go a lot further on Drupal than on any other platform. With another developer with different expertise, that platform/value choice may well be different, and that's fine. I'm just illuminating what the real concerns with Drupal are, so we can set appropriate expectations.
> Linux 101 is not working as root. MySQL gives the ability to assign different rights to users. Drupal claims security to be important, and uses an inordenate time and effort to secure. One of the best efforts in the business maybe even. Then why does it work as root? Why not assign a user with less rights to the front-end.
Ok, this statement smacks of complete ignorance of Drupal. Drupal does not "run" as root -- it does not run at all. PHP is what runs, and it runs as whatever user the web server calls it using. We never have that set as root. One benefit of Drupal compared to a bunch of other PHP-based CMSs is that there is never any reason to allow the web server write access to any executable PHP files in Drupal. So we don't. Even if you somehow hack PHP/Apache/Nginx/whatever to upload malicious code to any of our sites, you cannot put them where it can do any damage -- we are very careful to separate user-generated content into non-executable areas. Trying to do this in Word Press or Joomla or Zen Cart -- well, if you do, you lose a lot of the usability features those systems pride themselves for.
If you're referring to Drupal's user 1 account having "superuser" type of access, well, yes that's true -- every Linux box has a root user account as well. Doesn't mean you have to use it, and there's no difficulty setting up additional user accounts with any privileges you want.
> "Having spent some time trying to fix problems, looking into the issues, and taking into account all the learnings from this current forum we have decided that the forum needs to be completely rebuilt.
From that site, there's a frequently asked question: http://www.breastcancercare.org.uk/community/fresh-start-forum/questions-answers#g
> The current forum (indeed the whole website) was built by our team here at Breast Cancer Care at the time, so in theory would have been a very cost effective option but we will now need to bring in more external expertise to ensure that we get it right this time.
That totally lines up with my previous comment: "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 .... The hate comes because the total cost is way bigger than they expected."
The Breast Cancer Care organization built the site themselves, and it looks like they did not spend an adequate amount of time planning or designing the forum to meet the user experience expectation of their forum users.
I'd love to know specifically what underlying issues are forcing them to completely rebuild, rather than their previous strategy of adapting, but this kind of "outrage" happens all the time when you change the way something works without having buy-in from the users.
Forum software in particular is hard to get right, and Drupal's forum is middle-of-the road. I currently regularly participate in a forum that's in a Word Press site using BuddyPress (I think), and it's much worse. That software regularly loses my posts, gives me no ability to see my individual posts, is completely flakey and unusable, loses track of which threads I haven't read -- and yet it's very active in spite of its flaws. People get very attached to forums, and any change at all can easily raise a huge outcry for an established user base.
It really boils down to your goals for the site. If you, as the site owner, want to make it easy for forum users to see other things on your site, things that might lead to a sale, using a forum that's not bolted on to your web site but is an integral part of the same site has some real advantages. Some easy ones to put together include tiers/topics that are restricted to members -- and then by making membership a role you can purchase, you've got one pretty seamless system. Those kinds of integrations are where Drupal shines.
> Wasn't open source and Drupal supposed to be there for these kinds of organizations?
I think you're confused about how open source works. "Don't ask what your country can do for you, ask what you can do for your country!" Open source isn't about preventing people from making mistakes, building crappy software, putting a hole in your head. Open source is about sharing best practices, not dictating them. There is no control over how people use them, and that's a fundamental tenet of open source. It's not there to solve your problems, it's just there for you to use, if you find it useful. It's up to you to make that call.
> Shouldn't there be some kind of accreditation then for Drupal developers to avoid these kind of messes?
> Me thinks, there should. If Drupal is so hard, then someone without a license should not be using it.
By whom? It's not a bad idea by any stretch -- but that's not how open source works. I totally would see a market for a commercial company to create some sort of accreditation for Drupal, and develop a reputation for their certification that people who make it through will do a great job for you. But that's an ancillary service, not something I ever see an "open source" project undertake. See RedHat certifications, for example -- that's the main Linux certification I'm aware of, and Linus has nothing whatsoever to do with it.
> It would be great if the Drupal community could take steps to avoid such disasters in the future.
I think the "disaster" you're referring to is that one organization replaced their forum software without adequately planning how to introduce it to their users, or testing the user experience to make sure it would get accepted at all. That's a really common mistake in IT in general -- if you think that's entirely a Drupal problem, you're exposing your bias, or worse...
And the result is they're having to reach out to professionals to plan and build something that will delight their users. Perhaps if they had done this in the first place instead of trying to do it all themselves in house, they might have had a different result. The cost of development would probably have been similar in either case -- which is more than they spent trying to cut corners and do it themselves.
> It's not like people haven't been complaining about how much Drupal sucks. There should be steps in place to avoid disasters like this in the future. That money could have been well spent elsewhere.
Open source is about freedom, not about control. I think your real criticisms are more about the maturity of the project -- and my counterpoint is I don't see anything open source out there that's more mature or more capable than Drupal. There are certainly good alternatives, but each platform has its strengths and weaknesses, and none stand out as a clear "better" platform in terms of accomplishing the goals and getting results for an organization when you consider time and budget of a properly planned project.
And it really does go back to developers. A great developer can make any platform work for you. A crappy one is not going to get the job done. A huge amount of our business comes from customers who failed to get results from a previous developer -- they hire us and we get the job done. But more importantly is to realize that in the fast-changing web, the job is never really done -- the question is, what's an appropriate budget to devote to a web application to get the desired results for any given time frame, and then how to get the best value out of that budget.
We still find Drupal to provide a better value in terms of getting results than anything else we can offer -- and a big part of why that is so is we've invested a lot in learning how to do it right in Drupal, we are well over the learning curve, we can debug and fix (and regularly provide patches back to Drupal, though some do take way too long to get accepted, such as this one: https://drupal.org/node/1349080#comment-6918298). We've certainly had our challenges along the way, and plenty of code quagmires that take far longer than expected to resolve -- but if we thought we could deliver more value for our customers by switching to a better platform, we'd switch in an instant (as long as it's open source). Just like when we switched to Drupal, when we figured out we could deliver far better value on it than Joomla, ZenCart, WordPress, and the other platforms we used to use.
Linux 101 is not working as
Yes, I can see where we misunderstood each there, I wasn't talking about server root. It runs as MySQL root user. Where in the installation process does it warn or point that you can set the MySQL user to different rights? I'm not aware of any. Note though that this is a common issue with more modern cms's.
I agreed with some of your post, but you lost me at some other points.
What's particaluraly hard about getting forum software getting right? There is plenty of forum software out there. If Drupal's forum is half baked then why have it in there? But this is heading towards a small core or large core discussion.
The definition of open source, well we can metadebate that all day, but one the hand you have people going around saying how great Drupal is, selling it perhaps without scrupples because it can earn them a lot of money, and on the other hand the bitter reality. Your a breath of fresh air in developer air in that concern. Having said that: we don't let people buy tanks at K-mart for a reason either.
Open source, Drupal in this case, has lowered the monetary threshold to have a CMS. This makes the software in broader reach. One of Drupal's main goals was to be a CMS that enabled everyone. However we don't let people drive a car without having a license. Their is a huge marketing hype going concerning open source CMS's such as Drupal, WordPress, and Joomla. However, without a lot of people knowing what they are doing. That is fine if the software runs fine, but too often we see people get in trouble because of this.
There is a tension between what Dries wants and what developers want. Dries wants to build a system anyone can use at a low threshold. On the contrary Drupal has one of the steepest learning curves. Something doesn't mesh there. O.k. you could argue it has a high developer learning curve, but a low user curve. However it's developers that are going: I can't work with this, it's too buggy, it's too poorly documented, it's too slow, it's too complicated.
Listen if your content to work with a CMS that is akin to walking a path lined with quicksand in a desert storm, nobody is stopping you, it's a free world. It's not for us.
You asked me to clarify. I don't see your arguments, exceptions noted, getting any more than 'Drupal is awesome for us'. You acknowledge that it has many pitfalls. Thank you for your honesty in that.
Also I did not argue that there is a lack of commitment in the community, or with you, however merely stated that the current state of Drupal is such that we cannot and won't roll it out because we consider it too high a risk to invest any further into this open source project at this time.
As a potential customer this worries me. Because the money and time I'm investing to build something in your current platform of choice, could be dropped by you tommorrow, leaving you stretched across maintaining multiple systems or having to sell off that part of the service. How do you solve that?
You think or you know? When you make those kinds of statements you better know. ;-)
"Drupal is great!": Yeah, but for who is it great? For a developer like you who still loves to work with it, or for customers? Which brings me back to the start: Drupal is o.k. if you want to tinker, but I wouldn't use it for production.
Hej, but it's been real. Once again it proves Drupal is a money pit, considering the time I'm wasting on this discussion. That's not a gripe towards you, you did a pretty good job having this discussion. But you know what where just tired off having a discussion about how crappy this product is. We do have better things to do, like work with better working products.
We both agree that Drupal has certain problems. We've decided not to work with it for the moment, you've decided to. I think we have exhausted this discussion between us pretty much. I want to thank you for your time.
People that would say: why, don't you help improve. At this point where would you even start? We're watching this one from the sidelines folks. We do have to put a roof over our heads.
Yes, I can see where we
> Yes, I can see where we misunderstood each there, I wasn't talking about server root. It runs as MySQL root user. Where in the installation process does it warn or point that you can set the MySQL user to different rights? I'm not aware of any. Note though that this is a common issue with more modern cms's.
Really??? I have never, ever set up a Drupal site to use the MySQL root account, nor even considered doing so -- and I've only seen one or two installations out of hundreds that even did such a thing. This is not at all standard practice, and if you bothered to read the INSTALL.mysql.txt file, you'd find instructions to create a user and database, and nothing suggesting you should ever run as root.
> What's particaluraly hard about getting forum software getting right? There is plenty of forum software out there. If Drupal's forum is half baked then why have it in there? But this is heading towards a small core or large core discussion.
Nothing in particular is hard about doing forums. What's hard is changing user expectations about how they work, and even small changes can lead to immense hate, regardless of the nature of the change. There's nothing wrong with Drupal forum software -- it just doesn't necessarily have all of the features out of the box that other more specialized software like vBulletin or phpBB has. There are plenty of other modules you can add to get the features you want in a forum -- the main thing we find takes extra time with forums is getting the theming right, especially for threaded forums.
> As a potential customer this worries me. Because the money and time I'm investing to build something in your current platform of choice, could be dropped by you tommorrow, leaving you stretched across maintaining multiple systems or having to sell off that part of the service. How do you solve that?
This is a risk with any software platform -- how long can you get support for it? And Drupal actually makes it worse in that the major versions are pretty much different platforms. There's a couple different upgrade paths, but upgrades are far from trivial.
The good news with Drupal is that there are thousands of other development shops that can take over were we to do such a thing -- and this makes it possible to fire us pretty easily if we're not doing a good job for you. Avoiding vendor lock-in is one of the main benefits of using open source, and while we've seen plenty of screwed up Drupal sites that are expensive to fix, at least there is some common ground and general practices that generally makes the sites salvageable at worst. With custom code, it all boils down to the developer doing the work, how well organized they are, how well they document the code, how much they adhere to standard practices, etc. With Drupal, it turns out the same thing is true! It's just that there are a ton of wannabe developers out there with no clue.
> We both agree that Drupal has certain problems. We've decided not to work with it for the moment, you've decided to. I think we have exhausted this discussion between us pretty much. I want to thank you for your time.
Agreed! Thanks for the time you've spent having this discussion. I'm not sure why you've decided to stay anonymous throughout -- it seems like if you provided some contact details, you might get some business out of it!
The bottom line is, if you're talking to customers and not developers, customers don't care about the things developers care about. All they care about are results and cost -- the basic factors that represent value. We're not building tanks here, we're making web applications on the bleeding edge of web technology, and sometimes there is indeed blood. Drupal is as viable a platform as anything else out there, but the quality and discipline of your developers makes a far bigger difference than platform choice.
How about discussing that? Here's a starting point, a series of articles I wrote about code quality long before I ever touched Drupal: http://www.freelock.com/features/quality-code-how-do-you-judge
Just a quick comment. First
Just a quick comment. First off my apologies I had a short amount of sleep last night, and my last comment may have suffered for it.
1. INSTALL.MySQL.txt: will you look at that. Thanx for pointing that out. Never noticed that file before. The question is whether or not this is obvious enough. For example web installers with web hosting companies aut install. (I have done plenty of manual installs). Having said that granting these permissions "GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER" is pretty powerful, and "Unless your database user has all of the privileges listed above, you will not be able to run Drupal", boils down to the same thing I said. So one is still not able to set the front end to read only should you wish to, which was the case I made in the work case.
2. The reason from what I gather the Breast Cancer Care forum stopped was because the fixes for the problems they were running into were getting to costly. As well as some of the problems being hard to fix(?) (Which is a problem more people run into) Which ties into what you say about Drupal being easy to start, but then later on can become expensive. However, where would you read about this? Should there be a warning notice somewhere? From a customer relations standpoint it comes down expectation management. Unless I'm wrong Breast Cancer Care will probably not very likely be a customer of Drupal any time soon. I come across quite a few people that feel that way. Your talking to one. In terms of customers management and if Drupal wants to win in the long run, then it will have to have a succesful customer relations and customer binding. We may see it as open source, and scratch your own itch, but most outside people still see it as a product.
3. An experienced PHP developer should be able to read the documentation/ code in Drupal and manage to find his/ her way around. I mean look at us while we have been talking we have both learned things about Drupal. At the moment experienced (core) developers even have trouble sometimes figuring it out. However work on this is being done from what I understand. Conclusion could be that Drupal grew and just needs a good spring cleaning. As well perhaps more user testing from a developers stand point when it comes to install and technical stuff.
I'm not looking to make money from this discussion. Wouldn't consider that fair to you either, one developer to another. Open Source and Drupal have been good to me, and have helped me in business. Just see it as contributing back. Trying to sort out a solution to the problems. I'll think about it, right now Drupal is too much headache.
Do you have RSS feed for comments or some other way to stay up to date? It would make it easier following the discussion.
You write good articles, and definitely have a way of explaning things very well. You can count on me reading your blog on the future, and can definitely recommend it to other people.
P.s.
P.s.
1. "So one is still not able to set the front end to read only should you wish to"
Should be: set application permission access to the database as one wishes to.
You could technically have a static front end in HTML or such and use Drupal as backend.
P.p.s.
P.p.s.
Another correction. You were right in pointing out that I shouldn't say MySQL root user. Most webhosting companies won't allow you to run MySQL database as root either. One of the few times this could be the case if you install MySQL yourself for example in a development environment. I meant the user permissions, and accidentally got this confused with user naming. Thank you for pointing out the error.
Your comparing PHP/CakePHP
Your comparing PHP/CakePHP/Java/etc vs Drupal and that's not even legal. You compare Drupal with Joomla ,wordpress, or what have you. You compare Drupal against other frameworks not other language.
Drupal does not assume what kind of application you are building. And that's the key point difference with other CMS. In fact, hate to label Drupal as a CMS because it is really not just a CMS. It's a framework for developers. A platform to build something and anything. And yes, you may complain that it is slow and but I ultimately disagree it is a MESS. And while it is a platform for developers it is not for anyone who does not want to learn the basics and then complain up-front because it does not satisfy their wants.
Drupal is maintained very well. From Drupal 5 til 8 in a few years time - that is something you cannot refute. And isn't that a proof that undeniably people and developers are loving how and what Drupal is as a framework or platform?
Drupal community is huge. You get answers to your Drupal questions almost immediately. Give me an example of a community site and support like this.
Drupal Module contrib repo - There are module mainteners. You cannot get duplicate modules developed for the same fucntionality.
Hundreds if not thousands of reputable websites including the US whitehouse have chosen drupal because of it's secured framework.
I don't know where your hate is coming from but again, Drupal is not perfect. So goes with other frameworks out there. I'm not saying Drupal is the best but Drupal stay on and continue developing for imporovements. Learn to appreciate other frameworks as well but don't hate because after all knowledge is your power.
P.p.s.
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.
Added blockquotes.
All not TRUE! I'm running
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.
Drupal is a mem hog.
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
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
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.
Awesome, thanks! I always
Awesome, thanks! I always figured there was something that could be done but just kind of dealt with it until I saw this post.
next..rules
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.
Drupal Rocks(period)
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.
Drupal or Django? Leaving Drupal and why?
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.
Two Years Later....
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...
Drupal hooks
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,
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).
A true testament to Drupal's capabilities
www.scmp.com all driven off Drupal 7, one of the largest Media portals in Asia.
Suggestions needed
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,
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.
Added Issues
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...
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.
drupal
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
The context is important
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!
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
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.
Nice article and interesting comments
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.
there is nothing without risk
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...
This web is Drupal...
Add new comment