Using less Drupal

Lately, I’ve had various frustrations with Drupal which have moved me away from using it for various things. I’d like to go through where I’ve moved away from Drupal, why I’ve made those changes, and my future Drupal decisions.

WordPress rather than Drupal blog

To begin with, this blog is now on WordPress rather than Drupal – and I have to say that I’m loving it… and so are my non-geeky colleagues. It ticks all the right boxes. Its *really* user friendly. Its much easier to add photos (and videos) to posts. And it’s hardly taken long at all to setup.

So where did Drupal go wrong with this? Well, I guess its the ‘kitchen sink’ approach back-firing. In trying to be something to everyone, Drupal runs the risk of being less than perfect to to any one specific task too. WordPress, on the other hand, has the ability to focus on being the very best blogging software out there, and nothing else gets in the way of that or deters it from its ultimate goal.

But also, we needed to seaparate the business end of our website (the creation of yearbooks, using tens of thousands of nodes) from the nodes and users to do with the blog, partly because around this time every year we flush out the old site and start a new. So we were either going to have a separate Drupal install for the blog or use WordPress. We chose WordPress.

Form theming frustrations

Have a look at the form here and let me know how you’d create it using FAPI (we’re on Drupal 6.4). I’m talking specifically about the theming of the form. Yes, its a very simple form. A search form. But let’s have a look at what’s going on with it and discuss the Drupal way versus the way we ended up doing it.

In FAPI, you’d probably have a ‘textfield’ element for the search box and a ‘submit’ element for the ‘Go’ button. Easy enough, one minute of code. But what about the title ‘Name of your school or group’? Probably a title for the textfield element, no? But then how do we get it centred above both the textfield and the submit button? And what about the text under the two fields? A description, right? Again… how do we get it to appear *exactly* where we want it? The look and feel of the form are to me absolutely crucial. I don’t just want a textfield’s title (with annoying colon after it), a textfield, a description, and then a Go button all one on top of the other.

The Drupal solution? Using a theme hook. We define the form in our implementation of hook_form() and then theme that form separately. The ‘programmer’ cares about the functionality of the form but not the visual design of the form. The ‘designer’ doesn’t care about the functionality and instead works on how it looks. But I’m both the programmer and the designer here, and I want my work to be as easy as possible! So, let’s say i go down this route (I tried, I really did). I need to register my theme function in hook_themes(). Okay, I know why, it saves extra code running on every page load. But its still annoying. Now I create my theme function… urgh. You’ve got to really know your FAPI stuff to get this to work. I try for a while but then I give up. It just feels so messy with some code somewhere, some in another place, and then when I ask my colleague to have a look so he can learn how to do it he’s disgusted… doesn’t know what’s going on… starts bad-mouthing Drupal. So we build our own massively simple FAPI instead in about half an hour that does just what we want it to do.

So now we’re using our own super-basic FAPI for this form. Not all forms, just the ones we want complete control over, visually. Rather than using hook_form() and defining a form array, we just hard-code the HTML for the form. Some of you may be in complete horror now thinking about this but its just by far and away the easiest way to get forms to do exactly what you want. Like a forename and surname field side by side rather than one on top of the other, sharing the title ‘Name’ which is a label for the forename field.

We’re sticking with the idea of a validate() and submit() hook though. I like that one. But we’re doing it slighly differently and more simply, so that any new coders we might hire can quickly and easily pick it up.

Going nodeless

I don’t always like nodes. I really, really don’t. I don’t need revisions, and if I did I’d do them in my own way, just the right way for me, rather than a way that kind of works for everyone but not quite perfectly for anyone in specific. I don’t like the way that as uid=1 I get all the extra bits like ‘Authoring information’ which I never touch. Node hooks and the nodeapi which I once loved are now a higgeldy-piggledy mess that’s a real pain for my new hire. I try to explain to him what’s going on when I save a node. “So this function deals with the submission. But not the core node stuff, Drupal deals with that. And if we want something used for all nodes, we put it in here instead. And we can also override this specific bit here.”… he looks on in amazement, totally baffled by what’s going on and why. It would be so much easier for him (and me) to understand if everything’s just in one place.

So what do we gain from nodes? Umm… not much really. We don’t use contributed modules any more because they never do exactly what I want and always do stuff which I don’t want them doing which just make them less efficient. We put all our code in our own one module instead. A massive, hefty module with a dozen or so include files.

We gain the ability to always do $node->nid and use node_save() and other handy things. But we don’t really need nodes, and it frustrates me having to do the extra INNER JOINs on node_revisions etc. So we’re trialing not using nodes at all for one of our content types – our customers. We just have a simple ‘id’ field now in one single table. We no longer need to INNER JOIN node and node_revisions. We haven’t had any problems so far, but the new hire is finding it much easier to code now, without the ‘baggage’ of Drupal.

The future

Our current plan is to gently migrate away from Drupal, perhaps altogether. We like the idea of building our own framework again, one that does exactly what it needs to do for our site. Its not something we can do overnight. Ours is a yearly cycle, following the academic year, and the current plan is to fork the codebase in around January/February and that would mark the beginning of our own framework if we still feel that way then.

In the meantime, we’ll continue using nodes for most of our content types (if simply because migrating away from them would be a long and arduos task with little reward) and we’ll continue to use FAPI for most our forms. But I see us using our own simple FAPI for more and more forms where we need complete control over them, and I see us extending this FAPI to help us reduce using the same code multiiple times.

I think I still like Drupal. I definitely appreciate the vibrant community. But sometimes I thoroughly hate Drupal and get massively frustrated by it. But I still like it in theory at least. One framework for all my websites. But whilst I just work on one massive website it just has so much less use to me.

You’re more than welcome to urge me to stay with Drupal. In fact, I highly hope someone can manage this. I’ve put a lot of time over the last few years into learning Drupal, and it would be a great waste and a shame to lose all that.

20 thoughts on “Using less Drupal

  1. Pasqualle says:

    we’re using our own super-basic FAPI

    can you release the module on drupal.org?

    Drupal is absolutely different to any other framework, you need to learn it. But when you know how it is working and why it is working that way, you don’t want to use anything else.
    Please, try to write your own framework. I will see you back in Drupal within a year, I am sure.

    I see one big problem with your development practices: you do not work with the community. You try to create everything on your own. That’s not working. Drupal development is faster than anything you can accomplish, you will be left behind..

    Like

  2. Ronald says:

    I think you make an excellent point about what exactly are the problems of using Drupal. It does force you to do some things in very “verbose” ways and if you have a relatively specific task to achieve that does not change year after year then your own framework is probably the best option.

    Where Drupal shines, I think, is as a tool for a web agency that every month needs to deal with very different kinds of websites and can quickly put them together using Drupal’s flexibility rather than coming up with different versions of custom-made tools for each website.

    As for WordPress’s user-friendliness when compared to Drupal – it’s just true. I cannot believe anyone can make a valid argument for Drupal in that arena!

    Like

  3. Matt Farina says:

    Thanks for sharing your frustrations in a way that does more than complain about them but actually explains them. That all too often doesn’t happen.

    WordPress really is a top of the line blog engine. I’m a fan even though I rarely use it. Usability is high and it’s easy to do since it has a one purpose (or mostly so) target. You’ll find many examples of sites run on drupal but their blogs are on wordpress. (for an example check out blog.nowpublic.com)

    When if comes to your form issues I’m not exactly sure where your issue is. I took a look at your form and the same look is something that can be achieved with FAPI, a tweak in the template.php (to remove the :), and some css magic (no crazy theme functions required). A suggestion, no matter which way you choose to go, might be to invest more in CSS.

    I understand not all objects being nodes can make a difference. For many use cases this is very true which is why I’m looking forward to drupal 7 with it’s new PDO database layer that should make this easier (and support lazy loading). On this front I tend to use the Zend Framework (sometimes teamed with drupal – http://drupal.org/project/zend). If things keep on pace, drupal 7 should (hopefully) be much better with data sources other than nodes.

    There are a lot of other frameworks to choose from. I’ve worked with Zend, Symfony, django, and others. Before you go elsewhere take a good look at what’s out there and what it’s like in use with real problems and creating real solutions. I’ve found the grass isn’t always greener on the other side.

    Good luck in your search. I hope it’s a fruitful one.

    Like

  4. aka006 says:

    I nominate you for a position on the Drupal Association Board;) I’m sure there are lots of people that feel the same as you (including myself) that end up leaving drupal after a couple of years due to frustrations. Yes Drupal rocks as it offers cutting edge innovation, but new apis every year with each release cycle I can’t keep up any more!!!

    Like

  5. Craig says:

    As a tech consultant we’re always going to be faced with the problem of build from scratch vs. use a framework / existing system. Each has its pros/cons.

    When you use an existing system / framework you sacrifice some flexibility for speed of development. It all depends on the priorities. What features are critical and what can you sacrifice.

    Frameworks, Drupal especially, tries to be more of the kitchen sink. It wants to be every tool in the toolbox. If you only need a hammer (i.e. blog) then Drupal can be overkill. Use WordPress.

    I often times wish that Drupal provided a framework that integrates with other tools instead of trying to be every tool.

    From your description above, it sounds like building something on your own may be the way to go. Some of your particular needs make Drupal more difficult to use. If you’re only using a fraction of what Drupal provides, then go down the build from scratch route. Just make sure to consider the costs of building and maintaining enhancements, patches, testing, etc. compared to that of Drupal.

    Good luck!

    Like

  6. steve says:

    I was just cursing Drupal last night as I was up against a deadline and could not get Drupal to cooperate. Like you, I did the unthinkable and wrote a bunch of inline code in blocks and page.tpl.php just to get things working the way I wanted. It can be totally maddening when things don’t work the way they should (or the way I THINK they should), but for now I’m sticking with it because it really allows me to bring sites up pretty quickly with just a few modules and some theming.

    Like

  7. Wim Mostrey says:

    I wonder if you ever looked from help on the Drupal.org forum or on irc with your issues? For instance I don’t get why you would ever write a query that INNER JOINs the node_revisions table. If you want to load a node, use node_load(). If you want to load a list of nodes, use views or get their nids in a query and use node_load() on it. Also, theming that form is really easy since you’re basically putting the html code in there with a drupal_render() call for each field. It shouldn’t look all that different from your custom code.

    If you don’t like nodes, the nodeapi and formapi, then perhaps you shouldn’t be using Drupal in the first place. I’m glad that WordPress fits your needs.

    Like

  8. Marc Robinsone Caballero says:

    I think this is a great review. It brings good defense to the frustrations of many who were caught-in-the-act of making systems work for them.

    You see, making the system WORK FOR YOU is definitely wildly different from making a system WORK WITH YOU.

    But seeing that open source software is pretty dynamic (such as Drupal) it is really a must to choose the best package that will match the requirements (yours or the client for that matter).

    There are plenty of frustrating facts about Drupal and some people in the Drupal community (same is true for other software communities) but in the end, being able to know when to quit, come back, and represent your opinion in a good respectable way is all that matters.

    Overall, don’t expect people to stop you from using Drupal. They won’t even bother.

    Like

  9. Jacques says:

    Every users have different needs.

    I come from a world where WordPress and other CMS where the kings and queens. But since I discovered the Drupal platform, I cannot go back to WordPress or any other simple CMS.

    I agree, mastering Drupal is a big step, since you can do so many things with the platform. And there is so many things you can do with Drupal that it can be considered as a developer platform in addition to a content management platform, or event a web store platform, or a community plarform, or… Well, just pick and choose.

    And if I ever consider switching to simple HTML or a simple blog for a client or for some specific need, now I find it easier to do both using the Drupal platform.

    You are free to choose any CMS or CMP you wish, though. But choosing WordPress does not mean it’s better than Drupal. And choosing Drupal does not mean it’s better than WordPress. A user or developer just need to choose the glove that fits.

    Like

  10. yaph says:

    From what you describe Drupal really doesn’t seem to be the right choice for you. I know well that Drupal can cause headache, but most of the times I learned how to do it the Drupal way, I was thrilled with Drupal’s elaborate architecture.

    You can write powerful modules in a few hundred lines of code thanks to the hook system and the exiting API functions.

    You will have functionality you don’t need in other frameworks too, since none is built to exactly serve your individual needs. Writing your own seems like a logical choice, but you will end up re-inventing the wheel many times, which can also be very frustrating.

    Like

  11. Jessa says:

    @Wim

    node_load() performs a query on the node table INNER JOINed with node_revisions and users to retrieve *a single node*. If one is displaying any kind of large listing – like an index listing the title of 100 nodes – we’re then talking about making a minimum of 100 SELECTs just to display a simple table of information.

    There’s some overhead involved in sending a query to the database and getting back a result, regardless of how many records are returned. Repeating that overhead dozens of times noticeably degrades performance versus running a single query to get multiple records. If one has contrib modules that make a query when node_invoke_nodeapi() is called, then the situation gets even worse.

    If you can make a single query to get a list of nids, you should strongly consider writing that query to retrieve all the fields you intend to display and leaving node_load() out of it.

    I’m not trying to bash node_load(). It’s a great function that grabs everything you for a node while ensuring that access control and contributed modules all have their say on the output. When you need to display lots of detail about a small number of nodes it’s perfect. But, it’s the wrong tool for efficiently showing a couple fields from many nodes.

    Like

  12. jake says:

    Thanks for all the feedback so far. Lots of really well thought out replies.

    @Pasqualle:

    the super-basic FAPI is super super basic atm and definitely not ready to release on drupal.org. still need a lot more thought but for the job it was required for made things really nice and easy.

    Drupal is absolutely different to any other framework, you need to learn it. But when you know how it is working and why it is working that way, you don’t want to use anything else.

    I used to think this exact same thing, and still do to some extent. But I’m turning back to my own framework option. Not an all-purpose framework to be used on any new sites I do, but one specific for one particular framework. As an all-purpose swiss army knife Drupal does as well as it could, I don’t want to reinvent that wheel.

    I see one big problem with your development practices: you do not work with the community. You try to create everything on your own. That’s not working. Drupal development is faster than anything you can accomplish, you will be left behind.

    Don’t completely agree with this. I’ve contributed modules on drupal before (nice_menus, tasklist, and started the idea of hook_watchdog in core). I’ve spent money on Drupal consultants. I’ve helped and asked for help in IRC. I go to Drupal meetups. In short, I’ve really tried.

    @Ronald

    Where Drupal shines, I think, is as a tool for a web agency that every month needs to deal with very different kinds of websites and can quickly put them together using Drupal’s flexibility rather than coming up with different versions of custom-made tools for each website.

    Completely agree. If I were making dozens of websites rather than just the one I work on full time at the moment, then Drupal would be a grand choice.

    @Matt Farina

    When if comes to your form issues I’m not exactly sure where your issue is. I took a look at your form and the same look is something that can be achieved with FAPI, a tweak in the template.php (to remove the :), and some css magic (no crazy theme functions required). A suggestion, no matter which way you choose to go, might be to invest more in CSS.

    Thanks for your suggestions. I can remove the : by overriding theme_form_elements() or something like that, but then it affects all forms rather than just one. And it involves copying and pasting the code from there to my own function, then changing it in my own function. Then if in theory there was a security release which changes that function I’d have to make the same change in my function. A bit like forking the code, and potentially a real headache on upgrading to the next version of Drupal if things changed (oh… I’ve spent a *lot* of time upgrading my modules to new Drupal versions before).

    If things keep on pace, drupal 7 should (hopefully) be much better with data sources other than nodes.

    Again, the whole idea of another Drupal upgrade makes me feel sick knowing how much time I spent last time. Upgrading to Drupal 6 within 24 hours of its release was also a terrible idea… I discovered several major, major issues with regards to forms and race conditions.

    @aka006

    I nominate you for a position on the Drupal Association Board;)

    Haha… thanks. I’d love to spend time doing such things but the reality is this. I have a business to run, money to make, and a baby to support. The idea of spending time on anything else is lovely but almost impossible at the moment at least 😦

    @jessa

    spot on re. load_node. I really love node_load and node_save, bringing in my own stuff through hook_load and hook_update. But the content type I’ve taken away from being a node is used a lot in big tables with load of them in. I’m not going to do a node_load on each one and have dozens of database queries when one query will do just nicely thanks. Sometimes abstraction is really nice, but for performance abstraction can be terrible.

    Like

  13. Wim Mostrey says:

    Hi Jessa,

    Please note that node_load() fetches a cached result if it’s available, so you’re not sending 100 selects to display simple information. It’s getting the information straight out of the cache. Other modules can hook into hook_nodeapi to alter information and, as you say, do access control for instance. By doing the selects straight on the database, you’re bypassing those. This might seem like a good idea now, but if you install other modules later on, this might give you some headaches.

    It’s by doing these things manually (selecting node information straight from the db, writing your own forms, …) that you’re bypassing Drupal and that you’re missing out on its strength. It takes a while to learn “the Drupal way” but as yaph mentions, once you know how the handle them, you control very powerful instruments. Once you control these tools you’ll noticate that Drupal doesn’t have a lot of ‘baggage’ but that it allows you to write custom code so much easier and more flexibel.

    Like

  14. jake says:

    @Wim Mostrey

    It has to be cached for the current request, not just generally in the database. If it was just generally cached in the database, that would still involve one db query per node, which is exactly what we’re talking about here.

    I don’t want to use another module which does stuff in nodeapi. I simply want “SELECT * FROM blah WHERE blah LIMIT blah” and that’s it. node_load() does not fit my purpose where I’m showing multiple nodes on one page in a table.

    Forms are one area where I really loved Drupal. FAPI comes with a lot of built in security. I want to keep that security, whilst having better control over ad-hoc changes to the HTML layout (not everything can be done in CSS, or at least in the most appropriate and clean way). Yes, Drupal enables me to have complete control, but in a really obscure and abstract way which is very time consuming to deal with for every custom form you have.

    Like

  15. Greg Holsclaw says:

    The trouble with this comparison is that the costs of using Drupal are very much in front you as described in your headaches, extra theming loops you have to jump through and the FAPI you need to learn.

    But the benefits to using Drupal are a bit hidden until you hit a development wall. As mentioned in the last post, is your security up to snuff on your forms. When you want to add a combat spam, can you drop in the Mollom or captcha modules for instant success. Are all your user permission and controls in place for your expanding user base, with profile fields and OpenID ready a the flick of a switch.

    Once you go down the custom API, home spun framework, there is no coming back. The hundreds of devs who are creating new modules and improving current modules are useless to you, and you to them.

    I have been working on custom frameworks and Drupal now for years. It is true that I have to jump some building to make Drupal do what I want at times, but when I have a complex one-to-many user permission problem and instantly is solved by plugging in the nodeaccess module, I thank myself again and again that I using Drupal.

    Like

  16. Drupal User says:

    Why can’t you just #theme the form, do whatever markup you want and drupal_render() the few form elements wherever you to place them? After reading that portion I just had to stop… Not a real fan of “I had a bad day” posts.

    Like

  17. dalin says:

    re: theme functions: “Then if in theory there was a security release which changes that function I’d have to make the same change in my function.”

    By definition there should not be any real logic in a theme function. Theme functions add html tags to pre-constructed data, any logic should happen earlier in the flow. Thus the only real opportunity for a security flaw would be a missing check_plain() on a title for example. And these should be becoming all but extinct in major modules due to the new Drupal security scanner project.

    I have far less confidence in the security of my custom code than I do in Drupal or the major contributed modules since more eyes see the code, and more security tools are used to audit it.

    I see a custom framework having the same issue, only worse.

    Like

  18. dalin says:

    “The ‘programmer’ cares about the functionality of the form but not the visual design of the form. The ‘designer’ doesn’t care about the functionality and instead works on how it looks.”

    Actually the reason that things are separated is the MVC design pattern. This call for separation between the model, view and controller (The data, how it’s displayed, and how its manipulated). You could toss everything together, but it would be really painful to maintain. What amounts to a minor inconvenience of defining your form in one place, and theming it in another, makes for far more readable, and maintainable code.

    The importance of this and similar things should not be underestimated. What if you disappear? Will the project be able to continue? Or better yet, what if your organization grows? Will someone be able to join the project and get working quickly? You can’t hire an expert in your custom framework. Will it take six months of _your_ time for you to train a new hire on your custom framework that doesn’t have a drupal.org to learn from?

    P.S. Your name fields appear on two lines in my browser.

    Like

  19. Doli says:

    I’m preparing to start some social network, I’m still working on graphics and functionality, but slowly starting to look for the technology to built my site. I’m thinking mainly about drupal because of the issue dalin pointed out in his comment. I don’t want to be so much depended on the programmer using his own framework, coding tricks etc. If I build something in Drupal there shouldn’t be any problems in finding some other companies which could take over the coding when something goes wrong. This is very important thing for me. And in the case of updates when new release shows up. I think it can be good for the site, you can refresh it, rethink some ideas, remove the bad ones, work on the performance it’s good time to do it.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s