Drupal

The most important part of a content strategy, in my opinion, is your content model. It not only ensures your copywriters and editors are able to publish the appropriate content, it provides the framework for your user experience and ensures proper delivery of content across marketing channels.

Most content management systems were designed with content “blobbing” in mind - content should be entered into a body field and formatted with a WYSIWYG editor. Because of this, most organizations have not taken the time to truly analyze their content needs because the assumption is made that all formatting and structure will be added through the WYSIWYG editor.

Maintaining content in this format is a nightmare. Pages become inconsistently styled, content migrations become a bear, and porting content to external systems becomes nearly impossible.

Here are some tips for how you can improve your content modelling on your next website development project:

Properly Define Your Content Attributes

Most content strategies stop at defining the fields a particular content type should have. Depending on your editorial workflow, you may only want to have content editors select what image assets to associate with an article. Or, you may want to control the terms contributors are able to use when tagging a blog posts, so that free tagging field won't due.

When defining your content attributes, make sure to answers the following questions:

1. Is this field required?

2. Who should/shouldn't be able to enter content into this field?

3. What field type will enable content creators to most easily enter content given your editorial guidelines?

Model Your Assets Off

Seriously. Model your content assets. Don’t rely on the stock image and video management features of your CMS.

First take inventory of the types of assets you will be using with your content and how they will be used.

• How will your assets be organized and searched for?

• Does any metadata, such as department, country, topic, need to be associated with various assets?

• Will images and videos be reusable within various pieces of content?

• Do assets need to be credited to the creator, such as a photographer or videographer?

• Will images appear in a gallery or be embedded within content?

• Will assets only be attached to content via fields or will they be accessible through your WYSIWYG editor?

Once you have a good sense of your asset management needs, select the best asset management system for you. There are a number of customizable plugins or modules for content management systems that will offer the appropriate asset management tools that align well with your content model. If you have a large library of assets, look into using an external asset management system like Alfresco. These systems typically offer integration with CMS systems like Drupal.

Determine Your Needs for Microcopy

If you are not familiar with microcopy, it is a shorter variation of a content attribute, like a title or news article description. Microcopy can be used in many different ways, but it is typically used for displaying teasers on listings of content or in content previews on social media posts.

When you are trying to draw a reader in to read a full post, you want to grab their attention. Microcopy is a great way to develop content that draws people into  your website. If your micro-title is what will appear as the preview title when you post your article to Facebook, then create one that will generate the highest amount of clicks. Be witty or suspenseful.

Not every organization is going to have the desire or ability to develop microcopy for every piece of content. Gauge your writers’ tolerance for this before building microcopy into your content strategy. If your team won’t write it, then don’t build it into your content model.

Make Sure You Have the Right Metadata

Metadata is not only important for SEO, it is important for content portability. When your blog posts are shared by your readers on Facebook, you probably want an enticing thumbnail image to appear rather than a larger version of your favicon.

Think strategically about how your content is going to be discovered, and how it will appear on each external platforms. Then determine what metadata will need to be present in order for an external platform to generate the appropriate representation of your content.

Here are some type of metadata you will most likely want to have on your website:

• Meta tags

• Site verification code

• Open Graph markup

• Twitter Cards markup

• Google+ authorship tag

 

Did you plan for any of these areas when developing your content models?

“I used to believe building an awesome website is rocket science, but drupal proved me wrong”, said one of the student who attended our workshop on Drupal.

Personal blog tags: trainingGlobal training daysDrupal Bangalore

There is a saying that “a whole is greater than the sum of its parts”.

However, often communities such as Drupal can get so tied up with (albeit healthy) internal competition and rivalry that the bigger picture and the outside world are forgotten.

A great example of this is the reoccurring discussion about duplicate modules.

Whilst I admit there is a place for it, I think often it distracts us from a bigger and better goal.

New Drupal users will be gained externally

I would like this article to persuade you as a reader (if you are a user or developer of Drupal) that you will benefit as Drupal grows.

Increased usage of Drupal brings more people that will write code, more exposure that tests features to their limits, and more opportunities for the resulting improvements to be contributed back so that your projects benefit from them in the future.

The resulting halo brings more users to modules that you use, meaning that these benefits are tangible for you.

Does this sound good to you?!

However, growth does not come by winning users between one module and another.

Growth comes because a user who may not have used Drupal for their project comes to your module.

As an example, as a maintainer of the Project Management Module, I don't wish to position it as a competitor to Case Tracker, ERPAL, or Project*.

Instead, I want potential users to know that there are robust project management and ticket tracking solutions based on Drupal, and for them to choose the most appropriate solution for their situation.

An example

I would like to highlight and complement the Drupal Commerce modules for doing this really well.

Unrelated to how technically good they are, they are seen outside of the Drupal community as a strong competitor in the e-commerce space.

These modules help draw new users to Drupal.

To illustrate this, recently I was helping a friend design an online store, and received from his payment provider a list of the supported software packages. Drupal Commerce was on the list.

Potential users do not think “what modules are available for Drupal?” They think “which solution will best fit my needs?”

Drupal Commerce is not competing with Ubercart, or any of the payment provider specific modules, but is actively encouraging new users to Drupal.

Even if you don’t use e-commerce functionality, this benefits you too.

Practicing External Competition

Now that I’ve built the case for competing externally and drawn out one set of modules that does this particularly well, it is time to consider how you too can practice external competition.

I don’t think I’ve got a golden ticket for this, but there are three steps that are commonly used and I think are worth noting:

1. Create a standalone project homepage

Whilst Drupal.org has great infrastructure for hosted contributed modules, if you are looking for a module on Drupal.org, you have probably already chosen Drupal as your CMS.

Having a separate website allows the text to be more focussed on a different target audience - those who are not currently using Drupal. Plus, you could draw out that your module is build on top of a popular, robust CMS as an additional feature. The site could promote Drupal as much as your module.

These sites may help inspire you: Drupal Commerce, Aegir, ERPAL, or Project Management.

2. Build a distribution

New users often want to try something out quickly, and may not have the time (or skills) to configure for a proper test.

For these situations, a distribution that packages your module, all dependencies and add-ons that improve the experience is very helpful.

Take a lesson from Commerce Kickstart and give the option for demo content too.

Even developers may use a distribution to learn about your module, before using your module directly for a specific project.

3. Rewrite your Drupal.org project page

Few of the project descriptions on Drupal.org project pages are designed with a new user in mind.

If you are a maintainer - look at yours now.

Does the description explain the point of the module, simply and clearly...?

...Or does the text dive straight in with a description of which databases your module is compatible with?

Each project page will be unique, but they are worth a critical review (for projects that could be used externally, rather than utilities).

Perhaps one day the Drupal.org project page will have more structured fields, I think this will help a lot too.

 

What do you think?

Please join in the discussion in the comments.

Category: WebsitesTags: DrupalDrupal PlanetcompetitionMaintaining an Open Source Module

Earlier this month published ‘reposervice’ to GitHub. Reposervice is a “self-contained” Islandora installation source tree that is intended to smooth the LYRASIS deployment of repository services between development servers, a staging server and production servers. It is a bit of a work-in-progress at the moment, but others might find it useful as well.

(By the way, if you had looked at Reposervice prior to June 18th, you may have noticed a missing critical element — the Drupal submodule. Not because you couldn’t add Drupal yourself but because the Reposervice clone has relative soft symlinks to the Islandora modules positioned in the top level Reposervice directory.)

The goals of this setup are listed in the README file:

• Put (most) everything in a self-contained directory using relative paths for most components with a configuration script that generates configuration files for absolute paths.
• Make it easy to track the upstream Islandora work so that you can bring selected commits into your own environment, if desired [using git submodules].
• Put the configuration of Fedora Commons, FedoraGSearch, SOLR, and other associated components under version control.
• Use Drupal Features to store the Drupal configuration and put it under version control.
• Support multi-site setups for separate Islandora/Drupal instances using a common Fedora Commons, SOLR, and djatoka installation.

The first four bullets are there along with hints of the fifth. (There is some as-yet unfinished, uncommitted code that automates much of the work of creating multi-site setups under a single Drupal installation.)

When I sent a note about this to the islandora community mailing list, I got a helpful reply back from Nick Ruest pointing to some work that Graham Stewart of the University of Toronto had done using Chef.

Date: Thu, 13 Jun 2013 12:39:50 -0400
From: Nick Ruest
To: islandora@googlegroups.com
Subject: Re: [islandora] A ‘DevOps’ Configuration for Islandora

I nearly forgot! Graham Steward at UofT has a few recipes up in his
Github account[1] and there is a recording of his presentation from the
2012 Access[2].

-nruest

[1] https://github.com/librarychef
[2] http://www.youtube.com/watch?v=eTNBmy4ZznA

The recording of the presentation is a great introduction to Chef from a library perspective; Graham builds an Islandora 6.x installation from scratch in 624 seconds. The Ruby-based islandora12.rb recipe indeed has a great deal of resemblance to the bash scripts I was creating to deploy the components into the central directory tree. I’m going to have to add Chef to my list of things to learn, and Graham’s call of cooperation in building library-oriented recipes is a compelling one.

There are a few LYRASIS-specific things in here, but I’ve tried to make the basic building blocks replicable for others. This git repo, as it is further developed and documented, will be the foundation of a presentation I’m giving at Open Repositories next month. Comments, questions, observations, and even pull requests (should you find this setup useful in your own work) welcome!

Link to this post!

As a purely Drupal development agency, we are always looking for ways to improve our experience with Drupal.

One of the most common scenarios we experience is getting developers to keep track of block settings during deployment.

On all but the most basic of sites there can be hundreds of blocks, and when a team of developers are working together on a big project some of these changes can be forgotten or overlooked.

Issues vary from an 'oops!' because a bit of content dissapeared for a moment, to problematic when a block's PHP visibility snippet has been copied incorrectly or missed, resulting in a WSOD and a hasty database roll-back. (At least it's only on staging!)

In keeping with the Drupal community spirit, our solution comes in the form of a contrib module which everyone can benefit from:

 

Introducing Extended block visibility

Extended block visibility pulls Drupal's block settings out of your database and plants them firmly in your custom module.

Each block is allocated a list of candidate functions, any of which can be used to determine whether or not the block should be shown.

This means we can edit block visibility settings in our editor of choice (rather than inline on the site) and we can keep track of it all in git, which makes for really easy deployments.

 

You can download Extended block visibility from Drupal.org. Alternatively, please get in touch if you would like Drupal training or developer support.

At Lullabot, while working for a client's project, we assign resolved tickets to other bots for peer review. This process has turned out to be very effective in helping knowledge share, improving our coding standards and doing general QA (note: this does not exclude an external QA test).

One of our member came to use with a question about usernames.

After installing the Advanced Forum module, they noticed that Drupal was posting usernames. The same thing was happening for comments and elsewhere on the site.

Our member wondered if it was possible to replace these plain usernames with people's real names. Yes it is, if you use the Real name module.

We're going to show you how to create a calendar in Drupal.

This tutorial is ideal for people who want to show a monthly, weekly or daily list of upcoming events.

First, we'll show you how to set up a basic Calendar and then we'll modify it to the needs of your content.

Balazs Dianiska, Acquia Professional Services Consultant, has a lot of insight about the needs of enterprise businesses. Whenever he can, he shares that insight with the Drupal community at events and meet-ups.

balazs_dianiska_final.mp3

My name is Panagiotis Moutsopoulos and I am the most recent member of the Netstudio.gr team. I have been part of this great team for a few months but I never had the needed time to say "Hi!". Wondering about what I should write, I thought of what Ernest Hemingway used to think: “Do not worry. You have always written before and you will write now. All you have to do is write one true sentence. Write the truest sentence you know".

Once/if you have multiple languages configured on your website, selecting from them for the page becomes an important question. The Drupal 8 language detection and selection options are located the same place they were in Drupal 7 but almost all options got some improvement.

Useful out of the box

Drupal 7 only had the default language detection method turned on, so even if you kept adding in more and more languages (and even if you enabled the language switcher block), the URLs did not work. You still needed to get here and configure the URL detection method. Now this is built-in, so adding languages and placing a selector block would in itself make multiple languages accessible.

Query coder allows you to convert SQL queries into dynamic queries. The module offers a simple UI where you can paste in a SQL query, press submit and then you're presented with a dynamic query code example.

In Drupal 7, you can query the database in two ways; using a static or a dynamic query. Static queries are the simplest to write and the fastest from a performance stand point. A static query will suffice for general SELECT queries.

Dynamic queries on the other hand can be tricky and takes some getting used to. One benefit of using it is that other modules can modify the query by implementing hook_query_alter.

by Jeff Amaral

The Challenge:

Display the second level menu items of the currently active page, fully expanded, in the left sidebar of every page but the node edit form. And have this configuration saved in code so that every member of your development team can have it all work automatically.

Drupal menus allow you to hierarchically organize the content on your site. In Drupal 7, there are four system menus available by default: Navigation, Management, User menu, and Main menu. The Main menu is generally used for primary navigation (AKA the links generally shown at the top of every page).

All menus in Drupal can be displayed in one of two ways: as a variable in your theme settings or as a block. These blocks are limited. They will display the full menu (including top-level items) and, by default, only expand one of those top-level items if you are on a child page.

Want to show only the second level of the menu with the current page activated? Or the third? Want to expand all of the menu items so you can suckerfish them? You can’t.

Because of these deficiencies, lots of Drupal site builders turn to Menu Block, an incredibly popular and useful module....

In my new position at Drupalize.Me I have the luxury of helping a lot of projects in little ways. Being able to context switch quickly helps a lot. This means I've put a lot of time into how my workstation is setup so that I can easily move from one project to another. With the new job I also decided to add OSX to the mix of computers that I use on a daily basis.

read more

While working for Acquia in the last few months – helping them maintain Drupal Gardens – I had two tasks that required to write small modules. In this blog post, I would like to introduce these modules.

Safer Permissions

The first one is Safer Permissions.

Written on June 18, 2013 - 11:27

First of all: I'm a featured speaker. I'll be hosting a session called 'Drupal 8 for Site Builders'. Come and watch to get an overview of all the wonders and power Drupal 8 has for creating a site. However, there are other reasons to attend DrupalCon Prague, and they are not Drupal related at all.

Kutná Hora

Kutná Hora is a little town, about 80 kilometers away from Prague, world known for its Sedlec ossuary which contains a lot of human bones, used for decorating the inside. While this may sound luguber, a visit to this small chapel is not something you will ever forget. And if you don't go inside, the top of the chapel has a skull, they really thought about everything. The easiest way to get there is by train and even arriving in the small station is worth travelling. I have seen it already, but will be going again, so feel free to join me.

CERN opendays

CERN, the European Organization for Nuclear Research, is opening its doors on 28th and 29th of september for the public for it so called CERN opendays. CERN lies in Geneva, Switserland, about 8 hours driving from Prague, or maybe 1 hour flying by plane. You'll be able to go down 100 meters underground and look at the Large Hadron collider and all other amazingly cool experiments scientists and engineers perform. Unless you are Daniel "dawehner" Wehner, you don't get that many chances to visit this place in your lifetime, especially since they only open it up publicly every 4 years. Tickets are for sale starting August, so keep an eye on the website if you want to go. That means I won't be attending the post-sprints, but honestly, I can live with that.

The DrupalCon Prague team welcomes you to submit to our call for content for our September conference.

Why content, not papers? Well, the DrupalCon program has changed since we last did the call. We've listened to feedback from DrupalCon attendees, and we're hoping our new direction will really resonate with our audience. In addition to our regular great offerings of Sessions, BoFs, CXO, Keynotes and Training, we're excited to roll out a few new initiatives.

Recently, I had a need to be able to backup a Drupal database but to skip a number of tables that I didn’t care about; mostly tables related to caching. Given most of these tables are prefixed with cache*, I was hoping for a way to specify tables to ignore using a wildcard character like ‘%’ or ‘*’.

A discussion on responsive Sass strategy and how to solve the common problem of numerous grids needing varying numbers of columns across many breakpoints. Can we accomplish this with one mixin?

Building sites using Drupal Commerce is something we often do at Marzee Labs, but when EnjoyThis approached us to build an e-commerce site for The London Distillery Company featuring a “design your own whisky cask” part, we immediately seized that opportunity to do something different. In this post, I’ll review the architecture of the project.

Challenges

The new site for The London Distillery Company had to appeal to a young urban crowd. EnjoyThis took on the challenge of creating a visually appealing design using big images, bold typography & plenty of videos (which they shot themselves).

Drupal Commerce was chosen to build the site, which needed a lot of customization that would have been beyond most open-source ecommerce platforms. We needed multi-country & multi-continent shipping which influences shipping costs, delivery times & taxes. We also needed to offer customers the possibility to use coupons, so they’d get free shipping, receive a percentage off their purchase, or get a free bottle for every three bottles they buy.

The most challenging part of the project was to allow visitors to design their own bespoke casks, choosing from options such as barrel size (40 liters, 180 liters, or 220 liters, for the very thirsty ones!), wood type and barley. Every one of these options has a different price and attributes, and some of the options would in turn enable more options. For example, if you pick the Maris Otter barley type, you might want to take the peated or the non-peated version.

After the user has customized his or her own cask, we allow them to share their configuration via mail, Twitter or Facebook, so we needed unique URLs for every cask combination.

The first step in the “design your own whisky cask” process. Selecting a different option triggers an AJAX request that loads a different product combination. Try it out yourself.

UX and Front-end

The secret of marrying a good UX implementation to the one-pager “design your own cask” is very simple: relying on what Drupal Commerce gives us. The danger would be to sink in heavy template usage to accommodate the markup. Instead we used a couple of preprocess functions, as well as the standard and almost untouched commerce HTML.

Javascript-wise, we pass very limited amount of variables from Drupal PHP to Drupal behaviours, and hook our code to rely on what Drupal Commerce gives us. This means that we don’t have to hack our way around, and can keep the custom code down to a fairly human, understandable level. That said, we did hit a few walls, and butted our heads against the desk a couple of times, especially in some event bubbling that commerce was “offering” us.

All in all, the best decision we made for this uncommon commerce page was to keep most of what Drupal Commerce would give us out of the box and do a make up with jQuery rather than reinventing the wheel.

Under the hood

To build out the “design your own cask” tool, we started from a description and a price for each of the attributes that would made up the final cask: a 20-liter barrel costs that much, adding the peated option would add that much, etc.

We made the maths and found that a user can chose between roughly 200 different cask combinations. Each combination is built out as a separate product and bundled in one single product display (see the bespoke page), taking advantage of Drupal Commerce’s flexible product / product display separation. We built a script to generate the different combinations, and used Commerce Feeds to get that data into Drupal. Future price changes are then easily synced using the built-in synchronization of Commerce Feeds.

Each combination also shows a breakdown of the costs of each selected attribute. Selecting the “peated” option for the barley type would add an additional 200 pounds for example. We store that data in a separate node that is referenced from the product entity. Every time an attribute is selected by the user, we receive a correct reference to the price breakdown node of that particular combination and extract these components using jQuery.

The third step in the cask configuration. The visitor can choose the type of barley, which in turn triggers new choices.

We are very happy with the final site, especially the "Bespoke Tool" which we recommend you try out. Drupal Commerce proved to be a very flexible framework, even for a use case that requires more than just the typical product pages.

Disclaimer: our friends at EnjoyThis designed the whole site, including beautifully shot images and videos to promote the whisky distillery. Marzee Labs architected and implemented the e-commerce part using Drupal Commerce and implemented the User Experience of the “design your own cask” part.