Entries from March 2009 ↓

Media and Drupal workflow

I got to sit in a session where we’re learned about how newsrooms are using Drupal in varying ways. In a discussion called “Drupal in the Newsroom,” representatives from NY Observer (Tom McGeveran), Mother Jones (Nick Aster), and a representative from The McClatchy Company (I’m working on the name since I ran out of batteries and was scrambling for a plug when everyone was getting introduced) joined in a panel discussion.

McGerevan said the New York Observer takes a lot of the essential elements of Drupal and uses them in the newsroom. The newsroom operates in a way where most things are published to the web and then changed, improved, repackaged and put into the print publication. He says the news product more native to the web in its workflow. But they haven’t built any custom workflow into the CMS. They have customized Drupal for editorial needs. They found templates and ways to package content to do the things they need. In their recent relaunch of the site, they have editors applying a weight to a story. That determines how much prominence it has on the site. No more scheduling of the story items. It’s a thought process that is more web native. I really like that!

McClatchy’s workflow is rapidly developing. When they first started experimenting with the CMS, they were looking at standalone builds. They saw a lot of instances where affiliate IT departments were using Drupal as a back end or adding widget items into existing CMS. The Drupal commenting system is the only thing they would use it for. But as McClatchy newsrooms gain more knowledge, they’re using it more. Some newsrooms want to use it as a primary data entry site to feed the content into their core CMS and eventually use it to the print product.

Aster said Mother Jones used to consider itself as a magazine that happens to have a website. Now they’re working with the belief that they’re a 24 hour news agency. That thought process started changing when they introduced blogs two years ago. The web-focused workflow is more relaxed and once people realized that is a better process, the use of Drupal was welcomed. This process also created a less complex approval and permissions process to get articles and blogs published to the site.

The first thing that came to my mind was whether the newsrooms are working on any Agile development concepts using Drupal. Apparently McClatchy used Drupal to build a mom community in only a week and a half! I think that’s amazing. If I was able to build a functioning community site in that short amount of time, I could have four or five test projects running! Okay. Maybe three.

It was interesting to see where the conversations were going with the session. There was more culture talk and workflow talk than an actual discussion in how Drupal functions. I kind of really wanted to talk about Drupal functions. But the discussion turned to how did the newsrooms change culturally to become web-focused. The one thing that stood out from all three men was how all three newsrooms have an open source environment. They all said it made sense to work with an open source product. That was so great to hear. I’ve hit snag after snag from cultures that don’t work with Drupal’s flow.

The one workflow item that I really enjoyed hearing about what how Mother Jones is using Drupal’s features to create more of a community through online readers and potential contributors. Mother Jones wants to be able to share investigative journalism online where the community can help steer the conversations into solutions. The magazine added two little flags in Drupal where the comment can be a recommended solution or a documented result on behalf of the problem.

In the end, I got the feeling that the room was full of people bursting to talk about journalism and how we can find really great solutions for the industry… and the possibility that Drupal is one of those solutions. One person asked if Drupal was a fad… I mentioned that statement on Twitter. Ben Shoemate, who I finally met in person after talking on Twitter, mentioned to me that he felt that question was a bit dramatic. The real question is this: Do these newsrooms all expect to switch content management systems every two years? That’s when I really figured out why we’re doing all of this.

We are looking for solid CMS that is flexible enough to do what we want it to do today and what we’ll want it to do tomorrow. And if it isn’t flexible enough tomorrow, it needs to be able to export all of its data easily to prevent an ugly CMS divorce. That’s what matters. It doesn’t matter if Drupal or WordPress or Django are the fads. What matters more is if we don’t like the CMS, we can export, get out and move on without losing data.

So that’s where the question of output of web content that can go right into the print system becomes very important. If you can export web content to go into a newspaper, then you can export all of your content into archives or into an alternate CMS.

I’d love to hear what you think!

Working with Drupal Code

I have no clue how to code — I know how to hack into code and fix things the way I want them… But I attended a gentle introduction session at the start of DrupalCon in Washington, DC. We started out with terminology so I don’t feel so stupid. Addison Berry presented the first session I attended.

There are 1400 people attending this event!

First and foremost, Drupal is a content management system. It helps you manage a website built onto a framework. Drupal was made to be flexible to do what you want it to do. The CMS framework that makes it so flexible are constructed from APIs (Application Programming Interface). It does all kinds of bits of code that let you do tasks so you don’t have to hand code your website. It’s wrapped up in a nice little package for you. Drupal has a ton of APIs that are built as “modules.”

Here’s when the discussion gets deeply nerdy. If you aren’t interested in code… Here’s what I learned. There is a step by step process that helps Drupal function. It looks for all of the things you want to happen with the site and then it delivers that content to the site’s look or theme. If you think through what you want, the code comes together for you. If you build it and then try to make changes on top of your structure, things break. Also, the theme is more powerful than the actual code. It can trump the code… or the theme can fight the code. I’m pretty sure that’s another problem I found during my Smart Decision ’08 experience.

The sites folder that comes with a Drupal install is what you would probably mess around with. But the includes folder is actually worth looking into. It gives you the lay of the land and tells you what you’re working with. (http://api.drupal.org information is all in this file. It’s your own reference to explain things for you.) You can learn about the common functions of Drupal code. These functions are a little machine.

Drupal has a concept called “hooks.” It’s a naming convention. hook_* where hook is replaced by your module name. It lets you create a system where a module defines the system and another hook can connect with another hook.

Hook example: Think of Drupal of a train. It looks for a hook_perm function (each is a train car) in your module file. The API tells you what needs to go into it. Drupal searches through the whole site and grabs the items that have a hook_perm. Drupal grabs all of the cars (module perm files) and then it goes to the themes where you can snag alter functions. It’s a step by step process to get the site to do what you want it to do. Once it gets to the theme, that’s when it gets pretty. So once the site has all of the “look” and it delivers the content to a web browser. The hook system is why Drupal works… but it’s also why it can be challenging if you try to fight the hook process. If you work from the beginning to build a site following the hook process… then you won’t get in big trouble> Most troubles hapeen when you try to hook on extra stuff after you’ve built the basics of site. Ugly things happen… and that’s where I hit major snags with smartdecision08.com.

Menu function (in the includes folder as menu.inc) – Drupal needs the menu system functions that make it work. The menu system is not the menu module. The system works like a router – that’s how Drupal knows how to produce anything on your site. The menu system maps URLs to take you to that site. Without the menu system, the site won’t work. The menu module is not needed – it’s just the UI for you to graphically create navigation for a site. (most people don’t turn it off)

Form API (FAPI) – is a “thing of beauty” but most people get scared. The form API lets you build forms on your site. Drupal FAPI – form.inc has all of the functions in there. It handles the form, validation and submission. Instead of building it with HTML tags, it is just an element in the array – a big PHP array for every single thing. Drupal takes that array information and turns it into the HTML for you. Why would you let Drupal do it? It doesn’t just create a form, it does the security and verification for you as well. The idea is FAPI takes care of all of the security stuff. You just list out what you want in the form and Drupal takes care of it for you. Drupal has your own default and submission process. You can change it to have required and non-required elements. You have complete control when you build your own form module. When you’re trying to alter a form someone else built, you can go in it and tweak it (which is how I do anything in code). It’s great when you know what you’re doing… frustrating when you don’t. But once you get it, it’s a much easier way to build forms.

Databases – database.inc and database*.inc are in the includes folder. When you need a new table, insert new tables and take out tables, this will do it for you. This helps you securely pass and share information without a concern of breaking security holes (SQL stuff that I don’t know). You can just pick all the items you want for a database, it will build it for you. Just tell it what fields and tables you want and Drupal will do it for you.

Theme layer – is the last step. There’s an include files (theme.inc). It runs the entire theme system. It’s how Drupal gets output. Information runs through the theme to output to the front side of the web world. Drupal has a system module that has default tpls files (template files). Drupal by default has block, box and page template files in the system module folder. Blocks are a module – but the system has a block section as well. The core html output goes into a tpl file inside modules folder. If you want to change the tpl file – go into the system module, it will automatically change everything you want. page.tpl is what is most often changed. Anytime you want to modify html, see if there’s a template file to work on. Copy it, paste it and go.

In the end, themes rule. It controls everything in the end. Module output uses theme()
The order of priority is theme_function_name() (is there a theme function?)
phptemplate_function_name() (the engine of drupal)
mytheme_function_name() (final item that trumps all – it gives you total control of everything)
Copy and paste function into anything you want – change the logic, the wording… anything you want. It trumps anything the coders did for the site. Themers end up trumping the coders. When it comes to output the theme has control and this is probably where I’ve also hit snags. The code sometimes doesn’t agree with a theme. If you keep the module code really generic, it allows the theme to give it control on a lower level and the module can be used multiple times.

Yikes. I think I kind of picked up on the way Drupal actually works!!
Developer/Theme handbooks
Drupal source/api.drupal.org
Dev/Theme mailing lists (drupal.com/mailing-lists)
IRD:#drupal (#drupal-dev) #drupal-themes
Issue queues
Paper books: http://drupal.org/books

Those are my notes and I promise to go through that and improve what I’m trying to say. I promise.

Getting deep into Drupal


I just got into DC to attend this week’s DrupalCon. I’m pretty excited but also a bit overwhelmed. I’m not really a coder, but I want to be friends with one or ten. I’d love their thoughts on my experiences on projects I’m working on. I’m not really able to post much tonight, but hopefully I’ll be able to tweet the events while I’m at the conference.

My attempt at helping journos learn Twitter

I held a brown bag session this afternoon over lunch to show how I use Twitter and why I think journalists should take a look at it as a new news source. It isn’t the end all be all answer to all of our challenges, but I do think it’s a change in how we gather and share news and information.

I loaded up the first half of the presentation… The second half included questions and answers and a little bit of show and tell. If you have questions or need some show and tell, leave a comment here and I’ll see if I can help get you started.

Here are the slides I used during the presentation just in case you’re curious. I ran through a few pretty quickly to get to the second half of the presentation.

All of my follow up notes to this presentation are a permanent link to the right of the blog called “Twitter Tips.” Please feel free to leave comments here if there are additional details that were missed.

UPDATE: You can go here to watch part 2 of the webcast.

Talking Twitter

I’m planning to speak about Twitter journalism during a lunch time webcast and Missouri School of Journalism brown bag session today. (If you are in Columbia, it’s in the forum on the second floor of the Reynolds Journalism Institute at noon) It should be a lot of fun. If you can’t attend, I’ve written up my notes right here. If you can attend, those are just notes. I’m going to show more examples and field questions from the audience. It may be a packed house. It may not. If you are interested in watching, feel free to visit the RJI website to see the streaming video.

I promise to post the video here as soon as I can get my hands on it. Have fun!

UPDATE – if you go to the RJI website, just click on the “RJI Live” link to the left. And if you want to join in on the Twitter conversation before, during and after the event, please use #tweettalk as the hashtag!