Drupal's Golden Handcuffs • Hacker News Board

Re: Drupal's Golden Handcuffs

#81

Post by mtts » Wed, Oct 03, 2012, 6:39 AM UTC

knieveltech wrote: post #67

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 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 a development environment to a live environment without manually copying the settings from one to the other.

Re: Drupal's Golden Handcuffs

#82

Post by mtts » Wed, Oct 03, 2012, 6:44 AM UTC

lotyrin wrote: post #70

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

"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.

Re: Drupal's Golden Handcuffs

#83

Post by mtts » Wed, Oct 03, 2012, 6:49 AM UTC

ams6110 wrote: post #60

mcrittenden wrote: post #19

Earlier quoted context omitted.

There's a difference between beinf afraid to write code and avoiding reinventing the wheel. If there's a Drupal module that gives you what you need, why would you not use it?

A lot of the smaller drupal modules are unmaintained, buggy, or just plain don't work. Drupal advocates like to brag about the thousands of developers and modules in the ecosystem, but the truth is only the core modules and the most widely used contributed modules are production-worthy.

That, and even core-ish modules are maintained in a manner that's just plain unprofessional (I'm looking at you, Ubercart / Drupal Commerce): "Hey, there's a new version of Drupal Core! Let's drop development of (and support for) the current version of Ubercart that people are actually using and start writing a completely new cart system from scratch!"

Re: Drupal's Golden Handcuffs

#84

Post by fauigerzigerk » Wed, Oct 03, 2012, 6:51 AM UTC

apendleton wrote: post #74

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…

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. There is room for a new type of CMS database design that includes all the functions of a VCS.

Re: Drupal's Golden Handcuffs

#85

Post by mmcnickle » Wed, Oct 03, 2012, 6:55 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…

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

Re: Drupal's Golden Handcuffs

#86

Post by Joe_Knapp » Wed, Oct 03, 2012, 7:07 AM UTC

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.

Re: Drupal's Golden Handcuffs

#87

Post by lotyrin » Wed, Oct 03, 2012, 7:08 AM UTC

mtts wrote: post #82

lotyrin wrote: post #70

Earlier quoted context omitted.

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

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

Re: Drupal's Golden Handcuffs

#88

Post by mechanical_fish » Wed, Oct 03, 2012, 7:09 AM UTC

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…

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.

Re: Drupal's Golden Handcuffs

#89

Post by rybosome » Wed, Oct 03, 2012, 7:10 AM UTC

chx wrote: post #47

rybosome wrote: post #42

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…

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

Re: Drupal's Golden Handcuffs

#90

Post by mechanical_fish » Wed, Oct 03, 2012, 7:18 AM UTC

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…

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 any configuration that's been changed in the UI but not migrated to the code. Pressing a button spits out a code-based representation of that configuration. The developer finds the right file, pastes in the config change, checks into Git or SVN. Now the config is once again captured in code, and ready to be deployed in a consistent manner.

I'm not sure if the Drupal 8 team is using this pattern or something different. Still trying to catch up with this stuff.