Want to get Lullabot article, videocast, and podcast announcements delivered right to your in-box?
Let us know your email address (we won't share it) and we'll let you know when anything exciting happens.
Attacking the Glue Code Problem
July 13, 2007
My last couple of posts to the Lullablog have mostly been rumination about the state of Drupal site-building, and the need to make certain kinds of tweaky tasks easier for folks without PHP skills. Some of these gaps are difficult to close, but others are pretty simple once you realize them. The key is isolating the specific problem that is common to lots of sites, and figuring out how to solve it in a simple, easy-to-reuse fashion. Want an example? Yes, I thought so.
Over the last year or two several large-scale Drupal projects (including MTV UK and the New York Observer) have used custom CCK content types for their section 'landing' pages, daily cover pages, and so on. This technique works really well: it lets editors and content managers tweak the details of "The Front Page" without disturbing the 'live' version, tools like Scheduler and Actions/Workflow can be used to put additional editorial workflow controls on the new front page layouts, and there's no need to whip up a special maintenance UI for the various topical/sectional landing pages. Since they're nodes, you get them for free.
The trick is that you want the url for your section, or your landing page, to always display the right node. For example, http://www.newspaper.com/section/entertainment should always display the latest published 'front_page' node in the entertainment category. Without manually mucking around with path aliases every time you make a new node, there's no way to do that without custom code. This kind of stuff is easy to tuck into a single function or two in a custom module, but it's still a hurdle for folks that don't have PHP experience.
So! There's our problem: make it possible to set up custom url paths that display the latest node of a particular type, at a standard bookmarkable location. I took a look through code that we've written for clients in the past to do similar things, and found a snippet that I could re-use. When a user hit the module's custom url path, it loaded a pre-defined view, picked the top node, and displayed it. I gave it a bare-bones UI and added a couple of convenience features (like support for caching, to reduce load on high traffice sites). The result? The Top Node module.
The heart of the module is only 50 lines or so of code; the complicated part was putting a nice editing interface onto it. (This demonstrates the proof of my earlier comment: most 'glue code' tasks are pretty simple, to the point that it takes more code to give them a user interface.) There are already a couple of feature requests for it, and a handful of people are interested in helping add them.
Overcoming the challenge of 'glue code' in Drupal doesn't have to be painful. It just requires developers to step back, identify the common things that we have to tweak and hack on every site, and spend a bit of time to make it reusable. Let's brainstorm -- what small, granular bits of functionality do YOU find yourself hacking together on every Drupal site you build? And how can you turn that 'glue' into a useful tool?
Comments
Component module
My most common glue is the component module. More on that here. :-)
Bookmarks and Path aliases for sections
Good call, Jeff. I think nailing those details is very important for the accessibility of Drupal for non-developers.
Here is my piece of cake:
Drupal provides a number of ways to organize your content. Each one of them is rather unhierarchical and more of them together are not hierarchical per definition.
So, everytime I need a more rigid organisation of content - let's call it sections - of my web site, I find myself hacking breadcrumbs and URL aliases. The problem gets even more challenging, if users on the site should be able to create their own sections and sub sections.
Here is how I usually approach this task:
- Create a content type "section" that represents a section of the site
- Use NAT to automatically create a taxonomy term when a "section" node is created. (Problem: multilingual sites and cases where the node title shouldn't be the section name)
- Assign sub-nodes to this section with the NAT-created terms
- Hide section taxonomy from UI (theming layer)
- Set breadcrumb of nodes according to their section taxonomy in custom module (nodeapi hook).
- I didn't do any URL path alias work so far for it - wasn't that imortant, but is a nice-to-have - I guess you can use taxonomy in pathauto.
- Special problems pose pages that aren't nodes and therefore can't be assigned a taxonomy - I worked around by using a wrapper node for views using viewfield module.
I could go on here, but I think this list gives a pretty good idea of where it's going. I wanted to throw this out here because I think it's a common site building problem - I would be interested in how other people approach it.
Hey...
Where were you last week when I needed to know that?! :) Alex, can you please publish some more information on this?
Hierarchical Sites
Alex,
here is my approach:
Each section is based on a taxonomy term
Sometimes I need a Section "home page" to be just a static page so I just need to use a page their.
I need to pull in things likes blog postings, custom cck news and events content, or podcast episodes, I make a view block and set it to show just on that page in the content block (or sometimes another block). You can add more than one view this way to the same page. So you make a views block that says show me all the news cck type post sorted by date (or events or blog posts) and are in this taxonony category. I'm not actually sure why this wouldn't be a good solution for the problem Mr. Eaton describes, but I am sure I am missing some of the nuance.
Then for menus I just use menu.module to make a menu for each section or department and I use a php snippet to only show the menu for nodes of that particular taxonomy term.
This created one small problem - some nodes need to be in more than one "section". The first thought I had was just give it 2 taxonomy terms but that would actually show 2 menus so I made a small "include" module a la php or ssi includes that lets me include the content from one node into another but still use different terms
Before you write a module...
I might be completely missing something here, but it seems to me that you are making a major mistake here, by duplicating the functionality of another module, rather than improving it.
The Insert View module lets you insert a view into a node, and limit the number of results it returns. By limiting the number of results to 1, and setting a url alias to that node, you get the exact same functionality as in your module: Top node of view my_view in a preset url.
To answer your question, I'd say it's better to understand how you can squeeze Drupal of all of its juice, by using existing contributed modules, before you decide to write your own code.
I admit the mission is not easy. With new modules coming everyday, it's very hard to find the right module. But in most cases you'd find one already exists, and it waits just for you!
I think the simplicity of
I think the simplicity of Jeff's solution is worthwhile, and there's also may be a difference in display (requiring a theming workaround) of a plain view versus a view in a node. Though sometimes a view in a node (which the viewfield module can also do, as a CCK field) can also be what is desired.
In general your point is a very, very important one in the expanding Drupal universe, and I'm glad to know now about the insert_view module!
Benjamin's point below is
Benjamin's point above is why I decided to go this route. Using a view to display a single node works technically, but it doesn't give you the full effect of a node page. Specifically, the page title and breadcrumb trail are the view's rather than the node's, and there's no way to show the comment form and comment list below the node body.
Views feature request?
Sounds like a great Views option to add in the "page" section:
"display full node instead of a list if result is only one node"
Post new comment