Paying Attention to Drupal Admin experience

Capturing my answer to a question on a mail list I’m on about paying attention to the Drupal admin and editor experience. Particularly, someone was asking if they should open their allowed HTML to allow pasting form and iframe tags versus the risk of being compromised by the same. My initial reply was:

If your content team is relatively small and you trust them … I think it’s OK to all form and iframe embeds.
However, if you can I’d see if you can embed these snippets via some other way, like shortcodes in WordPress or as Paragraphs in Drupal (there are probably a dozen other solutions in Drupal too) which integrate with each of those platforms. HTML is easy to break, you won’t be able to just paste the HTML into your editor, and if they embed code has to change in the future (or be removed) it’ll be tedious to do so.
Which lead to a longer discussion on ensuring the overall Drupal editing experience is not ignored.
First, “locking” clients out of editing templates and configuration values makes sense, if the vendor will be hosting and supporting the site long term. There’s a lot going on in a CMS, and accounting for changes to configuration, CSS, templates introduced only on the production server is a migraine waiting to happen.
That said, it doesn’t mean you should give up a lot of flexibility for controlling the layout of your pages and you shouldn’t have to run to the vendor for every change. Things they and you should be paying attention to:
Ensuring they aren’t hard coding page and node layouts in a template such that changing them later requires a lot of effort. This was a pain on a site I worked on last year and had the Webforms module enabled. Instead of using the Webforms UI to build a form and control how the fields were grouped and displayed, the previous developer did that completely via custom templates. For the client,this meant that any new form had to have a custom template for it and changes made to forms in Drupal’s UI had no apparent effect (which kind of misses the point of having Drupal). Other pages on the site were handled similarly with custom templates.
Just throwing a WYWIWYG editor at your editors is also a big fail. If you have a document type which will have a link to a PDF file, don’t be content with a “file explorer” type plugin for CKEditor. Have a “Related Files” field in the document content type. Editors shouldn’t have to worry about how and where the file link will be rendered. Use Drupal/your CMS to consistently display the links (and integrate the PDF contents with Search, share files with other content types, etc).
For layout control within a page, Drupal has a couple of options which don’t require an editor making the layout in raw HTML. I think there’s a Layout builder in the latest release and there’s always the “Paragraphs” module which lets you define types of blocks you can stack to build an interactive page. Conceptually not unlike Mailchimp’s editor, if your familiar with it or how Gutenberg’s blocks will be handled in WordPress.
Media handling in Drupal has always lagged behind WordPress. I’m not sure what the state of the art is, but the latest release has Media in core. If you’re going to have a lot of photos, audio files, etc… you’re better off managing them as Entities you can tag and manage like a node and not just think of them as a file you upload and link somewhere (much like images I mentioned earlier).
Also if you have some custom workflows for managing the content creation process, you should ask your vendor to use well known modules like Workbench to configure and manage the process. I wouldn’t want to code a custom workflow for a client, since that becomes harder to change whereas Drupal modules exist which can let you manage and tweak those requirements in the UI (see https://www.palantir.net/blog/its-here-workbench-drupal-8)
Last, I’d say make sure you have a good content model. If you are going to have blog posts, articles, and press releases — each with their own quirks — they should each be a content type in the admin. Don’t make an uber “article” type which behaves differently depending on which fields are filled out. Within each content type, group fields which belong together, use vertical tabs or sidebars to break up forms with a lot of fields, etc… This is a good summary: https://evolvingweb.ca/blog/how-make-sure-your-content-editors-love-drupal

 

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.