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.
I am close to leaving drupal behind...
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,
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:
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,
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
The text was written almost three years ago, since then a lot has changed.
"This power comes at a cost -
"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
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 can't even install Drupal!
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
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
If you can't install drupal then you have either had a stroke or don't know how to use a computer.
So why you used Drupal ?
If drupal is that bad then why you are using drupal as your site ?
Did you read the first
Did you read the first paragraph of the post?
Missed the first paragraph
Yes, I missed the first paragraph.
Actually the power of Drupal comes with a cost,you mentioned it properly but every point you mentioned have it's solution too.
6. Drupal is a total memory hog : Yes it is if you install APC in your server it will fill up 512 MB very quick but you have to also consider that it servers 15000 request in just 1.76 second.
5. It's PHP: I am not going to argue about this point.
4. Version wars: This problem should be solve with 8,I guess !! we have to wait and see how their claim of 6 & 7 to 8 migration will work.
3. Abandoned modules: Being a part of open source community,we have to understand people need to move on when money matter and they should have full freedom to chose from money vs passion.
2. Caching: well memchache is pretty easy to start with ,also some database engine trick will boost performance by 20-30%,then we can go for more complex thing like varnish if properly handle it can justify the word "Move like a butterfly,sting like a bee ".
1. "Drupal Developers": Simple look at there drupal.org profile and check what they have to offer.
yet your site is built with
yet your site is built with Drupal. FAIL.
Sigh Yet another poster who
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.
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
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,
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!
I always love returning to this post.
And while I have no opinion on Drupal 8 yet since what I suspect to be the majority of users don't have the $ to influence D8, I'm not holding my breath - but I'm not too pessimistic, either. Time will tell, though I am quite wary of Drupalers Drupaling to just Drupal and justifying Drupal as awesome because of their implicit ownership in the process of Drupal. It's late. That should make sense.
It boils down to how much work bringing D7 sites to D8 will be, just like every other major version change that was in your original post.
The real issue, though, isn't Drupal. It's what Douglas Adams said so well. "They keep giving us technology when what we really need is stuff that works." Having paid the bills fixing the work of others over the last decade, I love that Drupal lets so many people shoot themselves in the foot. I simply wish that had bigger budgets after they got ripped off.
drupal sucks *ss
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
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.
It really does, yep.
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.
Drupal
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?
Writing Pages, making internal links, identify Nodes
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,
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
ok, but...
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
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
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
I agree, and I use it anyway, and WordPress and Joomla, and Modx
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
any system requires this..
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)
Indeed..
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.
Nice Nice :) Thanks so much
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.
drupal is tough
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 :)
Drupal is really effective...
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............
I love to bake Drupal...
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
Love it
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...
Ha! Thanks for that...
What sort of information are you looking for? Perhaps we can help...
Cheers,
John
there are some issued with drupal
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
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.
Lets take the business to a profesional level
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.
Fascinating Post and Subsequent Thread
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.
Multisite
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.
It's time to fork branch (distribution?) of drupal
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.
Community modules will be the downfall of 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
cuz Larry was assassinated by the Drustapo.
Drupal doesn't suck anymore
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…
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?
Who on earth is able to…
@yoman, well, we did...
For both Drupalgeddon 2 and 3, we rolled out the patch to over 60 websites within 4 - 5 hours of the public availability, with a complete backup done of each site.
If your agency can't do this, put them in touch with us! We can either handle this for you, or set up you up with a proper DevOps system that can do it.
drupal is a complete and…
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…
Drupal still seems wholesome to me though...
Add new comment