Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Drupal's Golden Handcuffs

mikecr.it

Post reply on HN
Print view View original

91–100 of 148 posts

Re: Drupal's Golden Handcuffs

#91

Post by debaserab2 »

knieveltech wrote: post #75
apendleton wrote: post #74

Earlier quoted context omitted.

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…

"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" And that, in a nutshell, describes why Drupal's adoption rate is as high as it is compared to development frameworks developers actually enjoy working with. No fucking code. Non-developers can actually get result…

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 any other module specific configuration. I speak from the experience of someone whose developed about a dozen or so Drupal sites.

Re: Drupal's Golden Handcuffs

#92

Post by mechanical_fish »

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?

http://www.acquia.com/customers

Just one subset, of course. Doesn't include customers of other major vendors.

Re: Drupal's Golden Handcuffs

#93

Post by debaserab2 »

lotyrin wrote: post #87
mtts wrote: post #82

Earlier quoted context omitted.

"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 develop…

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?

Re: Drupal's Golden Handcuffs

#94

Post by kalms »

debaserab2 wrote: post #91
knieveltech wrote: post #75

Earlier quoted context omitted.

"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" And that, in a nutshell, describes why Drupal's adoption rate is as high as it is compared to development frameworks developers actually enjoy working with. No fucking code. Non-developers can actually get result…

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.

Re: Drupal's Golden Handcuffs

#95

Post by lotyrin »

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?

It's not about frameworks so much as whether people use them. In Python and Ruby, pretty much everyone knows to look for useful gem or pip packages and uses frameworks and does a good job of avoiding reinventing wheels. In PHP, there's still a lot of old-guard cowboys and new blood that want to emulate them which aren't participating in the ecosystem, so the availability and quality of reusable code isn't there yet.

Re: Drupal's Golden Handcuffs

#96

Post by room271 »

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

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.

Re: Drupal's Golden Handcuffs

#97

Post by lotyrin »

fauigerzigerk wrote: post #84
apendleton wrote: post #74

Earlier quoted context omitted.

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…

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…

On a site that is version controlled and has a QA workflow for changes, you simply disable the UI for changing those things on production, and the only way to influence them is by committing the changes exported as code and deploying.

The UI is enabled on development environment, allowing for extremely quick experimentation (possibly by non-technical folk), but you still get (most) of the benefits of changes being in code.

ETA: It's not perfect, but it's on it's way to becoming the best of both worlds. Drupal 8 is making significant progress in that direction.

Re: Drupal's Golden Handcuffs

#98

Post by chx »

rybosome wrote: post #89
chx wrote: post #47

Earlier quoted context omitted.

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.

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

I still say this: If your node.tpl.php contains field_get_items or equivalent, you are doing it wrong, on a very fundamental level. If the formatters provide too much HTML, write your own, write a proper field.tpl.php etc.

Re: Drupal's Golden Handcuffs

#99

Post by lotyrin »

mtts wrote: post #81
knieveltech wrote: post #67

Earlier quoted context omitted.

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

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…

All of the configuration for my Drupal sites DOES live in a VCS (it just doesn't have to, and many people don't bother).

Drupal 8 is continuing to make this easier and more powerful, by (amongst other changes) making configuration live in the filesystem by default, turning the copy in the database into (one of several options for) a cache.

Re: Drupal's Golden Handcuffs

#100

Post by lotyrin »

mmcnickle wrote: post #85
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…

Such is the inner platform effect. I would happily bet there is someone working on a drupal-specific, poor substitute for version control.

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.
Post reply on HN