Drupal's Golden Handcuffs • Hacker News Board

Re: Drupal's Golden Handcuffs

#131

Post by fungi » Wed, Oct 03, 2012, 9:03 PM UTC

fungi wrote: post #109

mechanical_fish wrote: post #90

Earlier quoted context omitted.

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.

woops... "drush up" should be "drush fu"

Re: Drupal's Golden Handcuffs

#132

Post by knieveltech » Wed, Oct 03, 2012, 9:12 PM UTC

apendleton wrote: post #127

knieveltech wrote: post #122

Earlier quoted context omitted.

"Being able to export and commit isn't really good enough; keeping a work log is only a relatively small part of the capacity for version control systems to expedite development. Many projects have development workflows where new features are developed in branches, and only merged when they're ready to be deployed." Features, exportables, Strongarm (et al) are all compatible with the workflow you're describing. Our d…

"Field declarations for a single content type strewn across multiple features? Why?" Sorry for the confusion; I meant lower-case "features," as in, new pieces of functionality that both affect the same kind of data, not "Features" in Drupal terms. I don't think it would be especially unusual for multiple feature branches to affect the same content type in different ways. "Who claimed Drupal was object oriented? Serio…

Thanks for clarifying. At time of writing the only two data types that are routinely and consistently cast as objects in Drupal's codebase are users and nodes. The comical thing is neither have methods assigned and can just as easily be cast as associative arrays (like everything else).

Outside of core, contrib has gotten quite object oriented over the last few years as Views, Panels, Simpletest, Ctools (etc) are all heavily object-oriented and the popularity of these modules has driven a lot of other contrib module development that in turn is required to take an object-oriented approach to interact smoothly with these modules.

Still, attempting to claim Drupal is in any way object oriented is like hot gluing a handful of feathers to a basketball and calling it a chicken.

Re: Drupal's Golden Handcuffs

#133

Post by jasey » Thu, Oct 04, 2012, 4:09 AM UTC

smacktoward wrote: post #69

emmelaich wrote: post #52

Earlier quoted context omitted.

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

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.

In my wp-config.php file I have the following logic

https://gist.github.com/3831423

Re: Drupal's Golden Handcuffs

#134

Post by Falkon1313 » Thu, Oct 04, 2012, 4:35 AM UTC

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.

Re: Drupal's Golden Handcuffs

#135

Post by Falkon1313 » Thu, Oct 04, 2012, 4:56 AM UTC

chx wrote: post #98

rybosome wrote: post #89

Earlier quoted context omitted.

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.

So in order to "print $person->first_name;", you must first create formatters, display modes, and templates? Point goes to the one who's saying that it's overly complicated. Drupal makes it easy to do difficult things, but infuriatingly difficult to do simple things.

Re: Drupal's Golden Handcuffs

#136

Post by [deleted] » Thu, Oct 04, 2012, 4:56 AM UTC

chx wrote: post #98

rybosome wrote: post #89

Earlier quoted context omitted.

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.

[deleted]

Re: Drupal's Golden Handcuffs

#137

Post by [deleted] » Thu, Oct 04, 2012, 4:57 AM UTC

chx wrote: post #98

rybosome wrote: post #89

Earlier quoted context omitted.

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.

[deleted]

Re: Drupal's Golden Handcuffs

#138

Post by [deleted] » Thu, Oct 04, 2012, 4:57 AM UTC

chx wrote: post #98

rybosome wrote: post #89

Earlier quoted context omitted.

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.

[deleted]

Re: Drupal's Golden Handcuffs

#139

Post by berkes » Thu, Oct 04, 2012, 4:43 PM UTC

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.

Re: Drupal's Golden Handcuffs

#140

Post by berkes » Thu, Oct 04, 2012, 8:23 PM UTC

Daniel_b wrote: post #103

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…

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