Drupal's Golden Handcuffs • Hacker News Board

Re: Drupal's Golden Handcuffs

#101

Post by ZoFreX » Wed, Oct 03, 2012, 8:35 AM UTC

tedsuo wrote: post #25

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 s…

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.

Re: Drupal's Golden Handcuffs

#102

Post by kalms » Wed, Oct 03, 2012, 8:52 AM UTC

dasil003 wrote: post #31

lkrubner wrote: post #6

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 li…

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 s…

> Where is this elite Drupal employment world that the OA speaks of?

Drupal is fairly big here in Scandinavia, and it's my distinct impression that it's the same story all over Europe. It has a strong footing within online media that seems to grow every day.

I suspect that if I moved to another country, or even abroad, I wouldn't have much difficulty finding a different (high paying) job related to Drupal.

Also, if you're US based and like great community oriented dev houses: www.acquia.com, www.lullabot.com or www.palantir.net.

Re: Drupal's Golden Handcuffs

#103

Post by Daniel_b » Wed, Oct 03, 2012, 8:54 AM UTC

tedsuo wrote: post #25

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 s…

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

Re: Drupal's Golden Handcuffs

#104

Post by skrebbel » Wed, Oct 03, 2012, 9:09 AM UTC

kalms wrote: post #94

debaserab2 wrote: post #91

Earlier quoted context omitted.

Yeah, those non-developer's you're talking about? Most of them have no idea how to change a view, because changing a view is pretty much just as complicated as coding a SQL query. If you understand how to modify a view, you probably can write an SQL query. The benefits of having a UI to manage core application behavior is lost on most clients. Most are terribly scared of editing a view, content type, or pretty much a…

Our clients know it pretty well - it's all about education. The button's called "revert" for a reason, and it's placed pretty prominently on the page. When we removed the fear of fucking up, they started learning.

Genuinely curious: your clients hack around with Views on their on production site?

I'm not sure whether I think that's insane, or whether I'm simply very jealous of your clients.

Re: Drupal's Golden Handcuffs

#105

Post by gadders » Wed, Oct 03, 2012, 9:22 AM UTC

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.

Re: Drupal's Golden Handcuffs

#106

Post by mtts » Wed, Oct 03, 2012, 9:31 AM UTC

mechanical_fish wrote: post #88

mtts wrote: post #81

Earlier quoted context omitted.

Typical Drupal FUD. "Configuration lives in configuration tables" : the OP's point exactly. Configuration should live in a VCS Bear in mind also that "configuration" van be so complex with Drupal it's often more along the lines of being "an application". A non-trivial view is hugely complicated and yet all its settings and code live in the database entirely, with no way to either back it up in a VCS or deploy it from…

Views, specifically, have been exportable into version-controlled code since Drupal 5, and the ability to do so is a prominent feature in Views v3 for Drupal 7. Indeed, the Feature module, which spearheaded the current effort to make every Drupal configuration setting expressible in version-controlled, script-deployable code, is based on a pattern invented by Views years ago.

Exporting views to code has been shaky at best. And worse: once it's exported to code, there is no way to only import the bits that have changed. You must recreate the whole thing anew.

That's not version control, that's an export function.

Re: Drupal's Golden Handcuffs

#107

Post by dasil003 » Wed, Oct 03, 2012, 10:48 AM UTC

w4y2 wrote: post #43

dasil003 wrote: post #31

Earlier quoted context omitted.

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 s…

It appears you don't really understand the Drupal theming layer.

You created a new account just to post this ignorant snark?

My Drupal knowledge is well out of date, but the indisputable fact that the Drupal architecture like all software architecture imposes assumptions, many many more assumptions than a low-level framework like Rails (which tries to keep its assumptions as broadly applicable to all HTTP usage as possible). These assumptions imply tradeoffs. If you think there are no tradeoffs you need to step back and realize that Drupal has corrupted your mind and the limits of your web development ability will be constrained by whatever ideas Drupal core is able to harvest and integrate from the wider world of web development.

Re: Drupal's Golden Handcuffs

#108

Post by dasil003 » Wed, Oct 03, 2012, 11:13 AM UTC

debaserab2 wrote: post #93

lotyrin wrote: post #87

Earlier quoted context omitted.

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 f…

> And while PHP's is trying hard (see the other story on the front page at the moment) to modernize, the tools and ecosystem still don't compare to Ruby or Python. What do the current offering of PHP frameworks lack that Python/Rails provide?

I'm not going to claim up-to-date in-depth knowledge of the PHP ecosystem since my daily work ended in the 4/5 transition era, 6 years ago. So PHP is loads better, I'm sure, but I've seen the announcements of new features such as namespacing and closures, and it's clear that this stuff is shoehorned into the language and good use of these features is not ingrained into PHP culture.

In the case of rails, beyond the easily copyable superficialities of the MVC pattern, simple ORM and HTTP helper methods, what you have underneath is the elegance of the ruby OO model.

The ruby OO model with its mixins, implicit metaclass (eigenclass), and dynamic nature (ie. class definitions are just executable code), and standard functional features like lambdas w/ closures are all designed into the language in a very elegant way and this basic model has been more or less stable for the nearly 20 years of ruby's existence.

This means ruby code has a more consistent style and set of powerful idioms over time. Obviously there's a lot more shit ruby code getting written these days then there used to be, and modern PHP has a ton of power that can be leveraged very elegantly. However if you look at the corpi of popular open source ruby code vs popular open source PHP code over the years, you find a much higher bar of quality in the ruby code. Some of the attraction to the average rubyist is aesthetic, but that's not the whole story.

Re: Drupal's Golden Handcuffs

#109

Post by fungi » Wed, Oct 03, 2012, 11:39 AM UTC

mechanical_fish wrote: post #90

fauigerzigerk wrote: post #84

Earlier quoted context omitted.

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. T…

Drupal's Features module tends to use this pattern: The code defines the default configuration. If the user changes the config using the UI, the change gets written to the database. At the same time, a little telltale light (or something) tends to appear in the UI display, to alert the admin that something's been changed on the site, but not in the code. Your developer can then come along and pull a report that lists…

I do this all the time:

  drush up feature_name
  git commit -a

this gives you a nice diff of the config in production v's code.

  drush fd feature_name

sometimes i really need to make a fix in production (or its so trivial the overhead of a release would be just silly), make the change on production, then grab fresh db dump, stick it on dev box and run "drush up". today i did this to remove a link from a field in a view.

Re: Drupal's Golden Handcuffs

#110

Post by cyberswat » Wed, Oct 03, 2012, 11:46 AM UTC

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.