4 ms·
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 pa
by rybosome 14y ago
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 next to all comments, AND have a YouTube video feed!" that finding documentation on actual code is extremely challenging.
Another aspect of the project that was difficult was that the client had very specific needs. In almost every piece of functionality they requested, there was some wrinkle that made using an off-the-shelf module impossible. This meant having to code against the behemoth Drupal API. After about 3 months of work, I created an OO-wrapper module around Nodes called Doodal (https://github.com/rybosome/doodal https://github.com/rybosome/doodal) that makes it possible to code in an MVC-like way. This made the rest of the project somewhat easier, minus the parts that involved interfacing with native Drupal. Drupal was created at a time when PHP didn't have object oriented features. Their solution to the problem of needing OO-like behavior but not having it was to emulate it, which is an abstraction that quickly falls apart. For instance, the shortest line of PHP you could possibly write to simply print out an optional "first name" value from a node representing a person is...
array_key_exists('und', $person->first_name) ? $person->first_name['und'][0]['safe_value'] : '';
While I was wrapping up this project, a friend of mine pointed me to an opening his company had for a Drupal dev, paying about 1.8x what I was making at the time. I declined without even thinking about it, and have not regretted it for a second.
- chx 14y agoFirst, 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.
- rybosome 14y agoThe 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.
- chx 14y agoI 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.
- Falkon1313 14y agoSo 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.
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]