12 ms·

Drupal's Golden Handcuffs

187 points by mcrittenden 14y ago

WiseWeasel 14y ago
I'm using Drupal as a back-end, and doing the fun stuff in the front-end on the client. No boring days here.
tedsuo 14y ago
I would add this to the complaints: - NOT AMENABLE TO SOURCE CONTROL Half the code lives in the database, configuration is all mixed up with content, and there's no reliable programmatic way to extract it. It makes doing deployment a nightmare. And the worst part? Drupal developers by and large have such a narrow range of experience that they don't even know what they are missing. They have no idea what good coding standards look like, a lot of them don't even have a development/production separation: they just hack away on the live site with no source control or backup. And no one writes tests, or sees why they would be useful. Some of the big professional drupal shops appear to have basically written their own cms on top of drupal, with a bunch of terrible hacks to try to make source control kind of work, and just use the drupal name basically as a marketing technique. So glad I don't have to deal with any of that insanity any more.
- oinksoft 14y ago
  This is the main reason I chucked my Drupal 'cuffs in 2008, no longer taking on new Drupal projects and helping my clients move over to other Drupal service providers: It was very, very difficult to scale up my business because bringing on extra developers, and having consistent local/dev/staging/production environments was at least an order of magnitude more difficult that it would be with other tools. In Drupal 6, the only way to reproduce an environment was with a massive install profile for the project, and the average Drupal developer was entirely clueless to matters of testing and version control when compared to the average Django/Rails/CakePHP developer. This made for many painful projects and unhappy clients, usually beginning 6-8 weeks into the project when the issues of database drift became inevitable. And like you said, everything lives in the database. So the chances that some production issue (or new issue only seen in dev) was caused by an errant user action in the Drupal UI was pretty high, and this made debugging a nightmare -- where is my issue really coming from? I'd just about forgotten about my Drupal days of yore, and between the "click monkey" analogy and the "clear the cache" nostalgia, the author sure conjured up some bad memories!
- jackbravo 14y ago
  This is why http://drupal.org/project/features http://drupal.org/project/features module was born. To allow you to export your functionality to code and have it under version control. Features and things like http://drupal.org/project/drush_make http://drupal.org/project/drush_make is what makes a lot of the drupal distributions (http://drupal.org/project/distributions http://drupal.org/project/distributions) that keep popping up because sourced controlled, feature driven development is now possible in drupal. Also the testing part has been improving, and although very few of the contrib modules have tests most of core has automatic testing in place for when you submit a patch as you can see in the issue queues (http://drupal.org/node/466576 http://drupal.org/node/466576).
  - w4y2 14y ago
    Features is good as a concept, but in implementation it fails considerably. Here are a few issues: - How to deprecate a feature (I created http://drupal.org/node/1400346 http://drupal.org/node/1400346 to attempt to solve this, but admitedly, it's a very dangerous module) - Ever created a feature with tons of things in it? Hello, 5 minute load times for admin pages! - How do you merge two features together? How do you commit just one feature and not another (say, one you're still working on?) The CMI initiative will hopefully take care of a lot of the messiness and bugs in Features.
    - vaporstun 14y ago
      The other downside of Features in Drupal is that if we export something as a Feature (say a View) and then our site builders tweak and change that View for our clients and then we update some core element of that View and re-export the Feature, that re-export will overwrite any custom changes that were made to that View, thereby trashing any of the custom changes. This is a real problem with Features to which I'm surprised there has not yet been a good solution.
      - jackbravo 14y ago
        Same problem as other frameworks. You need to know the rules. If you use rails, and the designer changes the CSS without committing the change to git, then next code push will erase his change.
- emmelaich 14y ago
  > [ ..in the database ..] Similar comments for Moodle, another popular PHP app. You cannot even change the url for your site without rewriting content in the database.
  - smacktoward 14y ago
    WordPress too. In fact in WordPress the site root URL is stored in two separate configuration fields, so woe betide you if you rewrite one field and not the other. Thankfully the WP core devs seem to have been slowly cleaning stuff like this up over the last couple years. So even though this wart persists, I have hope it'll eventually get zapped.
    - jasey 14y ago
      In my wp-config.php file I have the following logic https://gist.github.com/3831423 https://gist.github.com/3831423
- hippich 14y ago
  On one hand there is Features modules and tons of modules built on top of it. On the other hand - if this problem could be solved - Drupal become holy grail, which should not exist! :)
- knieveltech 14y ago
  I work for a company that provides site implementation, custom feature coding and ongoing support for ~30 enterprise websites and all of them have this in common: 100% of the source code for each site is in revision control (SVN or Git, depending on client preferences). If you want to complain about Drupal be my guest. The ground's very fertile, but what you've posted here is FUD. Code in the database? No, just no. While it is technically possible to stuff code into the database community best practices (not to mention common sense) strongly advise against this practice. What you are describing is the system handing you enough rope to hang yourself, not it's default behavior. Configuration lives in configuration tables. Content lives in content tables. "they just hack away on the live site with no source control or backup" It would be a mistake to take the fumblings of a few scrub freelancers or interns and extrapolate that as being the norm for all (or even most) Drupal developers. For all core modules and all quality* contrib modules there are $N_load() functions to extract these (reliably) from the database. * With ~8000 contributed modules to choose from, quality varies wildly. While unfortunate, it's to be expected when you've got that many chefs in the kitchen.
  - apendleton 14y ago
    This is quibbling over semantics. Drupal's custom content types, custom fields, and Views all allow developers to express complex logic that would, in any other development environment, be expressed as code and committed to version control -- creating a new content type in Drupal and adding fields to it is exactly analogous to creating a new model in Django. You can call it "configuration" if that makes it easier to justify its being in a table, but it doesn't change the fact that Drupal developers spend lots of time building shit that can't go in a VCS, can't be easily tested, can't be branched/merged, and can't be easily deployed without a convoluted export/import dance. Just because there isn't literal code in the database, it doesn't mean there's a clean logic/content separation.
    - fauigerzigerk 14y ago
      Not that I know much about Drupal, but isn't it inevitable that stuff that can be changed via the UI (sometimes even per user) has to live in the database? This is simply a consequence of blurring the lines between developers and users, which is exactly the point of CMSs. Actually, I think what we should be asking is this: Do CMS databases and VCS really have to be two completely seperate universes? I would say no. There is room for a new type of CMS database design that includes all the functions of a VCS.
- lotyrin 14y ago
  I work on big Drupal sites and this simply is not true. Drupal lets you get a ton of shit accomplished without making you understand a single line of code, have a reasonable Dev-Stage-Prod workflow, QA, even version control or backups, etc., but it's completely possible to do all of that. That means that it can scale from anywhere from something like a 16 year-old's shared-host fanfiction site to say Whitehouse.gov. Of course that means that there will be tons of fuckups live-coding (or live-configuring) on production, or people that don't export and version things in environments when they should, and that people will construct fragile combinations of modules and configuration where a tiny bit of code would have sufficed, or write tons of fragile custom code with no tests or security review when there was already a module for that. But allowing people to be fuckups doesn't force them to be, and they can be trained.
  - mtts 14y ago
    "That means that it can scale from anywhere from something like a 16 year-old's shared-host fanfiction site to say Whitehouse.gov." Scaling to Whitehouse.gov is not impressive at all. Like a 16 year-old's shared-host fanfiction site whitehouse.gov really is nothing more than a content site, albeit a very large one. The problem is Drupal isn't content to simply be a CMS. It has to pretend to be a framework for developing web apps as well, and for that it's just plain terrible.
    - lotyrin 14y ago
      If you compare it to a framework it loses, obviously. It's massive and complicated. And while PHP's is trying hard to modernize, the tools and ecosystem still don't compare to Ruby or Python (see below). Drupal is only for when what it (or modules) can provide is a vast majority of the requirements of the project. Anything that couldn't be described as "nothing more than a content site" probably would not be a good fit. The only thing it has to offer is when what you need is one of the myriad things it can be configured to be, because then you get a bunch of community eyes and tests on a bunch of code you didn't have to write. Edit: Discussion on recent improvements to PHP's and its ecosystem (which are exciting progress in a direction I believe there is more room to go) http://news.ycombinator.com/item?id=4605715 http://news.ycombinator.com/item?id=4605715
- modarts 14y ago
  Wow. This sounds exactly like a complaint that would be lobbed against SharePoint (rightfully so, it's a special kind of hellish nightmare for people responsible for developing on it.)
- mmcnickle 14y ago
  Such is the inner platform effect. I would happily bet there is someone working on a drupal-specific, poor substitute for version control.
  - lotyrin 14y ago
    Nope. They're busting the inner platform and having config live in the filesystem to get versioned like anything else. Good luck with those prejudices, though.
    - mmcnickle 14y ago
      Does it address config drift in production where users make changes that aren't reflected in the versioned codebase? The question is not intended as a retort, I'm interested in the answer. The prejudices I have against Drupal are the result of my experience of it starting as far back as version 4. I don't believe they are unfounded.
      - TylerE 14y ago
        You're not wrong at all. I'm currently investing moving our sites (a network with 1M+ visits/and 12M+ pageviews) from Drupal 6 to Rails. We have a large amount of custom code (I've written 20+ modules for this platform), and yet we've gotten to a point where we really want Drupal (and PHP) out of our lives, because it isn't worth the headaches anymore.
- ZoFreX 14y ago
  Absolutely not true. When I was working with Drupal 6, CCK and Views 2, I would use the GUI to try out new content types and views, but I would then export their definitions and put the code for them into a custom module, which was under version control. When I first started out I actually wasn't using CCK or Views 2, I was creating new node types with a custom module, and if I were to go back to Drupal now I would be sorely tempted to do this again. Views was a bit too fragile and the queries it generated were horrific, and I think if you can code and know PHP and MySQL well they really give you very little value, or possibly even work out slower overall.
- Daniel_b 14y ago
  I completely disagree with your views about Drupal development. We've recently migrated bmj.com (a big site with gets 1.6 million visitors and 6.8 million page views a month) from old Java Servlet based platform to Drupal. We've used continuous development process where up to 4 developers were working on the same code base in dev, staging/testing and prod environments. It is now a standard Drupal development practice to export all configuration data to the source code. BMJ.com is not a simple site, it has an article page with quite complex data structure with up to 60 meta data elements (author details, publication date, vol/issue number, section, series, category, taxonomy, relations to other articles, open access flag, etc...) being rendered at the relevant blocks. The business and editorial departments have been happy with the new opportunities Drupal is offering them. For more detail, please access Drupal success case study: http://drupal.org/node/1557636 http://drupal.org/node/1557636
  - berkes 14y ago
    > from old Java Servlet based platform to Drupal. This does not say much about Drupal being good in absolute terms. It only tells us the obvious point that Drupal is a lot better then your old application. What you state would have been just as trough had you developed in Rails, Django, and maybe even in PHPnuke. What you don't state, is why Drupal was the better fit compared to modern alternatives. Is it?
- dougvann 14y ago
  Right you are @tedsuo There are many ppl not writing tests and not using staging and best deployment practices. This is true in every CMS and WCF. I don't believe it it any more prevalent in Drupal than anywhere else. Drupal invites a lot of BEGINNER types to the arena of web solutions. As such you will certainly find the things you mention. I don't agree with your suspicion that big shops are hacking core and building custom CMSs upon Drupal in a vain effort to try and gain source control features. Rather... I'm aware of big shops sticking to Drupal bets practices and using Features, Strongarm, Plumber and other modules to get configuration into code and keep it source controlled. If Drupal deployment were the nightmare you s=describe, then the phenomenal adoption of Drupal that we see today would make no sense. Why would the Georgia Tech Authority decide to move SIXTY-FIVE sites off of a Oracle, Java, Vignette solution and onto Drupal? Well.. It is isn't because they like nightmares during deployment. Drupal is growing up. The issues that plagued us 5 years ago when I got involved are being solved with varying degrees of success and effort. We're not where we want to be but the market is eating us up. We are bullish about our future and know that out continued improvement will only serve to better our position as the leader that we are in the web space. Doug Vann [Drupal Trainer, Consultant, Developer] http://dougvann.com http://dougvann.com
graeme 14y ago
I don't have this problem, currently. But I've previously used boring, lucrative work to bootstrap my way into more interesting work. Here are the steps: 1. Identify what you would rather do 2. Keep doing boring work, but part time 3. Reduce expenses 4. Use money from boring work to subsidize skill development in interesting area 5. Switch to interesting area Obviously, this only works in fields where you can get away with ~4 per day spent on your main work.
jack-r-abbit 14y ago
uh... I have never had a day when I said "I'm Bored" like that. What you describe as all the Productivity stuff that can be done with zero coding isn't really all that Drupal developers do. At least not where I work. We are writing custom code/modules on a daily basis... not just "every now and then". But I guess it comes down to the type of site you're building. But I have had my fair share of "WTF?" and "Damn it, Drupal!" moments. That much is true.
stevepurkiss 14y ago
Interesting article, perhaps if a few of those "I'm bored"s were changed to "I'm helping make Drupal suck less by writing some documentation" or "I'm learning cool new stuff cos Drupal does the generic boring stuff for me" the author would have a more fulfilling life. If everyone blows a little more energy back into the Drupal project, it'll suck a lot less ;)
- jackbravo 14y ago
  I agree 100%. That makes it a lot less boring because you feel you are doing something useful not only for yourself. That's also why Drupal has huge amounts of contributed modules and developers. Lots of people who do just that. Drupal is the Linux of the CMSs.
- mcrittenden 14y ago
  It depends on your work environment. If your boss asks for 40 billable hours a week and you have a family to keep you busy in off hours then there's not much time for writing docs or contributing modules.
  - jackbravo 14y ago
    Is the same problem that every person working with free software projects faces. Can I contribute more if I'm not being paid to do it? In the long run you can expect those extra hours contributing to the project to really pay off, because you gain a deeper understanding of where things go, because you meet people that can help you, because people see your contributions and you make connections and a lot of other goodies.
- Angelo8000 14y ago
  I agree - Perhaps some more active contribution rather than just the usual "I'm bored", etc. Why not be more proactive. Good point.
patrickdavey 14y ago
I have just left my Drupal job for a Rails job, pretty much for the reasons listed here... I'm certainly going to be making _more_ money doing it too. I reckon 40 hours a week (or whatever you work) is far too many to be doing something that leaves you bored or frustrated for a reasonable percentage of the time.
lkrubner 14y ago
I am puzzled by this: "Good Drupal developers are making a lot of money right now, much more than I'm seeing for Django or Rails or Node devs in general." I am curious where this is? This is not true in New York City, where I am. Developers who are good with a given PHP framework (Drupal, Symfony, etc) will make something like $60 to $70 an hour. The top Rails devs will make at least the same amount, and usually a little more than that.
- enobrev 14y ago
  I know developers (including myself on a rare occasion - i tend towards custom development) who are doing far better than $70/hour for Drupal development in NYC. Although I don't know many successful developers who explicitly sell themselves as "[Framework] Developers". More often than not, when shooting for a higher rate, it seems to sell better as someone who provides a full solution, which May include specific frameworks if necessary.
- dasil003 14y ago
  This doesn't make sense to me either, though I haven't touched Drupal for at least 6 years. In my experience, Drupal is ideal for cheap clients who want a zillion features but don't have the budget. You can deliver more functionality in Drupal than anything else, that is absolutely true. For high-end clients who are willing to pay for impeccable UX and solid problem-solving, I can rarely recommend Drupal because it starts with a raft of assumptions that tend to lead to subtle compromises in the UX but would require an inordinate amount of effort to fix. I ditched Drupal for Rails specifically because I hate being in the position where I have to explain why a seemingly simple change would require far more work than logically makes sense (to be fair, this is an occupational hazard of programming, but with Drupal it happens to an obscene degree). Going to Rails felt like targetting a higher class of client. Meanwhile Rails developers seem like some of the most sought after programmers today. Where is this elite Drupal employment world that the OA speaks of?
  - juan_juarez 14y ago
    > In my experience, Drupal is ideal for cheap clients who want a zillion features but don't have the budget. IE - customers you don't really want to be stuck with in the first place.
Finbarr 14y ago
Couldn't agree more. Having built a range of Drupal sites on a freelance basis, I can confirm that you can do crazy amounts of work with just a few clicks of the mouse. The moment you realize you need to customize, however, is a dreadful one.
patrickocoffeyo 14y ago
Drupal is fine to code for, as long as you know what you are doing. #codemonkeylaughsatalltheclickmonkeys
mcantelon 14y ago
Developing via a GUI is good for rapid prototyping or CMS applications, but I prefer traditional coding for web applications. It's easy to change something in a GUI and not notice it. You can't "grep" a GUI to find the screen you need to access to change something (as you may need to click through several screens to get to where you want to go). Version control becomes more complicated as well: when development is defined by data in a database it's more complicated to have a staging/production setup than with straight-up code in version control. Plus text is expressive: there's a reason humanity moved to the written word from pictographs. Performance can also be an issue as well in Drupal, depending on your use-case. Stuff based on layer upon layer of abstraction uses more memory and can be slow. "Just add Varnish" works for some use-cases, but not others. Upgrading can be painful as well. Because third-party modules are dependent on Drupal core, when you upgrade Drupal core you also have to upgrade all your modules at the same time. For a complex site this can take awhile. If a module isn't upgraded you either have to do that work yourself, drop it as a dependency, or wait to see if the module gets updated. With less monolithic systems you can deal with upgrading components individually which can make the process more manageable.
- jackbravo 14y ago
  you can use the features module in drupal and have the best of both worlds. You click to get a prototype quickly, then you export the functionality to a module with drupal and keep track of changes with git.
exratione 14y ago
If you're using Drupal the way the author describes here - building in the interface rather than writing code - then yes, you're pretty much doomed. You're producing a very fragile thing that is very hard to maintain and adjust later on, and heaven help you if you actually want to do something in a different way than the modules you're working with allow out of the box. Drupal development is very divided between (a) the small number of people who can treat it as a framework and write solid custom code while still making good reuse of core and contributed modules to speed development versus (b) the much larger number of people who treat it as a sophisticated CMS with plugins, and typically use Views and template overrides to produce a fragile solution. On the money side of things - yes, if you're in group (a), then you can charge a bunch of money. Drupal development is very lucrative. If you're in group (b), then no. That's just an average wage.
- jtreminio 14y ago
  What would you recommend an experienced developer coming into Drupal do to land in group A?
  - rybosome 14y ago
    I had a lot of difficulty finding good learning resources for developers. Most are aimed at non-programmers. I had quite a few questions answered on http://drupal.stackexchange.com/ http://drupal.stackexchange.com/, which is a good starting point.
  - exratione 14y ago
    - Write a module with at least some UI to scratch an itch. - Then figure out how to contribute it to the community as a release on drupal.org. Both parts of that process are equally valuable.
  - knieveltech 14y ago
    Group A is guarded by a learning curve like the Swiss Alps. The only way to get past that is to get as much exposure as possible. There are already some excellent suggestions here so I won't rehash those, some other things you might consider: Idle in #drupal and #drupal-support. Whenever an interesting question gets asked, go figure it out if you don't know the answer already. Try tackling a few issues in the novice queues for D8. Not only will you get the kind of low-level exposure to how core really works that so many "Drupal developers" lack, you'll also get some nice bragging rights when your name's listed with the rest of the contributors. The next time you encounter a limitation with a module you're using, in addition to hook_$N_alter()'ing the fuck out of it, try writing a patch that cleanly extends the module to do what you want. Open an issue in the module's issue queue and submit your patch. Code review can be tough to take but stick with your issue until your patch is either accepted or the module maintainer closes the issue (won't fix, whatever). Try landing a gig with Acquia or some other big Drupal shop. You'll get to work with (and learn from) some of the top talent in the community and you'll get the kind of exposure you can't get experimenting in your spare time. If you're serious about going pro with Drupal development drop me a line. I may be able to help and would be happy to introduce you to others in the community.
richforrester 14y ago
I'm a Sydney-based UX person with a background in UI and front-end coding, and I happen to find programming (I dabble in php) extremely satisfying. Drupal, to me, is definitely a means to get things done. Here's my "day in Drupal": - Amazed - Amazed - Bored - WTF? - Lunch - Amazed - Puzzled - Amazed - FUCK YOU DRUPAL! - Amazed Yes, setting up content types and views can be annoying, but really, sometimes you get a view done in under 15 minutes. Including styling. Stuff like that never ceases to amaze me, and really makes Drupal worthwhile. I could never code a cms ground-up, and the likes of cakePHP and whatnot just seem a wee bit too far down the rabit-hole (for now). Drupal is an "easy" alternative.
patrickocoffeyo 14y ago
if you can't code a CMS, don't claim to be a professional at using them.
- mcrittenden 14y ago
  Can you expand on this? How is this comment relevant to the article?
  - reeses 14y ago
    If that were the case, there would be no market for CMS. Everyone who wanted one would hack one up in Excel. Or maybe Word with macros.
    - patrickocoffeyo 14y ago
      Not really, a CMS is good because you don't have to build the same thing multiple times. However, if you plan on using a CMS as a tool to create solid, scalable, efficient applications, you will need to understand how to use the CMS properly. Many times that means understand what the CMS is doing behind the scenes. Any good programmer should be able to code a project like Drupal, granted that would take time, but they should be able to do it without sweating too much. I get extremely tired of the noobs and click-monkeys taking of the drupal community. If you can't write your own decent CMS because you don't know how, you should find another job, and leave application development to people who can do it properly and give clients a product that is worth the money they payed.
      - reeses 14y ago
        You're confusing Drupal with a CMS. It's much more, and less.
        patrickocoffeyo 14y ago
        I'm not confusing it with a CMS at all, it is a CMS. You can use it more as a framework, but as a framework it really kind of sucks when compared to Code Igniter or zend, or even Yii.
math0ne 14y ago
astute article, as a full time drupal dev, i agree on most points
peterjmag 14y ago
Moving away from Drupal was one of my biggest steps forward as a web developer. I worked with Drupal full time for a little over two years. I spent much of that time clicking around in config screens, and when I did have to get my hands dirty with some custom code, I usually felt like I was just stumbling around in the shadow of the behemoth that is Drupal's API. I thought, "Surely this isn't what web development's supposed to be." Turns out I was right. On recommendation from a developer friend, I started experimenting with a bit Rails, tried a couple of "proper" PHP frameworks, and then discovered Python and its excellent web development ecosystem. That's when it really started to click for me—all these pieces that Drupal had so kindly obscured from me started falling in to place. Rather than trying to push around a monolith, I learned how to keep things lightweight and use only the pieces I needed. And importantly, I was actually writing code. Sweet, readable, maintainable, version-controllable code. None of this "serialize a hugely long options page and dump it all in the DB" stuff. (On a side note, learning git was another big catalyst for my move away from Drupal. D6 always felt like a pain to track in a VCS, especially when I was collaborating with another developer—though the situation may be improving.) I should point out: I think a big part of my frustration was the fact that many of the sites I was building didn't need something as big as Drupal. I've since found WordPress to be a better fit for most of the "easy" stuff, or even static HTML/CSS if it makes sense for the project. When I'm building something more complex, well, there rarely seems to be any reason for me to use Drupal anymore.
- lotyrin 14y ago
  I've been doing Drupal full time for the past four years and I'll agree 100%. People that try to build applications in Drupal are running a fool's errand. It's got a ton of code and another ton of assumptions, but that's the thing; when those assumptions are what you need and that's code you don't have to write, magic happens. I'd say, 90% of the time, if you're using Drupal and you're in a code editor instead of the admin UI, you're making a mistake, either because there's an easier way to do what you're doing, or because you shouldn't be using Drupal. The real trick is knowing which.
- patrickocoffeyo 14y ago
  Kudos! Drupal is good as a tool. But writing real code is where it's at bro. :)
deleted 14y ago
[deleted]
rybosome 14y ago
Developing a large web application in Drupal from October 2011 to May 2012 was, by far, the most stressful period of my professional life. The most difficult part is that the vast majority of learning materials for Drupal are aimed at non-developers. So much literature is dedicated to impressing people who otherwise couldn't create a website with things like, "LOOK! You can implement access control, put a smiley face next to all comments, AND have a YouTube video feed!" that finding documentation on actual code is extremely challenging. Another aspect of the project that was difficult was that the client had very specific needs. In almost every piece of functionality they requested, there was some wrinkle that made using an off-the-shelf module impossible. This meant having to code against the behemoth Drupal API. After about 3 months of work, I created an OO-wrapper module around Nodes called Doodal (https://github.com/rybosome/doodal https://github.com/rybosome/doodal) that makes it possible to code in an MVC-like way. This made the rest of the project somewhat easier, minus the parts that involved interfacing with native Drupal. Drupal was created at a time when PHP didn't have object oriented features. Their solution to the problem of needing OO-like behavior but not having it was to emulate it, which is an abstraction that quickly falls apart. For instance, the shortest line of PHP you could possibly write to simply print out an optional "first name" value from a node representing a person is... array_key_exists('und', $person->first_name) ? $person->first_name['und'][0]['safe_value'] : ''; While I was wrapping up this project, a friend of mine pointed me to an opening his company had for a Drupal dev, paying about 1.8x what I was making at the time. I declined without even thinking about it, and have not regretted it for a second.
- chx 14y ago
  First, it's LANGUAGE_NONE not 'und'. Second, while I could go on how you should use field_get_items instead, it's very very likely you are missing some concepts here an you want a formatter, a whole display mode etc. You very rarely need that level of plumbing.
  - rybosome 14y ago
    The constant LANGUAGE_NONE represents the value 'und'. Yes, using the value directly rather than the constant is bad practice, and certainly is not idiomatic in any language; I'll concede that point to you. Regarding the use of field_get_items, check the documentation on the return value: "An array of field items keyed by delta if available, FALSE otherwise." Per my requirement of getting a single, OPTIONAL field value, field_get_items might return false, which means we are still looking at something like this overly verbose code: ($first_name = field_get_items('node', $person, 'first_name')) ? array_shift($first_name) : ''; Lastly, "you want a formatter, a whole display mode, etc. You very rarely need that level of plumbing". One of the requirements for this project was that each page represented by a person node would have a very specific layout. This meant that I couldn't rely on Drupal's default layout (even with formatters there was too much baked-in HTML that was unacceptable), and had to create a node--person.tpl.php file, i.e. a custom template.
jacques_chester 14y ago
This all sounds like my $dayjob with Oracle Application Express. Except that ... you know ... people have heard of Drupal.
hawtshot 14y ago
Drupal definitely allows you to get 95% of the most common features done very quickly with contributed modules but the assessment that it shatters if you try to bend it too far is very accurate. Also, the RESTful API is not fun to work with, mainly because the documentation for it is really lacking. It gives you all the information that you need to do CRUD on standard fields but if you throw date or file fields into the mix, you'll be tearing your hair out. It's also quite clunky and tedious to parse responses from since it responds with entire nodes which can include unnecessary RDF info or multiple languages along with field values nested 3+ levels deep in arrays.
at-fates-hands 14y ago
Okay here's my Drupal story. It starts out with me at a Drupal conference. First question I ask is this, "Is Drupal a framework or a CMS?" To which the guy running it said cheerfully, "Both!" After building my personal site with Drupal, I realized the one thing which drove me nuts was the vast number of modules I wanted to use either had shitty documentation or none at all. It was basically, "Install this and it works!" Which made me spend even more time either having figure out how this thing worked, or attempting to write my own. To me, this is not a developer friendly framework. When I talk to my friends who are developers and they flat out tell you there's a STEEP learning curve with Drupal, they're not kidding. I can honestly say I built a dealer locator from scratch faster than I did trying to figure out how do it in Drupal. Just an example of the stuff I'm talking about: http://drupal.org/node/38401 http://drupal.org/node/38401
justinph 14y ago
Drupal 8 is basically trying to get to where django/rails/symfony were several years ago, and based on the glacial development pace of the last version, by the time it is complete, they'll still be several years behind the feature set of contemporary frameworks. In my experience, Drupal is a pristine example of the way modern software should not be made. With one or two notable exceptions, there is a distinct lack of computer science type knowledge in the drupal world. The result is kludgey, over-complicated, and inefficient code. Drupal's "success" is only because it's community consists of people who don't know any better. The author himself points this out by making laborious points about how much money there is to be made propagating bad, wasteful practices.
- knieveltech 14y ago
  "It's "success" is only because it's community consists of people who don't know any better." That is both untrue and dishonest. Drupal's success is directly attributable to all of the following: 1. a very large, growing, and passionate pool of contributing developers and designers. 2. aggressive community involvement a la issue queues, forums, IRC, local user's groups and 30+ regional camps and conferences in North America alone. 3. Did you read the part where the op wrote about the ridiculous amount of shit you can get done without opening a text editor? Office staff with minimal technical background can be trained to implement/manage most of it. 4. It. Just. Works. On commodity hosting no less. Or on expensive enterprise hosting. With little or no assing around with server configuration. There are hosts that have push-button site installation. In short, Drupal is popular for all of the same reasons that PHP still hasn't gone away after almost a decade of developers whinging that it sucks. Is it fun to code for? Nope, not even a little bit. By the time you've written your fourth or fifth custom module 99% of it is the same tired slog through boilerplate code and hook_$N_alter() groveling. Dull, dull, dull shit. And yet I suspect Drupal and Wordpress (which is arguably even worse to deal with) are running way more websites than django, rails, and symphony put together. Look on the bright side, at least it wasn't written in Perl. :)
  - justinph 14y ago
    1. Growing by what measure? When I was at Drupalcon 2012 there was a large amount of discussion about how the community wasn't growing and was the same people every year. And I seriously don't mean to be a dick, but passion doesn't equal technical competence. You don't have to be a gifted programmer to understand quality, and understand that Drupal lacks it. 2. There are user groups, I've been to them. They're mostly full of people who have basic problems and a few exasperated and grizzly veterans who offer arcane solutions to non-arcane problems "use last night's dev version of the module, sure it's ok to put php in the database... And the community of drupal.org might exist, but if you can sort it out from the convoluted UX mess that is drupal.org, good luck. 3. Is that supposed to be a feature? In theory, you can get ridiculous amounts of things done if you happen to know the arcane way to combine 30 different checkboxes and twelve different modules. How is this by any objective measure better than writing code? Code is expressive, documentable, concise. Checkboxes and UI interactions are not. 4. This is hardly a unique feature. The same can be said about wordpress, rails, django, etc (at least if you use webfaction) I don't think you can argue under any objective measure that wordpress is more difficult to deal with than drupal. It has many of the same issues as drupal (feature management), but the ease of theming and documentation are lightyears ahead. It's also quite a bit more limited.
vph 14y ago
Years ago, I wrote and published a couple of Drupal modules, which are still being used from time to time. But I moved away from Drupal. With Drupal, you don't learn about building web apps; what you learn is "tweaking" a complex system. You can be building very complex apps nicely, but at the same have no clue about what is underneath.
freshhawk 14y ago
And now we have all the silly arguments comparing web frameworks and CMS's. The CMS people will compare installing modules to writing code from scratch instead of installing a library and writing a bit of glue code. If they don't make that mistake they will probably underestimate how much more flexible, better written and better tested that library will be compared to the CMS module and overestimate how hard it is to glue in a general purpose library. The web framework people will underestimate just how fast it is to install a module into a completely integrated system and underestimate the time they would have spent integrating the library and writing the glue code. They'll also overestimate how often a client needs a piece of functionality that's in any way interesting instead of just a new skin on the same old thing. The answer is "The progression goes: CMS -> Web Framework -> Http related libraries" The question can be any of the following: "What web related stuff has the worst code quality? what has the best?" "How will the tools I use change as I get more experience in web development" "What tools will I use for the most boring web dev work? What about the most interesting?" "What tool skillsets in web development will earn me the most money" "What tool skillsets have the least amount of jobs? what about the most?" "What tools web dev tools will make me want to punch my monitor the most? and the least?" Feel free to come up with your own.
languagehacker 14y ago
Based on my two minutes of salary research I can say that someone with the title "Drupal Developer" make substantially less than someone with a title "Django Developer" (about $10k in SF), and (again, in SF terms), substantially less than the average software engineer without a framework in their title. From what I've seen on job posts over the last couple of years, including the framework in the title is something relatively endemic to Drupal, so I'm assuming that they don't get lumped into "Software Engineer" too often. So let's take compensation out of the discussion. Now let's just list the actual problems with Drupal. It seems like there are as many drawbacks are there are off-the-shelf features when you're making Drupal the core of your own product. It also seems to make a lot of assumptions about your application following a very specific CRM architecture. I'd personally prefer to spend the effort on building out the CRM components myself using a more modular framework so I have more control over the architecture, the version control history, etc. It sort of seems like Drupal tries really hard to set itself apart from WordPress. In reality, it seems the major PHP CRMs all fall into this very narrow point of view on what the responsibilities are of the implementing developer. This minimization of implementation detail promotes a very limited perspective on how a PHP web application works. So now your product's architecture is hobbled by the philosophies of the core library as well as those most apt to develop on it.
Joe_Knapp 14y ago
The problem with Drupal is its lack of human management. There's no one at the helm. It's being run by a bunch of programmers. That's why I gave up on Drupal. When you couldn't do a simple update in Drupal seven, I knew there was a problem. Then they have these other projects going on, like Drupal eight. Seven is not yet stable, then there are people making products for eight. I gave up over a year ago.
room271 14y ago
I wrote a blog on this problem for Drupal a while ago - but with a particular focus on the fact that Drupal has a 'talent problem' precisely because of what the article says (Drupal is not fun for developers and, moreover, fails to promote learning). You can read it here: http://room271.net/2012/05/24/developers-and-drupal.html http://room271.net/2012/05/24/developers-and-drupal.html I worked on Drupal for ~1 year and wrote very little custom code. The caveat is that core developers working at one of the top Drupal shops do get to write interesting code, but they are the exception rather than the norm. ps. still a big fan of Drupal, just don't want it to be my day-to-day work.
gadders 14y ago
I think this applies to a lot of platforms, tbh. It even reminds me of when I was a #embarrassed cough# Lotus Notes developer 12 years or so ago. I think it might be the price you pay for using a "framework". 80% = really easy, the remaining 20% is a git.
cyberswat 14y ago
The beauty of open source is that we have the ability to learn from the experiences of others. Many of the challenges expressed in these conversations are being met head on by the Drupal community. I disagree with many sentiments of the OP but also practice integrating different technologies, when appropriate, to get a job done ... The feedback in this thread is invaluable and highly appreciated. There are technical solutions in the form of modules and organizational workflow solutions that can be used to solve most of the issues I see mentioned here. There are also a lot of false or mis-informed assertions. Thanks for the insight.
saltcod 14y ago
I left Drupal for WordPress because: 1. When it breaks, it shatters—as you said 2. WordPress's UI is so much better for clients, in my experience 3. Theming in Drupal was a nightmare — div.class > div.class > div.class It's such a shame about Drupal. It's so capable, flexible and powerful, but the ui is a tough sell. You can build almost anything with it, but when it comes time to theme and eventually time to hand it off to the client, that's where things got hairy for me.
tombb 14y ago
If you're an engineer/coder building sites by clicking buttons all day, you're in the wrong job. That's not Drupal's fault though. Drupal is a CMS - a powerful one, but not a framework.. At my work we've got a team of "web designers" building websites using Drupal. It allows them to build most of the stuff that clients want for their website/intranet, without writing code. For the more business-logic heavy applications that need to scale and continuously require new features there's a separate team of Django developers. This approach seems to work fairly well: designers get to build pretty advanced stuff they normally wouldn't be able to without some programming help, developers don't get the boring CRUD/shopping cart stuff.
Zelphyr 14y ago
I just spent over a month on a project where we started to use Drupal and I can't see a single thing that is good about it. Poorly written core code. Poorly written modules. Abysmal UI. The only thing I can possibly think that Drupal has going for it is a great community and, as this article mentions, the ability to make a lot of money for little work. Needless to say, a month and a half into the project we dumped Drupal.
Falkon1313 14y ago
1) Drupal's great if you can accept something close to what you want - that has most (but not all) of what you want, plus some stuff that you didn't need. But if you're dealing with perfectionists who want things precisely their way, then you'll spend a lot of time and add a lot of complexity overriding, suppressing, and customizing things and gluing clusters of modules together. Sometimes more than if you'd just built what you needed from scratch. 2) Initial standup can be very quick and easy, especially if you can do it with mostly out-of-the-box stuff (see 1). But over the long-term maintenance and development can be extremely difficult. 3) If you're stuck using designs from designers who aren't skilled with Drupal, theming is likely to be inordinately difficult. Drupal provides a great amount of useful tools and utilities to designers, but if the designer doesn't use them then you basically have to rip them all out and/or override them all and the theme can grow monstrous. 4) The ability for a 'non-technical' user to do so much through the admin interface is a great strength. But the fact that there is so much there in the admin interface (scattered around by the different modules) means that non-technical users often can't (or won't) use it without a thorough understanding of Drupal and the modules. It's too complicated. So you'll need to add time to strip out, simplify, and rework the admin interface. Even then, you may still end up with programmers being tasked with content edits. 5) The database for config+content really is a big issue that majorly affects long-term maintenance and continuing development/deployment on a live site. 'Features' and exportables are not a good enough fix. They're better than nothing, but don't rely too heavily on them. They break down in a lot of cases. D8 promises to be better on that issue...we'll see. 6) Performance really is a problem. For any moderately complex and trafficked site, you have to set up proxies and elaborate caching and etc. etc. just to get "okay, I suppose that's acceptable enough" performance. It can be done, but it's a major headache. That's a tradeoff for the flexibility and modularity. I've built scores of sites in Drupal over the years, and it's a great tool, but it's far from perfect. It's all about tradeoffs, and often the greatest strengths are also the greatest weaknesses. You just have to decide whether it fits what you need. If you can live with the drawbacks, then it's good. If not, then you'll need something else which will have it's own different set of drawbacks.
berkes 14y ago
I think author is switching cause and effect: Move a few paragraphs around and the problem becomes clear. It is right in his article! > Drupal just isn't a great system to code for. And then > No debugging your custom code Proper, well architectured custom code is not hard to debug. At least not anywhere near as hard as debugging Drupalcode. Due to, yup "Drupal just isn't a great system to code for." > No digging through the docs trying to find the API function you need for an odd task "Drupal just isn't a great system to code for." > A discoverable UI--click around until you find what you're looking for, rather than digging through code Hmm. there is a pattern here: "Drupal just isn't a great system to code for." > A team of thousands of users and contributors testing the code in ways you never would have imagined and fixing the bugs Klicking Monkeys testing stuff? Where are the unit-tests? CI? They are there, somewhere in Drupal, but in reality unusable, because, yup "Drupal just isn't a great system to code for." > A much much smaller risk of security breaches due to that team Well, to an extend. But the most security comes from your arcitecture. And 90% of the Drupal-security-anouncements can be tracked back to, yup "Drupal just isn't a great system to code for.". > Holy crap, so much faster Yes. Faster then coding. But that is only true for Drupal, because, "Drupal just isn't a great system to code for.". It certainly is not faster then your average RAD-framework for many, many sites. There may be some cases where Drupal is faster, but only when you don't have to write a line of code, nor need to debug and find why Module Foo and Bar don't work together, because.. well. See above.
dougvann 14y ago
...note... After Mike published the "Golden Handcuffs" post he publicly stated that he did not intend it to be so negative. [yah... I've been there. I start typing and my passion pours out and all the sudden I'm fire up like crazy] So I hope my criticism of this article is pointed in the right direction. ... here goes.... I can not begin to state how much I disagree with the conclusion of this post by @mcrittenden . I believe he feels the way he feels. I believe he has experienced what he says he experienced. But the conclusion is not a typical one. Most of us who are making tremendous earnings in Drupal are NOT bored, unchallenged and lamenting the lack of fun and elegance of coding. We are excited, challenged, evolving, stretched ppl who are having a blast with what we believe to be the BEST community associated with the BEST software out there. [yah... we're pretty biased but THAT is the enthusiasm you run into on a large scale] I am not saying that he's lying. I believe he is telling the truth when he says he's bored and unchallenged and despises the lack of elegance. I liken that to some one who really misses their horse after trading it in for a Model-T. I get it. We did just find for a very very long long time with the horse. Horses are still used today and not just for entertainment but for very real and practical reasons. There's simply NO WAY that some one is going to have a relationship with a car in any similar manner that they did with their horse. I fully respect @mcrittenden and his position here. When ever some one goes on a rant about what they don't like about Drupal [and OH how often this happens!] I find that many of the points are valid and I can not write them off and dismiss them out of hand. Such is the case here. I will say this.... Drupal is a career and a discipline and a community. I encounter some of the same challenges that @mcrittenden does. I don't have the same reaction. I get better and better at this and I have many friends who I can reach out to. Whereas shops have a lot of BRAIN POWER in-house, we independents stick together and hit each other up with those WTF moments. Between all the DrupalCamp, DrupalCons, local UserGroups, Internet Relay Chat, Skype, Email... I'm very connected to the community and I get answers to my questions when ever I need them. If I know an area of development is going to be extra challenging.. I will factor in some room to pay my friends who know things I do not. Yah... We get freebys from each other ALL THE TIME but I really love it when I tell some one I have a couple hundred bucks to spend on them to teach me something or to architect a solution. I've even spent thousands like this before. I knew the client had needs and I connected them with another shop to handle a very specific piece of the puzzle. It worked well for all concerned. And by the way... this was FUN and Challenging and the solution was very Elegant. CONCLUSION: I DEFINITELY run into issues with Drupal from time to time. Just like sharepoint and vignette and ez-publish and auto-mechanics and horse-handlers do. My reaction is a little different. I have made the choice long long ago that DRUPAL is my vehicle. I don't want to use Joomla like I used to. I don't want to use Sharepoint like I started to and was studying in 2007. I chose Drupal. Now that I have made that choice I am enjoying great money and great challenges and an even greater community. Our system has its quarks; some are minor and some not so minor. Regardless, this is the path I'm on. We, the community, are continuing to improve "this area" and "that area" and yes I'll even agree that some areas are getting a little worse with each release. This is no secret and I'm part of two different teams that are assessing the situation and proposing action and then encouraging and seeking funds for that re-action. We're seriously on a roll here with this stuff. @mcrittenden I get it, man. This stuff [called Drupal] can ROYALY piss a guy, or gal, off at times. But what you describe as boredom and click monkeys is a drastically inaccurate description of what I, or anyone I know, do for a living. I do know of many HOBBYIST Drupalers who just want to point and click and they are using Drupal as an overgrown geo-cities but I know that's not who you're talking about here. I really appreciate the article! This global conversation is sparking other conversations that are enacting change! So.. THNX! Doug Vann [Drupal Trainer, Consultant, Developer] http://dougvann.com http://dougvann.com
nearly 14y ago
the article refers to being bored. any drupal dev who is bored because they are talented and unchallenged should be contributing to core development. the OPs d.o profile shows contribution but not focused on a particular core initiative. the employer could be giving time over for that. contribution is satisfying and challenging. and much needed!!
nearly 14y ago
the article refers to being bored. any drupal dev who is bored because they are talented and unchallenged should be contributing to core development. the OPs d.o profile shows contribution but not focused on a particular core initiative. the employer could be giving time over for that. contribution is satisfying and challenging. and much needed!!

187 points by mcrittenden 14y ago

I'm using Drupal as a back-end, and doing the fun stuff in the front-end on the client. No boring days here.

I would add this to the complaints: - NOT AMENABLE TO SOURCE CONTROL Half the code lives in the database, configuration is all mixed up with content, and there's no reliable programmatic way to extract it. It makes doing deployment a nightmare. And the worst part? Drupal developers by and large have such a narrow range of experience that they don't even know what they are missing. They have no idea what good coding standards look like, a lot of them don't even have a development/production separation: they just hack away on the live site with no source control or backup. And no one writes tests, or sees why they would be useful. Some of the big professional drupal shops appear to have basically written their own cms on top of drupal, with a bunch of terrible hacks to try to make source control kind of work, and just use the drupal name basically as a marketing technique. So glad I don't have to deal with any of that insanity any more.

oinksoft 14y ago
This is the main reason I chucked my Drupal 'cuffs in 2008, no longer taking on new Drupal projects and helping my clients move over to other Drupal service providers: It was very, very difficult to scale up my business because bringing on extra developers, and having consistent local/dev/staging/production environments was at least an order of magnitude more difficult that it would be with other tools. In Drupal 6, the only way to reproduce an environment was with a massive install profile for the project, and the average Drupal developer was entirely clueless to matters of testing and version control when compared to the average Django/Rails/CakePHP developer. This made for many painful projects and unhappy clients, usually beginning 6-8 weeks into the project when the issues of database drift became inevitable. And like you said, everything lives in the database. So the chances that some production issue (or new issue only seen in dev) was caused by an errant user action in the Drupal UI was pretty high, and this made debugging a nightmare -- where is my issue really coming from? I'd just about forgotten about my Drupal days of yore, and between the "click monkey" analogy and the "clear the cache" nostalgia, the author sure conjured up some bad memories!
jackbravo 14y ago
This is why http://drupal.org/project/features http://drupal.org/project/features module was born. To allow you to export your functionality to code and have it under version control. Features and things like http://drupal.org/project/drush_make http://drupal.org/project/drush_make is what makes a lot of the drupal distributions (http://drupal.org/project/distributions http://drupal.org/project/distributions) that keep popping up because sourced controlled, feature driven development is now possible in drupal. Also the testing part has been improving, and although very few of the contrib modules have tests most of core has automatic testing in place for when you submit a patch as you can see in the issue queues (http://drupal.org/node/466576 http://drupal.org/node/466576).
- w4y2 14y ago
  Features is good as a concept, but in implementation it fails considerably. Here are a few issues: - How to deprecate a feature (I created http://drupal.org/node/1400346 http://drupal.org/node/1400346 to attempt to solve this, but admitedly, it's a very dangerous module) - Ever created a feature with tons of things in it? Hello, 5 minute load times for admin pages! - How do you merge two features together? How do you commit just one feature and not another (say, one you're still working on?) The CMI initiative will hopefully take care of a lot of the messiness and bugs in Features.
  - vaporstun 14y ago
    The other downside of Features in Drupal is that if we export something as a Feature (say a View) and then our site builders tweak and change that View for our clients and then we update some core element of that View and re-export the Feature, that re-export will overwrite any custom changes that were made to that View, thereby trashing any of the custom changes. This is a real problem with Features to which I'm surprised there has not yet been a good solution.
    - jackbravo 14y ago
      Same problem as other frameworks. You need to know the rules. If you use rails, and the designer changes the CSS without committing the change to git, then next code push will erase his change.
emmelaich 14y ago
> [ ..in the database ..] Similar comments for Moodle, another popular PHP app. You cannot even change the url for your site without rewriting content in the database.
- smacktoward 14y ago
  WordPress too. In fact in WordPress the site root URL is stored in two separate configuration fields, so woe betide you if you rewrite one field and not the other. Thankfully the WP core devs seem to have been slowly cleaning stuff like this up over the last couple years. So even though this wart persists, I have hope it'll eventually get zapped.
  - jasey 14y ago
    In my wp-config.php file I have the following logic https://gist.github.com/3831423 https://gist.github.com/3831423
hippich 14y ago
On one hand there is Features modules and tons of modules built on top of it. On the other hand - if this problem could be solved - Drupal become holy grail, which should not exist! :)
knieveltech 14y ago
I work for a company that provides site implementation, custom feature coding and ongoing support for ~30 enterprise websites and all of them have this in common: 100% of the source code for each site is in revision control (SVN or Git, depending on client preferences). If you want to complain about Drupal be my guest. The ground's very fertile, but what you've posted here is FUD. Code in the database? No, just no. While it is technically possible to stuff code into the database community best practices (not to mention common sense) strongly advise against this practice. What you are describing is the system handing you enough rope to hang yourself, not it's default behavior. Configuration lives in configuration tables. Content lives in content tables. "they just hack away on the live site with no source control or backup" It would be a mistake to take the fumblings of a few scrub freelancers or interns and extrapolate that as being the norm for all (or even most) Drupal developers. For all core modules and all quality* contrib modules there are $N_load() functions to extract these (reliably) from the database. * With ~8000 contributed modules to choose from, quality varies wildly. While unfortunate, it's to be expected when you've got that many chefs in the kitchen.
- apendleton 14y ago
  This is quibbling over semantics. Drupal's custom content types, custom fields, and Views all allow developers to express complex logic that would, in any other development environment, be expressed as code and committed to version control -- creating a new content type in Drupal and adding fields to it is exactly analogous to creating a new model in Django. You can call it "configuration" if that makes it easier to justify its being in a table, but it doesn't change the fact that Drupal developers spend lots of time building shit that can't go in a VCS, can't be easily tested, can't be branched/merged, and can't be easily deployed without a convoluted export/import dance. Just because there isn't literal code in the database, it doesn't mean there's a clean logic/content separation.
  - fauigerzigerk 14y ago
    Not that I know much about Drupal, but isn't it inevitable that stuff that can be changed via the UI (sometimes even per user) has to live in the database? This is simply a consequence of blurring the lines between developers and users, which is exactly the point of CMSs. Actually, I think what we should be asking is this: Do CMS databases and VCS really have to be two completely seperate universes? I would say no. There is room for a new type of CMS database design that includes all the functions of a VCS.
lotyrin 14y ago
I work on big Drupal sites and this simply is not true. Drupal lets you get a ton of shit accomplished without making you understand a single line of code, have a reasonable Dev-Stage-Prod workflow, QA, even version control or backups, etc., but it's completely possible to do all of that. That means that it can scale from anywhere from something like a 16 year-old's shared-host fanfiction site to say Whitehouse.gov. Of course that means that there will be tons of fuckups live-coding (or live-configuring) on production, or people that don't export and version things in environments when they should, and that people will construct fragile combinations of modules and configuration where a tiny bit of code would have sufficed, or write tons of fragile custom code with no tests or security review when there was already a module for that. But allowing people to be fuckups doesn't force them to be, and they can be trained.
- mtts 14y ago
  "That means that it can scale from anywhere from something like a 16 year-old's shared-host fanfiction site to say Whitehouse.gov." Scaling to Whitehouse.gov is not impressive at all. Like a 16 year-old's shared-host fanfiction site whitehouse.gov really is nothing more than a content site, albeit a very large one. The problem is Drupal isn't content to simply be a CMS. It has to pretend to be a framework for developing web apps as well, and for that it's just plain terrible.
  - lotyrin 14y ago
    If you compare it to a framework it loses, obviously. It's massive and complicated. And while PHP's is trying hard to modernize, the tools and ecosystem still don't compare to Ruby or Python (see below). Drupal is only for when what it (or modules) can provide is a vast majority of the requirements of the project. Anything that couldn't be described as "nothing more than a content site" probably would not be a good fit. The only thing it has to offer is when what you need is one of the myriad things it can be configured to be, because then you get a bunch of community eyes and tests on a bunch of code you didn't have to write. Edit: Discussion on recent improvements to PHP's and its ecosystem (which are exciting progress in a direction I believe there is more room to go) http://news.ycombinator.com/item?id=4605715 http://news.ycombinator.com/item?id=4605715
modarts 14y ago
Wow. This sounds exactly like a complaint that would be lobbed against SharePoint (rightfully so, it's a special kind of hellish nightmare for people responsible for developing on it.)
mmcnickle 14y ago
Such is the inner platform effect. I would happily bet there is someone working on a drupal-specific, poor substitute for version control.
- lotyrin 14y ago
  Nope. They're busting the inner platform and having config live in the filesystem to get versioned like anything else. Good luck with those prejudices, though.
  - mmcnickle 14y ago
    Does it address config drift in production where users make changes that aren't reflected in the versioned codebase? The question is not intended as a retort, I'm interested in the answer. The prejudices I have against Drupal are the result of my experience of it starting as far back as version 4. I don't believe they are unfounded.
    - TylerE 14y ago
      You're not wrong at all. I'm currently investing moving our sites (a network with 1M+ visits/and 12M+ pageviews) from Drupal 6 to Rails. We have a large amount of custom code (I've written 20+ modules for this platform), and yet we've gotten to a point where we really want Drupal (and PHP) out of our lives, because it isn't worth the headaches anymore.
ZoFreX 14y ago
Absolutely not true. When I was working with Drupal 6, CCK and Views 2, I would use the GUI to try out new content types and views, but I would then export their definitions and put the code for them into a custom module, which was under version control. When I first started out I actually wasn't using CCK or Views 2, I was creating new node types with a custom module, and if I were to go back to Drupal now I would be sorely tempted to do this again. Views was a bit too fragile and the queries it generated were horrific, and I think if you can code and know PHP and MySQL well they really give you very little value, or possibly even work out slower overall.
Daniel_b 14y ago
I completely disagree with your views about Drupal development. We've recently migrated bmj.com (a big site with gets 1.6 million visitors and 6.8 million page views a month) from old Java Servlet based platform to Drupal. We've used continuous development process where up to 4 developers were working on the same code base in dev, staging/testing and prod environments. It is now a standard Drupal development practice to export all configuration data to the source code. BMJ.com is not a simple site, it has an article page with quite complex data structure with up to 60 meta data elements (author details, publication date, vol/issue number, section, series, category, taxonomy, relations to other articles, open access flag, etc...) being rendered at the relevant blocks. The business and editorial departments have been happy with the new opportunities Drupal is offering them. For more detail, please access Drupal success case study: http://drupal.org/node/1557636 http://drupal.org/node/1557636
- berkes 14y ago
  > from old Java Servlet based platform to Drupal. This does not say much about Drupal being good in absolute terms. It only tells us the obvious point that Drupal is a lot better then your old application. What you state would have been just as trough had you developed in Rails, Django, and maybe even in PHPnuke. What you don't state, is why Drupal was the better fit compared to modern alternatives. Is it?
dougvann 14y ago
Right you are @tedsuo There are many ppl not writing tests and not using staging and best deployment practices. This is true in every CMS and WCF. I don't believe it it any more prevalent in Drupal than anywhere else. Drupal invites a lot of BEGINNER types to the arena of web solutions. As such you will certainly find the things you mention. I don't agree with your suspicion that big shops are hacking core and building custom CMSs upon Drupal in a vain effort to try and gain source control features. Rather... I'm aware of big shops sticking to Drupal bets practices and using Features, Strongarm, Plumber and other modules to get configuration into code and keep it source controlled. If Drupal deployment were the nightmare you s=describe, then the phenomenal adoption of Drupal that we see today would make no sense. Why would the Georgia Tech Authority decide to move SIXTY-FIVE sites off of a Oracle, Java, Vignette solution and onto Drupal? Well.. It is isn't because they like nightmares during deployment. Drupal is growing up. The issues that plagued us 5 years ago when I got involved are being solved with varying degrees of success and effort. We're not where we want to be but the market is eating us up. We are bullish about our future and know that out continued improvement will only serve to better our position as the leader that we are in the web space. Doug Vann [Drupal Trainer, Consultant, Developer] http://dougvann.com http://dougvann.com

graeme 14y ago

I don't have this problem, currently. But I've previously used boring, lucrative work to bootstrap my way into more interesting work. Here are the steps: 1. Identify what you would rather do 2. Keep doing boring work, but part time 3. Reduce expenses 4. Use money from boring work to subsidize skill development in interesting area 5. Switch to interesting area Obviously, this only works in fields where you can get away with ~4 per day spent on your main work.

jack-r-abbit 14y ago

uh... I have never had a day when I said "I'm Bored" like that. What you describe as all the Productivity stuff that can be done with zero coding isn't really all that Drupal developers do. At least not where I work. We are writing custom code/modules on a daily basis... not just "every now and then". But I guess it comes down to the type of site you're building. But I have had my fair share of "WTF?" and "Damn it, Drupal!" moments. That much is true.

stevepurkiss 14y ago

Interesting article, perhaps if a few of those "I'm bored"s were changed to "I'm helping make Drupal suck less by writing some documentation" or "I'm learning cool new stuff cos Drupal does the generic boring stuff for me" the author would have a more fulfilling life. If everyone blows a little more energy back into the Drupal project, it'll suck a lot less ;)

jackbravo 14y ago
I agree 100%. That makes it a lot less boring because you feel you are doing something useful not only for yourself. That's also why Drupal has huge amounts of contributed modules and developers. Lots of people who do just that. Drupal is the Linux of the CMSs.
mcrittenden 14y ago
It depends on your work environment. If your boss asks for 40 billable hours a week and you have a family to keep you busy in off hours then there's not much time for writing docs or contributing modules.
- jackbravo 14y ago
  Is the same problem that every person working with free software projects faces. Can I contribute more if I'm not being paid to do it? In the long run you can expect those extra hours contributing to the project to really pay off, because you gain a deeper understanding of where things go, because you meet people that can help you, because people see your contributions and you make connections and a lot of other goodies.
Angelo8000 14y ago
I agree - Perhaps some more active contribution rather than just the usual "I'm bored", etc. Why not be more proactive. Good point.

patrickdavey 14y ago

I have just left my Drupal job for a Rails job, pretty much for the reasons listed here... I'm certainly going to be making _more_ money doing it too. I reckon 40 hours a week (or whatever you work) is far too many to be doing something that leaves you bored or frustrated for a reasonable percentage of the time.

lkrubner 14y ago

I am puzzled by this: "Good Drupal developers are making a lot of money right now, much more than I'm seeing for Django or Rails or Node devs in general." I am curious where this is? This is not true in New York City, where I am. Developers who are good with a given PHP framework (Drupal, Symfony, etc) will make something like $60 to $70 an hour. The top Rails devs will make at least the same amount, and usually a little more than that.

enobrev 14y ago
I know developers (including myself on a rare occasion - i tend towards custom development) who are doing far better than $70/hour for Drupal development in NYC. Although I don't know many successful developers who explicitly sell themselves as "[Framework] Developers". More often than not, when shooting for a higher rate, it seems to sell better as someone who provides a full solution, which May include specific frameworks if necessary.
dasil003 14y ago
This doesn't make sense to me either, though I haven't touched Drupal for at least 6 years. In my experience, Drupal is ideal for cheap clients who want a zillion features but don't have the budget. You can deliver more functionality in Drupal than anything else, that is absolutely true. For high-end clients who are willing to pay for impeccable UX and solid problem-solving, I can rarely recommend Drupal because it starts with a raft of assumptions that tend to lead to subtle compromises in the UX but would require an inordinate amount of effort to fix. I ditched Drupal for Rails specifically because I hate being in the position where I have to explain why a seemingly simple change would require far more work than logically makes sense (to be fair, this is an occupational hazard of programming, but with Drupal it happens to an obscene degree). Going to Rails felt like targetting a higher class of client. Meanwhile Rails developers seem like some of the most sought after programmers today. Where is this elite Drupal employment world that the OA speaks of?
- juan_juarez 14y ago
  > In my experience, Drupal is ideal for cheap clients who want a zillion features but don't have the budget. IE - customers you don't really want to be stuck with in the first place.

Finbarr 14y ago

Couldn't agree more. Having built a range of Drupal sites on a freelance basis, I can confirm that you can do crazy amounts of work with just a few clicks of the mouse. The moment you realize you need to customize, however, is a dreadful one.

patrickocoffeyo 14y ago

Drupal is fine to code for, as long as you know what you are doing. #codemonkeylaughsatalltheclickmonkeys

mcantelon 14y ago

Developing via a GUI is good for rapid prototyping or CMS applications, but I prefer traditional coding for web applications. It's easy to change something in a GUI and not notice it. You can't "grep" a GUI to find the screen you need to access to change something (as you may need to click through several screens to get to where you want to go). Version control becomes more complicated as well: when development is defined by data in a database it's more complicated to have a staging/production setup than with straight-up code in version control. Plus text is expressive: there's a reason humanity moved to the written word from pictographs. Performance can also be an issue as well in Drupal, depending on your use-case. Stuff based on layer upon layer of abstraction uses more memory and can be slow. "Just add Varnish" works for some use-cases, but not others. Upgrading can be painful as well. Because third-party modules are dependent on Drupal core, when you upgrade Drupal core you also have to upgrade all your modules at the same time. For a complex site this can take awhile. If a module isn't upgraded you either have to do that work yourself, drop it as a dependency, or wait to see if the module gets updated. With less monolithic systems you can deal with upgrading components individually which can make the process more manageable.

jackbravo 14y ago
you can use the features module in drupal and have the best of both worlds. You click to get a prototype quickly, then you export the functionality to a module with drupal and keep track of changes with git.

exratione 14y ago

If you're using Drupal the way the author describes here - building in the interface rather than writing code - then yes, you're pretty much doomed. You're producing a very fragile thing that is very hard to maintain and adjust later on, and heaven help you if you actually want to do something in a different way than the modules you're working with allow out of the box. Drupal development is very divided between (a) the small number of people who can treat it as a framework and write solid custom code while still making good reuse of core and contributed modules to speed development versus (b) the much larger number of people who treat it as a sophisticated CMS with plugins, and typically use Views and template overrides to produce a fragile solution. On the money side of things - yes, if you're in group (a), then you can charge a bunch of money. Drupal development is very lucrative. If you're in group (b), then no. That's just an average wage.

jtreminio 14y ago
What would you recommend an experienced developer coming into Drupal do to land in group A?
- rybosome 14y ago
  I had a lot of difficulty finding good learning resources for developers. Most are aimed at non-programmers. I had quite a few questions answered on http://drupal.stackexchange.com/ http://drupal.stackexchange.com/, which is a good starting point.
- exratione 14y ago
  - Write a module with at least some UI to scratch an itch. - Then figure out how to contribute it to the community as a release on drupal.org. Both parts of that process are equally valuable.
- knieveltech 14y ago
  Group A is guarded by a learning curve like the Swiss Alps. The only way to get past that is to get as much exposure as possible. There are already some excellent suggestions here so I won't rehash those, some other things you might consider: Idle in #drupal and #drupal-support. Whenever an interesting question gets asked, go figure it out if you don't know the answer already. Try tackling a few issues in the novice queues for D8. Not only will you get the kind of low-level exposure to how core really works that so many "Drupal developers" lack, you'll also get some nice bragging rights when your name's listed with the rest of the contributors. The next time you encounter a limitation with a module you're using, in addition to hook_$N_alter()'ing the fuck out of it, try writing a patch that cleanly extends the module to do what you want. Open an issue in the module's issue queue and submit your patch. Code review can be tough to take but stick with your issue until your patch is either accepted or the module maintainer closes the issue (won't fix, whatever). Try landing a gig with Acquia or some other big Drupal shop. You'll get to work with (and learn from) some of the top talent in the community and you'll get the kind of exposure you can't get experimenting in your spare time. If you're serious about going pro with Drupal development drop me a line. I may be able to help and would be happy to introduce you to others in the community.

richforrester 14y ago

I'm a Sydney-based UX person with a background in UI and front-end coding, and I happen to find programming (I dabble in php) extremely satisfying. Drupal, to me, is definitely a means to get things done. Here's my "day in Drupal": - Amazed - Amazed - Bored - WTF? - Lunch - Amazed - Puzzled - Amazed - FUCK YOU DRUPAL! - Amazed Yes, setting up content types and views can be annoying, but really, sometimes you get a view done in under 15 minutes. Including styling. Stuff like that never ceases to amaze me, and really makes Drupal worthwhile. I could never code a cms ground-up, and the likes of cakePHP and whatnot just seem a wee bit too far down the rabit-hole (for now). Drupal is an "easy" alternative.

patrickocoffeyo 14y ago

if you can't code a CMS, don't claim to be a professional at using them.

mcrittenden 14y ago
Can you expand on this? How is this comment relevant to the article?
- reeses 14y ago
  If that were the case, there would be no market for CMS. Everyone who wanted one would hack one up in Excel. Or maybe Word with macros.
  - patrickocoffeyo 14y ago
    Not really, a CMS is good because you don't have to build the same thing multiple times. However, if you plan on using a CMS as a tool to create solid, scalable, efficient applications, you will need to understand how to use the CMS properly. Many times that means understand what the CMS is doing behind the scenes. Any good programmer should be able to code a project like Drupal, granted that would take time, but they should be able to do it without sweating too much. I get extremely tired of the noobs and click-monkeys taking of the drupal community. If you can't write your own decent CMS because you don't know how, you should find another job, and leave application development to people who can do it properly and give clients a product that is worth the money they payed.
    - reeses 14y ago
      You're confusing Drupal with a CMS. It's much more, and less.
      - patrickocoffeyo 14y ago
        I'm not confusing it with a CMS at all, it is a CMS. You can use it more as a framework, but as a framework it really kind of sucks when compared to Code Igniter or zend, or even Yii.

math0ne 14y ago

astute article, as a full time drupal dev, i agree on most points

peterjmag 14y ago

Moving away from Drupal was one of my biggest steps forward as a web developer. I worked with Drupal full time for a little over two years. I spent much of that time clicking around in config screens, and when I did have to get my hands dirty with some custom code, I usually felt like I was just stumbling around in the shadow of the behemoth that is Drupal's API. I thought, "Surely this isn't what web development's supposed to be." Turns out I was right. On recommendation from a developer friend, I started experimenting with a bit Rails, tried a couple of "proper" PHP frameworks, and then discovered Python and its excellent web development ecosystem. That's when it really started to click for me—all these pieces that Drupal had so kindly obscured from me started falling in to place. Rather than trying to push around a monolith, I learned how to keep things lightweight and use only the pieces I needed. And importantly, I was actually writing code. Sweet, readable, maintainable, version-controllable code. None of this "serialize a hugely long options page and dump it all in the DB" stuff. (On a side note, learning git was another big catalyst for my move away from Drupal. D6 always felt like a pain to track in a VCS, especially when I was collaborating with another developer—though the situation may be improving.) I should point out: I think a big part of my frustration was the fact that many of the sites I was building didn't need something as big as Drupal. I've since found WordPress to be a better fit for most of the "easy" stuff, or even static HTML/CSS if it makes sense for the project. When I'm building something more complex, well, there rarely seems to be any reason for me to use Drupal anymore.

lotyrin 14y ago
I've been doing Drupal full time for the past four years and I'll agree 100%. People that try to build applications in Drupal are running a fool's errand. It's got a ton of code and another ton of assumptions, but that's the thing; when those assumptions are what you need and that's code you don't have to write, magic happens. I'd say, 90% of the time, if you're using Drupal and you're in a code editor instead of the admin UI, you're making a mistake, either because there's an easier way to do what you're doing, or because you shouldn't be using Drupal. The real trick is knowing which.
patrickocoffeyo 14y ago
Kudos! Drupal is good as a tool. But writing real code is where it's at bro. :)

deleted 14y ago

[deleted]

rybosome 14y ago

Developing a large web application in Drupal from October 2011 to May 2012 was, by far, the most stressful period of my professional life. The most difficult part is that the vast majority of learning materials for Drupal are aimed at non-developers. So much literature is dedicated to impressing people who otherwise couldn't create a website with things like, "LOOK! You can implement access control, put a smiley face next to all comments, AND have a YouTube video feed!" that finding documentation on actual code is extremely challenging. Another aspect of the project that was difficult was that the client had very specific needs. In almost every piece of functionality they requested, there was some wrinkle that made using an off-the-shelf module impossible. This meant having to code against the behemoth Drupal API. After about 3 months of work, I created an OO-wrapper module around Nodes called Doodal (https://github.com/rybosome/doodal https://github.com/rybosome/doodal) that makes it possible to code in an MVC-like way. This made the rest of the project somewhat easier, minus the parts that involved interfacing with native Drupal. Drupal was created at a time when PHP didn't have object oriented features. Their solution to the problem of needing OO-like behavior but not having it was to emulate it, which is an abstraction that quickly falls apart. For instance, the shortest line of PHP you could possibly write to simply print out an optional "first name" value from a node representing a person is... array_key_exists('und', $person->first_name) ? $person->first_name['und'][0]['safe_value'] : ''; While I was wrapping up this project, a friend of mine pointed me to an opening his company had for a Drupal dev, paying about 1.8x what I was making at the time. I declined without even thinking about it, and have not regretted it for a second.

chx 14y ago
First, it's LANGUAGE_NONE not 'und'. Second, while I could go on how you should use field_get_items instead, it's very very likely you are missing some concepts here an you want a formatter, a whole display mode etc. You very rarely need that level of plumbing.
- rybosome 14y ago
  The constant LANGUAGE_NONE represents the value 'und'. Yes, using the value directly rather than the constant is bad practice, and certainly is not idiomatic in any language; I'll concede that point to you. Regarding the use of field_get_items, check the documentation on the return value: "An array of field items keyed by delta if available, FALSE otherwise." Per my requirement of getting a single, OPTIONAL field value, field_get_items might return false, which means we are still looking at something like this overly verbose code: ($first_name = field_get_items('node', $person, 'first_name')) ? array_shift($first_name) : ''; Lastly, "you want a formatter, a whole display mode, etc. You very rarely need that level of plumbing". One of the requirements for this project was that each page represented by a person node would have a very specific layout. This meant that I couldn't rely on Drupal's default layout (even with formatters there was too much baked-in HTML that was unacceptable), and had to create a node--person.tpl.php file, i.e. a custom template.

jacques_chester 14y ago

This all sounds like my $dayjob with Oracle Application Express. Except that ... you know ... people have heard of Drupal.

hawtshot 14y ago

Drupal definitely allows you to get 95% of the most common features done very quickly with contributed modules but the assessment that it shatters if you try to bend it too far is very accurate. Also, the RESTful API is not fun to work with, mainly because the documentation for it is really lacking. It gives you all the information that you need to do CRUD on standard fields but if you throw date or file fields into the mix, you'll be tearing your hair out. It's also quite clunky and tedious to parse responses from since it responds with entire nodes which can include unnecessary RDF info or multiple languages along with field values nested 3+ levels deep in arrays.

at-fates-hands 14y ago

Okay here's my Drupal story. It starts out with me at a Drupal conference. First question I ask is this, "Is Drupal a framework or a CMS?" To which the guy running it said cheerfully, "Both!" After building my personal site with Drupal, I realized the one thing which drove me nuts was the vast number of modules I wanted to use either had shitty documentation or none at all. It was basically, "Install this and it works!" Which made me spend even more time either having figure out how this thing worked, or attempting to write my own. To me, this is not a developer friendly framework. When I talk to my friends who are developers and they flat out tell you there's a STEEP learning curve with Drupal, they're not kidding. I can honestly say I built a dealer locator from scratch faster than I did trying to figure out how do it in Drupal. Just an example of the stuff I'm talking about: http://drupal.org/node/38401 http://drupal.org/node/38401

justinph 14y ago

Drupal 8 is basically trying to get to where django/rails/symfony were several years ago, and based on the glacial development pace of the last version, by the time it is complete, they'll still be several years behind the feature set of contemporary frameworks. In my experience, Drupal is a pristine example of the way modern software should not be made. With one or two notable exceptions, there is a distinct lack of computer science type knowledge in the drupal world. The result is kludgey, over-complicated, and inefficient code. Drupal's "success" is only because it's community consists of people who don't know any better. The author himself points this out by making laborious points about how much money there is to be made propagating bad, wasteful practices.

knieveltech 14y ago
"It's "success" is only because it's community consists of people who don't know any better." That is both untrue and dishonest. Drupal's success is directly attributable to all of the following: 1. a very large, growing, and passionate pool of contributing developers and designers. 2. aggressive community involvement a la issue queues, forums, IRC, local user's groups and 30+ regional camps and conferences in North America alone. 3. Did you read the part where the op wrote about the ridiculous amount of shit you can get done without opening a text editor? Office staff with minimal technical background can be trained to implement/manage most of it. 4. It. Just. Works. On commodity hosting no less. Or on expensive enterprise hosting. With little or no assing around with server configuration. There are hosts that have push-button site installation. In short, Drupal is popular for all of the same reasons that PHP still hasn't gone away after almost a decade of developers whinging that it sucks. Is it fun to code for? Nope, not even a little bit. By the time you've written your fourth or fifth custom module 99% of it is the same tired slog through boilerplate code and hook_$N_alter() groveling. Dull, dull, dull shit. And yet I suspect Drupal and Wordpress (which is arguably even worse to deal with) are running way more websites than django, rails, and symphony put together. Look on the bright side, at least it wasn't written in Perl. :)
- justinph 14y ago
  1. Growing by what measure? When I was at Drupalcon 2012 there was a large amount of discussion about how the community wasn't growing and was the same people every year. And I seriously don't mean to be a dick, but passion doesn't equal technical competence. You don't have to be a gifted programmer to understand quality, and understand that Drupal lacks it. 2. There are user groups, I've been to them. They're mostly full of people who have basic problems and a few exasperated and grizzly veterans who offer arcane solutions to non-arcane problems "use last night's dev version of the module, sure it's ok to put php in the database... And the community of drupal.org might exist, but if you can sort it out from the convoluted UX mess that is drupal.org, good luck. 3. Is that supposed to be a feature? In theory, you can get ridiculous amounts of things done if you happen to know the arcane way to combine 30 different checkboxes and twelve different modules. How is this by any objective measure better than writing code? Code is expressive, documentable, concise. Checkboxes and UI interactions are not. 4. This is hardly a unique feature. The same can be said about wordpress, rails, django, etc (at least if you use webfaction) I don't think you can argue under any objective measure that wordpress is more difficult to deal with than drupal. It has many of the same issues as drupal (feature management), but the ease of theming and documentation are lightyears ahead. It's also quite a bit more limited.

vph 14y ago

Years ago, I wrote and published a couple of Drupal modules, which are still being used from time to time. But I moved away from Drupal. With Drupal, you don't learn about building web apps; what you learn is "tweaking" a complex system. You can be building very complex apps nicely, but at the same have no clue about what is underneath.

freshhawk 14y ago

And now we have all the silly arguments comparing web frameworks and CMS's. The CMS people will compare installing modules to writing code from scratch instead of installing a library and writing a bit of glue code. If they don't make that mistake they will probably underestimate how much more flexible, better written and better tested that library will be compared to the CMS module and overestimate how hard it is to glue in a general purpose library. The web framework people will underestimate just how fast it is to install a module into a completely integrated system and underestimate the time they would have spent integrating the library and writing the glue code. They'll also overestimate how often a client needs a piece of functionality that's in any way interesting instead of just a new skin on the same old thing. The answer is "The progression goes: CMS -> Web Framework -> Http related libraries" The question can be any of the following: "What web related stuff has the worst code quality? what has the best?" "How will the tools I use change as I get more experience in web development" "What tools will I use for the most boring web dev work? What about the most interesting?" "What tool skillsets in web development will earn me the most money" "What tool skillsets have the least amount of jobs? what about the most?" "What tools web dev tools will make me want to punch my monitor the most? and the least?" Feel free to come up with your own.

languagehacker 14y ago

Based on my two minutes of salary research I can say that someone with the title "Drupal Developer" make substantially less than someone with a title "Django Developer" (about $10k in SF), and (again, in SF terms), substantially less than the average software engineer without a framework in their title. From what I've seen on job posts over the last couple of years, including the framework in the title is something relatively endemic to Drupal, so I'm assuming that they don't get lumped into "Software Engineer" too often. So let's take compensation out of the discussion. Now let's just list the actual problems with Drupal. It seems like there are as many drawbacks are there are off-the-shelf features when you're making Drupal the core of your own product. It also seems to make a lot of assumptions about your application following a very specific CRM architecture. I'd personally prefer to spend the effort on building out the CRM components myself using a more modular framework so I have more control over the architecture, the version control history, etc. It sort of seems like Drupal tries really hard to set itself apart from WordPress. In reality, it seems the major PHP CRMs all fall into this very narrow point of view on what the responsibilities are of the implementing developer. This minimization of implementation detail promotes a very limited perspective on how a PHP web application works. So now your product's architecture is hobbled by the philosophies of the core library as well as those most apt to develop on it.

Joe_Knapp 14y ago

The problem with Drupal is its lack of human management. There's no one at the helm. It's being run by a bunch of programmers. That's why I gave up on Drupal. When you couldn't do a simple update in Drupal seven, I knew there was a problem. Then they have these other projects going on, like Drupal eight. Seven is not yet stable, then there are people making products for eight. I gave up over a year ago.

room271 14y ago

I wrote a blog on this problem for Drupal a while ago - but with a particular focus on the fact that Drupal has a 'talent problem' precisely because of what the article says (Drupal is not fun for developers and, moreover, fails to promote learning). You can read it here: http://room271.net/2012/05/24/developers-and-drupal.html http://room271.net/2012/05/24/developers-and-drupal.html I worked on Drupal for ~1 year and wrote very little custom code. The caveat is that core developers working at one of the top Drupal shops do get to write interesting code, but they are the exception rather than the norm. ps. still a big fan of Drupal, just don't want it to be my day-to-day work.

gadders 14y ago

I think this applies to a lot of platforms, tbh. It even reminds me of when I was a #embarrassed cough# Lotus Notes developer 12 years or so ago. I think it might be the price you pay for using a "framework". 80% = really easy, the remaining 20% is a git.

cyberswat 14y ago

The beauty of open source is that we have the ability to learn from the experiences of others. Many of the challenges expressed in these conversations are being met head on by the Drupal community. I disagree with many sentiments of the OP but also practice integrating different technologies, when appropriate, to get a job done ... The feedback in this thread is invaluable and highly appreciated. There are technical solutions in the form of modules and organizational workflow solutions that can be used to solve most of the issues I see mentioned here. There are also a lot of false or mis-informed assertions. Thanks for the insight.

saltcod 14y ago

I left Drupal for WordPress because: 1. When it breaks, it shatters—as you said 2. WordPress's UI is so much better for clients, in my experience 3. Theming in Drupal was a nightmare — div.class > div.class > div.class It's such a shame about Drupal. It's so capable, flexible and powerful, but the ui is a tough sell. You can build almost anything with it, but when it comes time to theme and eventually time to hand it off to the client, that's where things got hairy for me.

tombb 14y ago

If you're an engineer/coder building sites by clicking buttons all day, you're in the wrong job. That's not Drupal's fault though. Drupal is a CMS - a powerful one, but not a framework.. At my work we've got a team of "web designers" building websites using Drupal. It allows them to build most of the stuff that clients want for their website/intranet, without writing code. For the more business-logic heavy applications that need to scale and continuously require new features there's a separate team of Django developers. This approach seems to work fairly well: designers get to build pretty advanced stuff they normally wouldn't be able to without some programming help, developers don't get the boring CRUD/shopping cart stuff.

Zelphyr 14y ago

I just spent over a month on a project where we started to use Drupal and I can't see a single thing that is good about it. Poorly written core code. Poorly written modules. Abysmal UI. The only thing I can possibly think that Drupal has going for it is a great community and, as this article mentions, the ability to make a lot of money for little work. Needless to say, a month and a half into the project we dumped Drupal.

Falkon1313 14y ago

1) Drupal's great if you can accept something close to what you want - that has most (but not all) of what you want, plus some stuff that you didn't need. But if you're dealing with perfectionists who want things precisely their way, then you'll spend a lot of time and add a lot of complexity overriding, suppressing, and customizing things and gluing clusters of modules together. Sometimes more than if you'd just built what you needed from scratch. 2) Initial standup can be very quick and easy, especially if you can do it with mostly out-of-the-box stuff (see 1). But over the long-term maintenance and development can be extremely difficult. 3) If you're stuck using designs from designers who aren't skilled with Drupal, theming is likely to be inordinately difficult. Drupal provides a great amount of useful tools and utilities to designers, but if the designer doesn't use them then you basically have to rip them all out and/or override them all and the theme can grow monstrous. 4) The ability for a 'non-technical' user to do so much through the admin interface is a great strength. But the fact that there is so much there in the admin interface (scattered around by the different modules) means that non-technical users often can't (or won't) use it without a thorough understanding of Drupal and the modules. It's too complicated. So you'll need to add time to strip out, simplify, and rework the admin interface. Even then, you may still end up with programmers being tasked with content edits. 5) The database for config+content really is a big issue that majorly affects long-term maintenance and continuing development/deployment on a live site. 'Features' and exportables are not a good enough fix. They're better than nothing, but don't rely too heavily on them. They break down in a lot of cases. D8 promises to be better on that issue...we'll see. 6) Performance really is a problem. For any moderately complex and trafficked site, you have to set up proxies and elaborate caching and etc. etc. just to get "okay, I suppose that's acceptable enough" performance. It can be done, but it's a major headache. That's a tradeoff for the flexibility and modularity. I've built scores of sites in Drupal over the years, and it's a great tool, but it's far from perfect. It's all about tradeoffs, and often the greatest strengths are also the greatest weaknesses. You just have to decide whether it fits what you need. If you can live with the drawbacks, then it's good. If not, then you'll need something else which will have it's own different set of drawbacks.

berkes 14y ago

I think author is switching cause and effect: Move a few paragraphs around and the problem becomes clear. It is right in his article! > Drupal just isn't a great system to code for. And then > No debugging your custom code Proper, well architectured custom code is not hard to debug. At least not anywhere near as hard as debugging Drupalcode. Due to, yup "Drupal just isn't a great system to code for." > No digging through the docs trying to find the API function you need for an odd task "Drupal just isn't a great system to code for." > A discoverable UI--click around until you find what you're looking for, rather than digging through code Hmm. there is a pattern here: "Drupal just isn't a great system to code for." > A team of thousands of users and contributors testing the code in ways you never would have imagined and fixing the bugs Klicking Monkeys testing stuff? Where are the unit-tests? CI? They are there, somewhere in Drupal, but in reality unusable, because, yup "Drupal just isn't a great system to code for." > A much much smaller risk of security breaches due to that team Well, to an extend. But the most security comes from your arcitecture. And 90% of the Drupal-security-anouncements can be tracked back to, yup "Drupal just isn't a great system to code for.". > Holy crap, so much faster Yes. Faster then coding. But that is only true for Drupal, because, "Drupal just isn't a great system to code for.". It certainly is not faster then your average RAD-framework for many, many sites. There may be some cases where Drupal is faster, but only when you don't have to write a line of code, nor need to debug and find why Module Foo and Bar don't work together, because.. well. See above.

dougvann 14y ago

...note... After Mike published the "Golden Handcuffs" post he publicly stated that he did not intend it to be so negative. [yah... I've been there. I start typing and my passion pours out and all the sudden I'm fire up like crazy] So I hope my criticism of this article is pointed in the right direction. ... here goes.... I can not begin to state how much I disagree with the conclusion of this post by @mcrittenden . I believe he feels the way he feels. I believe he has experienced what he says he experienced. But the conclusion is not a typical one. Most of us who are making tremendous earnings in Drupal are NOT bored, unchallenged and lamenting the lack of fun and elegance of coding. We are excited, challenged, evolving, stretched ppl who are having a blast with what we believe to be the BEST community associated with the BEST software out there. [yah... we're pretty biased but THAT is the enthusiasm you run into on a large scale] I am not saying that he's lying. I believe he is telling the truth when he says he's bored and unchallenged and despises the lack of elegance. I liken that to some one who really misses their horse after trading it in for a Model-T. I get it. We did just find for a very very long long time with the horse. Horses are still used today and not just for entertainment but for very real and practical reasons. There's simply NO WAY that some one is going to have a relationship with a car in any similar manner that they did with their horse. I fully respect @mcrittenden and his position here. When ever some one goes on a rant about what they don't like about Drupal [and OH how often this happens!] I find that many of the points are valid and I can not write them off and dismiss them out of hand. Such is the case here. I will say this.... Drupal is a career and a discipline and a community. I encounter some of the same challenges that @mcrittenden does. I don't have the same reaction. I get better and better at this and I have many friends who I can reach out to. Whereas shops have a lot of BRAIN POWER in-house, we independents stick together and hit each other up with those WTF moments. Between all the DrupalCamp, DrupalCons, local UserGroups, Internet Relay Chat, Skype, Email... I'm very connected to the community and I get answers to my questions when ever I need them. If I know an area of development is going to be extra challenging.. I will factor in some room to pay my friends who know things I do not. Yah... We get freebys from each other ALL THE TIME but I really love it when I tell some one I have a couple hundred bucks to spend on them to teach me something or to architect a solution. I've even spent thousands like this before. I knew the client had needs and I connected them with another shop to handle a very specific piece of the puzzle. It worked well for all concerned. And by the way... this was FUN and Challenging and the solution was very Elegant. CONCLUSION: I DEFINITELY run into issues with Drupal from time to time. Just like sharepoint and vignette and ez-publish and auto-mechanics and horse-handlers do. My reaction is a little different. I have made the choice long long ago that DRUPAL is my vehicle. I don't want to use Joomla like I used to. I don't want to use Sharepoint like I started to and was studying in 2007. I chose Drupal. Now that I have made that choice I am enjoying great money and great challenges and an even greater community. Our system has its quarks; some are minor and some not so minor. Regardless, this is the path I'm on. We, the community, are continuing to improve "this area" and "that area" and yes I'll even agree that some areas are getting a little worse with each release. This is no secret and I'm part of two different teams that are assessing the situation and proposing action and then encouraging and seeking funds for that re-action. We're seriously on a roll here with this stuff. @mcrittenden I get it, man. This stuff [called Drupal] can ROYALY piss a guy, or gal, off at times. But what you describe as boredom and click monkeys is a drastically inaccurate description of what I, or anyone I know, do for a living. I do know of many HOBBYIST Drupalers who just want to point and click and they are using Drupal as an overgrown geo-cities but I know that's not who you're talking about here. I really appreciate the article! This global conversation is sparking other conversations that are enacting change! So.. THNX! Doug Vann [Drupal Trainer, Consultant, Developer] http://dougvann.com http://dougvann.com

nearly 14y ago

the article refers to being bored. any drupal dev who is bored because they are talented and unchallenged should be contributing to core development. the OPs d.o profile shows contribution but not focused on a particular core initiative. the employer could be giving time over for that. contribution is satisfying and challenging. and much needed!!

nearly 14y ago