My Woes with Drupal

drupal.mdown

Hokay, please keep in mind I know nothing about Drupal 8, so much of what I comment on here may well be problems that are already being addressed or have been solved therein. AGAIN: If I make a poopoo face at something that has been rectified in D8, please don't be terribly irritated at me!

I am a longtime D6 dev, and have been working in D7 for the past few months, as well.

Core issues as I see them in terms of the mobile Web and the pan-device Web as a whole:

• Controllers need to be separated from template/view layers in so much as is possible. There is still too much munging between page callbacks/action and the rendered response. I think this is sort of part of what render arrays aim to ease in D7, but render arrays are complex and abysmally documented. I have asked around and no one can find true documentation on them. They're far too convoluted to figure out on one's own unless one has a lot of time, which I sadly do not.
• Let me clarify: I believe in the kind of idea that a render array represents. But it needs to make sense :).
• The theme layer has too many abstracted layers and yet doesn't perform what I think it intends to. Stop making it a requirement to configure so many things. More auto-detection. If there is a tpl.php for the hook, use it. I shouldn't have to mention it in my hook_theme. Or at least fix the core irony! I'm required to define template name for my hook but the only name that will work is the name of the hook (with underscores translated to dashes). That's humorous.
• The form API needs to be rethought and view-layer stuff pulled out. Every time I '#title' => t('My form field name') in a $form array I die a little bit inside. In fact, every time I see t() I ask myself if it's an opportunity to move whatever it is to a view layer.
• Basically, I feel that configurable content exists at a layer where people who interact with modifying and customizing content work. That tends to be on the HTML/templating layer, not in the module logic or in controllers.
• Routing and menu stuff. I desire support for HTTP verbs. I would like systematic routing for resources. Trying to cram REST into Drupal is tear-inducing.
• All of these things pale when viewed against the reality that the Drupal database conflates configuration data and content. That above all needs to be solved. Management and deployment of Drupal instances is a world of pain. I'd like to be able to move my content around between environments without carrying a lot of environment-specific data with it. EDIT: Amye Scavarda has let me know I'm ignorant of the Configuration Management initiative in D8. Sounds like a move in the right direction!
• The other nightmare is the balance between filesystem and database-based content and settings. The kind of stuff that the good ol' features module and its ilk tried to start addressing years ago. I'm seeing woefully little progress in this area, and I am sad about it!
• Too hard to manage my page delivery mechanisms. I want to be able to render my template/view layer in whatever way makes sense for the consuming client. Recently I had need to return AJAX partial views. In this case I just wanted to return rendered HTML strings that represented those partials, for injection into the page. This sent me down a long path of hacking via hook_page_delivery_callback_alter as D7 insists on returning JSON (not HTML) for XHR requests. This was too hard. And now I face the same exact situation in that I want to return some Content-type: application/atom+xml data (that is: ATOM/feed flavor of a resource also available in HTML). I got so daunted that I just had my page callback fling out a Content-type header, render the ATOM and exit(). And yeah, I know that is totally wrong.
• Some sort of ORM or abstracted, useful data persistence layer would sure be nice. Reinventing that wheel got old about the ninth time I did it :). I think I maybe heard this is in the works for 8? Would sure make coding resource-based web apps a lot faster.