Drupal's Golden Handcuffs • Hacker News Board

Re: Drupal's Golden Handcuffs

#51

Post by Pwnguinz » Wed, Oct 03, 2012, 1:54 AM UTC

jackbravo wrote: post #24

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?

it all depends. Example, if you want to assign a role to a new user when he signs up you can install http://drupal.org/project/autoassignrole module which does about 10 more things or just write one hook_user function. If you install a module for every piece of functionality soon you'll end up with a huge codebase and the hell the author is describing.

You are responding to the author ;).

That said, I wholeheartedly agree.

Did Drupal dev for 2 years, and my biggest takeaway was: Don't go around installing custom modules for one dinky feature. Wrap it up in your own custom module.

Less dependency hell to deal with, and not only that, you'll have a much easier time debugging code you wrote yourself.

Re: Drupal's Golden Handcuffs

#52

Post by emmelaich » Wed, Oct 03, 2012, 1:57 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…

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

Re: Drupal's Golden Handcuffs

#53

Post by jackbravo » Wed, Oct 03, 2012, 2:01 AM UTC

w4y2 wrote: post #41

jackbravo wrote: post #36

Earlier quoted context omitted.

This is why 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 is what makes a lot of the drupal distributions ( http://drupal.org/project/distributions ) that keep popping up because sourced controlled, feature driven development is now possible in drupal. Also the testi…

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

Right, features is not perfect. Upgrading a feature from D6 to D7 has been a pain to me.

I've merged features together and it was not as hard, at the end it is all code, you just need to be very careful, but at the same time you have git to revert if something goes wrong.

I don't understand the part about committing just one feature. You can commit just one =P.

Re: Drupal's Golden Handcuffs

#54

Post by jackbravo » Wed, Oct 03, 2012, 2:03 AM UTC

vaporstun wrote: post #49

w4y2 wrote: post #41

Earlier quoted context omitted.

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

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

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.

Re: Drupal's Golden Handcuffs

#55

Post by jacques_chester » Wed, Oct 03, 2012, 2:04 AM UTC

This all sounds like my $dayjob with Oracle Application Express.

Except that ... you know ... people have heard of Drupal.

Re: Drupal's Golden Handcuffs

#56

Post by exratione » Wed, Oct 03, 2012, 2:05 AM UTC

w4y2 wrote: post #41

jackbravo wrote: post #36

Earlier quoted context omitted.

This is why 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 is what makes a lot of the drupal distributions ( http://drupal.org/project/distributions ) that keep popping up because sourced controlled, feature driven development is now possible in drupal. Also the testi…

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

Features is indeed the answer, and all of the potential issues are manageable.

I finished up a project earlier this year that has more than 300 modules active in a custom install profile, with 10MB of features modules stuck in there. We committed/contributed to a few fixes in core and Features to speed it up greatly. That's out in the wild on major sites and doing fine.

We didn't have any terrible admin screen issues, or indeed any terrible issues beyond occasional painful version control collisions.

Re: Drupal's Golden Handcuffs

#57

Post by exratione » Wed, Oct 03, 2012, 2:09 AM UTC

jtreminio wrote: post #30

exratione wrote: post #12

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

What would you recommend an experienced developer coming into Drupal do to land in group A?

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

Re: Drupal's Golden Handcuffs

#58

Post by hippich » Wed, Oct 03, 2012, 2:09 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…

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! :)

Re: Drupal's Golden Handcuffs

#59

Post by hawtshot » Wed, Oct 03, 2012, 2:11 AM UTC

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.

Re: Drupal's Golden Handcuffs

#60

Post by ams6110 » Wed, Oct 03, 2012, 2:27 AM UTC

mcrittenden wrote: post #19

patrickocoffeyo wrote: post #14

Earlier quoted context omitted.

Yes, and amen. All people who are afraid to write code need to stop using drupal.

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.