Drupal Workflow and Access control

Large organizations want to, or may actually need, strict access control and content review workflows to manage the publishing process on their website. Drupal’s default roles and permissions system is designed to handle the simplest of setups. However, there is a wide variety of modules that each address these needs. Many of them overlap, some complement each other, while others are abandonded and haven’t been ported to Drupal 7. In this article, I’ll look at some active modules for these requirements.

Revisioning for Basic Workflow

Unless your web publishing workflow is very complicated -= in which case, I think you have other problems – the Revisioning module should suit a basic author-editor review setup. You’ll need at least two roles, an author role that can create and update but not publish new nodes, and an editor role that reviews and publishes changes made by authors.

Authors write content that prior to being made publicly visible must be reviewed (and possibly edited) by moderators. Once the moderators have published the content, authors should be prevented from modifying it while “live”, but they should be able to submit new revisions to their moderators.

Once installed, the module provides a view to show revision status at /content-summary.

Content Access for write privileges

The Content Access module allows more fine grained control over view, edit, and delete permissions. Furthermore, it allows you to set access controls on a per node basis. This lets you restrict the set of pages, stories, or other content types that a single role can change.

This module allows you to manage permissions for content types by role and author. It allows you to specifiy custom view, edit and delete permissions for each content type. Optionally you can enable per content access settings, so you can customize the access for each content node.

Related Modules

If you need “serious” workflow in your Drupal, there is the aptly named Workflow module, and the newer State Machine and Workbench Moderation modules. These modules seem to be actively developed, and with enough time, tweaking and experimentation should help solve many workflow issues.

Drupal finally using OOP

Finally. This is a huge step forward for Drupal. After eschewing OOP practices for a long time, its finally winning over core developers, which will make working with Drupal as a Framework easier in many ways. I copied the announcement below, but you can see that patch and discussion here.

This patch is about to be committed. It is the foundation to change for example $comment from an stdClass to a comment specific class allowing for $comment->save(). This is a monumental change and everyone is invited to review and familiarize with the new system even before it is committed.

What is possible when you use proper classes? The first thing I envision is a plugin/pluggable system in the same way that Zend Framework allows you to use Controller Plugins and View Helpers from a pluggable object, without the need to inherit or compose an object. For example, in a Zend View, you can call a partial like this:

{syntaxhighlighter php}

partial(‘my-partial.html’);
?>

Now, the View class doesn’t have a method named partial, instead the magic __call method intercepts the call, gets the Partial view helper, and calls its invoke method.

Web Design is Evolving

I may be a bit late to the party with this observation, but web design is finally evolving. Mobile phones and tablets have freed us from having to use a laptop or desktop to use the web. Using HTML and CSS, designers can now use media queries to control how a site appears on different devices.  If done right, and done from the beginning to save costs, your website can be useable and look nice on multiple devices, without the need to setup a different mobile site or theme.

We may also be seeing the end of the tiny font fad that has made sites illegible for the last decade. It’s about time.

You see, in most cases, if you’re building websites with the font size set between 10 and 15 pixels, you are costing your clients money. And I aim to prove it.

16 Pixels.

Frustration with Drupal core growing

When a prominent developer and contributor lashes out that Drupal is in dire straits, you better listen.  You ought to read his critique of how Drupal core development is stalling, or at least stuck in the mud.  That can’t be good news for anyone looking to upgrade to Drupal 7.  My thoughts after the quote.

In addition to the half-baked, single-purpose product features mentioned above, Drupal core still carries around very old cruft from earlier days, which no one cares for. All of these features are not core functionality of a flexible, modular, and extensible system Drupal pretends to be. They are poor and inflexible product features being based on APIs and concepts that Drupal core allowed for, five and more years ago.

Where would Drupal be if they had worked more closely with the PHP community early on?  I have no idea, but a lot of PHP programmers have looked down on Drupal because most of the codebase can be messy, with poor API design decisions, overuse of globals, and leaky separation of concerns. Along with Drupal eschewing Object Oriented Programming and resulting best practices, its no wonder that talented developers would choose to use a framework like Zend, Symfony, or Cake to build a complicated website.  It sounds like a lot of short cuts and idiosyncrasies are now baked deep into Drupal core, and ripping them out too much work for core developers.

I’ve always thought that Drupal’s greatest strength is certainly not the great design of its codebase, but the Drupal community and ecosystem. A contrib module usally exists for many common website needs, like managing redirects, creating useful URLs for content, integrating with analytics,  and plugging in 3rd party commenting systems.  On top of that, there are super-modules like Views, Panels, and Context, which let you prototype and build parts of a website without having to write any code at all.  The Drupal community has solved a lot of problems through determination and individual brilliance, but that model can’t be sustainable in the long run.

Is there a solution?

Drupal core should cater to programmer’s needs, via coherent APIs and pluggable subsytems.  A complete rewrite of core, or even big parts of core, would be a waste of time. Drupal would stagnate while other frameworks kept improving.  I think Drupal 8 should seriously consider using a framework like Symfony2 as the foundation for core.  I mention Symfony because it has an EventDispatcher component that can replace most of Drupal’s magical hooks system.  The next release of the Zend Framework will have a similar component. A tested framework, used not just by content management applications would expose developers to a wider range of best practices, particularly around configuration management, deploytment, and unit testing.

Contrib should cater to site builders needs and focus on adding features on top of core that they want.  Modules in contrib can improve faster to meet user needs, fix bugs, and innovate.  This is an idea proposed in the discussion linked above. Moving as many modules as possible out of core also makes Drupal leaner.

What’s in your Project Management toolbox?

Matthew at DogStar describes his PM toolbox today, The Project Management Tool Box | Opensource, Nonprofits, and Web 2.0.  It’s a detailed and well organized list, and I think reflects a very practical approach. The first thing that strikes me, is the overwhelming amount of tools available to the would-be PM.  Certainly, there is no lack of tools out there.

You see, the general feeling is, there is no silver bullet. There is no grail of a tool that does everything a single Web Producer, Project Manager, Product Manager, or Content Manager might need or want. There is clearly a gap that is filled with a series of different products. This walked hand in hand with a desire to review processes at work and engage in course corrections. It is an excellent habit to follow – look what you are doing with a critical eye, analyse why you are doing it, and make changes as needed. I have worked across four different shops with a wide variety of different ways of practicing project management. I have used these methodologies and tools across ~ 50 different Drupal projects and another 25 or so custom PHP MySQL projects.

I could not agree more that its important to not be seduced into picking the one right tool for every situation.  It is a difficult tempation to resists, especially when you have tool makers pushing to sell you a solution. The best tool for the job isn’t the one that has the most features, its the one that you, and your team, end up using the most.

As I read the article, a thought that struck me is that sometimes, you don’t need ONE tool, you just need to make sure everyone has the right tools (and skills) to be productive and responsible. At work, we’re a tiny team of 3 who deal with day to day management of our Drupal site, unexpected requests on tight deadlines, and long term projects to build new features. Here’s a secret – we don’t have a central bug/ticket tracking tool. We can be productive simply with email, IM, code bearing, and face to face conversations. For big projects we use a whiteboard to wireframe, capture tasks, and track progress.  This works better than a more sophisticated technical solution that would impose a greater burder on our time.

What’s your experience with tools and grappling with finding the perfect tool?

Limitations of multi-lingual Drupal

Good explanation of the limitatins of using Drupal to run a multi-lingual site.

Then there is “the other side”, whatever does not come from code. Drupal works pretty well and very consistent if you want all of those to be in a foreign language (i.e. not English), but not in multiple languages (any of which can be English at that point). Drupal only has direct multilingual support in nodes (+ fields of entitites) and for path aliases. But life with Drupal means you work with all kinds of other objects like blocks, views, rules, content types, etc which are not “language-aware”.

Drupal’s multilingual problem – why t() is the wrong answer

Designing for the Drupal Community

I posted a comment over at Five community challenges for design in Drupal 7 & beyond. It is awaiting moderation but here it is in case it doesn’t get approved.

@Mathieu – saying that coding is fundamentally about rolling out features and bug fixes is like saying that design is rolling out sizing boxes and picking color schemes. To bring any design to life, there are a number of choices that have to be made when it comes time to implement them in code (both front-end and back-end code). And, although choices are deeply individual, we’ve found ways to come to a consensus and make group decisions.

For Designers who think there work ends with producing a PSD or other mockup, the issue queue + IRC are not going to fit their work habits. Neither will having to defend most of their decisions after they have been made. I think designers have a tough job there, because good design is holistic. The Open Source community is used to testing and challenging proposed solutions, so designers might feel like their precious creations get unduly criticized when shared. Also, Drupal needs to be flexible to fit different use cases, so trying to have a one-true-solution is impossible.

How NOT to Optimize your Drupal website for a iPhone or iPod

Don’t follow the advice posted below to “optimize” your site based on the user agent string.  The author suggests doing so in the page.tpl.php for your theme.  However, this means you can NEVER turn caching on for your site.  Also, the uses ereg functions to “detect” the device.  These functions are now deprecated by PHP, meaning they won’t be supported in the future.  The matches used are also very simple, and could be done much faster using the strpos or stripos functions. 

Optimise your Drupal website for a iPhone or iPod

If you need to detect the useragent,  you should probably use hook_init() or hook_boot() to do so, since they run regardless of the cache settings.  You’d also have to plan more thoroughly how to react to different devices –  if in fact you thinkg that’s a good solution.  A better approach would be to use pretty clean, flexible markup and use CSS media queries to provide device-specific stylesheets, as in Return of the Mobile Stylesheet.