Join us at the next Drupal Media sprint at the Mountain camp in Davos!

Are you excited about the recent improvements in Drupal core Media? Would you like to join us at one of the next sprints and help us reach our goals? Now you can!

Drupal Mountain Camp 2017 will happen between 16th and 19th February in the lovely Davos. Drupal, code community, snow, fondue, outdoor activities and much more. Definitely something that should not be missed!

And the best part? There will be Media sprint going on throughout the event. Eager to join? Simply add yourself to the sprint attendance list and show up. We promise you the best sprint ever!

slashrsm Fri, 06.01.2017 - 23:19 Tags Drupal Media Sprint Enjoyed this post? There is more! Results of the Drupal 8 media sprint Presentations about various Drupal 8 media modules Call for Drupal 8 media ecosystem co-maintainers Drupal dev environment on Docker

Republished from buytaert.net

Nine months ago I wrote about the importance of improving Drupal's content workflow capabilities and how we set out to include a common base layer of workflow-related functionality in Drupal 8 core. That base layer would act as the foundation on which we can build a list of great features like cross-site content staging, content branching, site previews, offline browsing and publishing, content recovery and audit logs. Some of these features are really impactful; 5 out of the top 10 most requested features for content authors are related to workflows (features 3-7 on the image below). We will deliver feature requests 3 and 4 as part of the "content workflow initiative" for Drupal 8. Feature requests 5, 6 and 7 are not in scope of the current content workflow initiative but still stand to benefit significantly from it. Today, I'd like to provide an update on the workflow initiative's progress the past 9 months.

The top 10 requested features for content creators according to the 2016 State of Drupal survey. Features 1 and 2 are part of the media initiative for Drupal 8. Features 3 and 4 are part of the content workflow initiative. Features 5, 6 and 7 benefit from the content workflow initiative.

Configurable content workflow states in Drupal 8.2

While Drupal 8.0 and 8.1 shipped with just two workflow states (Published and Unpublished), Drupal 8.2 (with the the experimental Content moderation module) ships with three: Published, Draft, and Archived. Rather than a single 'Unpublished' workflow state, content creators will be able to distinguish between posts to be published later (drafts) and posts that were published before (archived posts).

The 'Draft' workflow state is a long-requested usability improvement, but may seem like a small change. What is more exciting is that the list of workflow states is fully configurable: you can add additional workflow states, or replace them with completely different ones. The three workflow states in Drupal 8.2 are just what we decided to be good defaults.

Let's say you manage a website with content that requires legal sign-off before it can be published. You can now create a new workflow state 'Needs legal sign-off' that is only accessible to people in your organization's legal department. In other words, you can set up content workflows that are simple (like the default one with just three states) or that are very complex (for a large organization with complex content workflows and permissions).

This functionality was already available in Drupal 7 thanks to the contributed modules like the Workbench suite. Moving this functionality into core is useful for two reasons. First, it provides a much-requested feature out of the box – this capability meets the third most important feature request for content authors. Second, it encourages contributed modules to be built with configurable workflows in mind. Both should improve the end-user experience.

Support for different workflows in Drupal 8.3

Drupal 8.3 (still in development, planned to be released in April of 2017) goes one step further and introduces the concept of multiple types of workflows in the experimental Workflows module. This provides a more intuitive way to set up different workflows for different content types. For example, blog posts might not need legal sign-off but legal contracts do. To support this use case, you need to be able to setup different workflows assigned to their appropriate content types.

What is also interesting is that the workflow system in Drupal 8.3 can be applied to things other than traditional content. Let's say that our example site happens to be a website for a membership organization. The new workflow system could be the technical foundation to move members through different workflows (e.g. new member, paying member, honorary member). The reusability of Drupal's components has always been a unique strength and is what differentiates an application from a platform. By enabling people to reuse components in interesting ways, we turn Drupal into a powerful platform for building many different applications.

Drupal 8.3 will support multiple different editorial workflows. Each workflow can define its own workflow states as well as the possible transitions between them. Each transition has permissions associated with them to control who can move content from one state to another.

Workspace interactions under design

While workflows for individual content items is very powerful, many sites want to publish multiple content items at once as a group. This is reflected in the fourth-most requested feature for content authors, 'Staging of multiple content changes'. For example, a newspaper website might cover the passing of George Michael in a dedicated section on their site. Such a section could include multiple pages covering his professional career and personal life. These pages would have menus and blocks with links to other resources. 'Workspaces' group all these individual elements (pages, blocks and menus) into a logical package, so they can be prepared, previewed and published as a group. And what is great about the support for multiple different workflows is that content workflows can be applied to workspaces as well as to individual pieces of content.

We are still in the early stages of building out the workspace functionality. Work is being done to introduce the concept of workspaces in the developer API and on designing the user interface. A lot remains to be figured out and implemented, but we hope to introduce this feature in Drupal 8.5 (planned to be released in Q2 of 2018). In the mean time, other Drupal 8 solutions are available as contributed modules.

An outside-in design that shows how content creators could work in different workspaces. When you're building out a new section on your site, you want to preview your entire site, and publish all the changes at once. Designed by Jozef Toth at Pfizer.

Closing thoughts

We discussed work on content workflows and workspaces. The changes being made will also help with other problems like content recovery, cross-site content staging, content branching, site previews, offline browsing and publishing, and audit logs. Check out the larger roadmap of the workflow initiative and the current priorities. We have an exciting roadmap and are always looking for more individuals and organizations to get involved and accelerate our work. If you want to get involved, don't be afraid to raise your hand in the comments of this post.

Thank you

I tried to make a list of all people and organizations to thank for their work on the workflow initiative but couldn't. The Drupal 8 workflow initiative borrows heavily from years of hard work and learnings from many people and organizations. In addition, there are many people actively working on various aspects of the Drupal 8 workflow initiative. Special thanks to Dick Olsson (Pfizer), Jozef Toth (Pfizer), Tim Millwood (Appnovation), Andrei Jechiu (Pfizer), Andrei Mateescu (Pfizer), Alex Pott (Chapter Three), Dave Hall (Pfizer), Ken Rickard (Palantir.net) and Ani Gupta (Pfizer). Also thank you to Gábor Hojtsy (Acquia) for his contributions to this blog post.

As Gene Kim, American entrepreneur and founder of Tripwire, says, DevOps is “not yet a precise collection of practices, descriptive or prescriptive.”[1]  Similarly, as Drupal enters its own era of philosophical movement towards Drupal 8, what more fitting time to focus around how we can bridge the gap between Developers and Operations to further improve our DevOps workflows.

In the DevOps Track Description, we drew comparisons between Development and Operations being like Peanut Butter and Chocolate.  Some people might think this analogy is stretching the limits or just an easy way to justify having a bunch of Peanut Butter Cups on my desk but the correlation between Peanut Butter and Chocolate is the same sort of philosophical relationship we look for between Development and Operations teams.  This philosophical relationship is what we hope to explore during the DevOps track at DrupalCon Baltimore.

The problem:

Content management systems are extremely powerful, in that they let developers focus on what they do best – build the infrastructure of a site, while allowing content editors to do what they do best – create content.

But this can be a problem when building a new feature. How often have you heard something to this effect:

Developer: “That blank spot right there will be a neat slideshow, once you build it.”

Client: “I thought I was paying you to build it.”

The separation between content and development can lead to missed edge cases, unfounded assumptions, and wasted time for everyone involved.

There are a few workarounds to this problem. We often prototype our sites with dummy content (insert your favorite Ipsum here). But this, without fail, leads to some nasty surprises when the client starts entering real content. It’s suddenly much longer (or shorter) than the designer or developer intended. Or maybe the images are far too big. Or they’re all portraits where we expected landscapes. In short, the arguments made against using Lorem Ipsum in designs go doubly once you start actually implementing fields on your Drupal site.

So what about more meaningful content – maybe exported from another source? Modules like Default Content allow developers to export certain content for import during the initial site build. But that content has the disadvantage of requiring a developer’s intervention. The more of a nuisance it is to update the content, sync the database, change the fields, etc, the less likely you are to keep the content up-to-date.

At ThinkShout, we want to populate our client’s sites with content as soon as possible.

It doesn’t need to be the final content…

But it should be real content.

It shouldn’t necessarily be exactly what’s on the old site…

But it ought to be close…

In other words, our initial content needs to be easy to change – easy enough that the client can do it. Easy enough that the developers don’t have to take a walk around the block to calm down when they find out the fields are changing (again). Easy.

Our Solution Part 1: Migrate

“But isn’t Migration to Drupal hard?” I hear you saying.

It certainly was in Drupal 7, where the Migrate module had a (deserved) reputation for being difficult to use. Migrating from one Drupal site to another, or even from Wordpress to Drupal was relatively smooth, but if you really wanted to do something unusual, like migrate from a less-common CMS to Drupal, you were going to be writing a lot of custom code “glue” to get it all working.

In D8, Migrations have been moved to core. This means a few things. First, it means the core concept of entities is baked right in. In D7 migrations, you often had to hunt around for a plugin, hoping someone had written a Destination Handler for your favorite oddball entities, like Redirects, or Addresses, or the dreaded Field Collections. In D8, an entity is an entity.

As such, with a solid knowledge of the helpful migration plugins and two essential contributed modules, Migrate Tools and Migrate Plus, you can write a robust migration of both content and config entities without writing code more complicated than a few .yml files. If you don’t believe me, I encourage you to try upgrading your D6 or D7 site to D8 on a local or dev environment to see how much of your data is already in there.

That being said, what if I don’t have an existing site? Or what if I want to implement a new content strategy to go along with my fancy new site?

Our Solution Part 2: Google Sheets

Throw that new content into a Google Doc!

Yes, spreadsheets are old school, but let’s take a minute to appreciate what they give us.

• Spreadsheets are familiar. When it comes right down to it, spreadsheets are the universal language of business. Putting content into little boxes gives us the ability to move those boxes around, highlight them, and sort them – few UX experiences can get you so much information so quickly.

• Spreadsheets are dynamic. It doesn’t take hours of database planning to get information into a spreadsheet. Nor does it take hours of testing to rearrange or remove items from a spreadsheet. It doesn’t demand anything of your data architect other than “organize things by columns and rows.”

• Spreadsheets are sharable. We can enable a Google spreadsheet and share it with the client in a few minutes. Clients can start entering their data from day 1 (alright, maybe day 2 or 3). And they can update content as needed – take it out of the sheet, update things, and change them.

• Google spreadsheets have revisioning built in. If someone really messes up a Google Doc, you can go back through its history and revert it. It’s a nice compromise between committing all your initial content to source control or just letting it live freely.

Ready to give it a shot?

Stay tuned for Part 2 of this series, where I go into detail about how to set up your own Google sheet Drupal 8 migration.

Can’t wait? Check out the Migrate Google Sheets module now! We’ve even set up a sample site where content comes entirely from an external spreadsheet to help you get started.

You used to know Internetdevels as a reliable Drupal development company. We are always trying to satisfy your every need, which is why our team was recently enriched with specialists dealing with .NET. Now you have an opportunity to choose a CMS appropriate for your site.

Read more

I was asked to find a way to collect log messages from 100 websites that were running on Drupal (version 7) and make them available for evaluation as one of the last steps of a long-running test suite.  Here is one of the ways Drupal logs can be collected into a Kinesis stream.

Drupal Mountain Camp: Call for Sessions closing soon!

With 16 February 2017 fast-approaching, Drupal Mountain Camp is closing the call for sessions at midnight CET on Sunday, 8 January, so hurry and submit your talk today.

Daniel Lemon Fri, 01/06/2017 - 13:33

What and When is Drupal Mountain Camp?

The camp is designed to mix the beauty of the Swiss Alps, sprinkled in snow, with the warmth of the Drupal community. It's a perfect combination of fresh tracks for those who ski or snowboard with inspirational talks by amazing people topped with Swiss cheese & chocolate.

The camp will happen from 16 to 19 February 2017 at the Davos Congress Centre.

Final call for sessions

The closing for call for sessions is rapidly approaching, so submit your talks as soon as possible! There is already over 30 great sessions with 2 confirmed key-notes by Laura Gaetano and Preston So.

Does that sound interesting and do you want to know more about the process to submit your session topic? Well, read on:

How can I submit a session?

So you've got something you'd like to talk about, awesome, here's how you can submit a session:

1. Head on over to the submit a session link.
2. Think of a catchy-title and fill in the Session Title.
3. What is your talk about? Try to write 4-5 lines about what you'd like to talk about in the Description textbox.
   • Note: you can add images if it helps portray your talk.
4. Select what kind of Session Type (how much time) you'd like.
5. Select the appropiate Tracks - you can select multiple if your talk covers various topics.
6. Select the Level of expertise - is it more of a beginner talk or does it become quite advanced with technical terms?
7. Don't forget to add your Speaker name and Contact email.

Well that sounds easy, but why should I submit a talk?

Public speaking rates high among the top 5 phobias by people right alongside going to the dentist and flying. Why would anyone put themselves through that? Well, everyone has their own reasons, but here's what I've gathered.

• Giving a talk will require a lot of work and preparation, but don't let that put you off. It will pay off in the end.
• People who attend your talk are generally looking for help in your specific topic, so this will be a great time for networking.
• You'll be noticed and people will tell you that you're cool.
  • Ok, maybe you don't want to be noticed, and maybe you're fine with not being called cool, but you'll definetly have fun talking.
• You'll feel way more confident afterwards, which might be a good enough boost for you to jump on a snowboard and hit the slopes on the weekend.

There are some great talks already submitted for example on topics like Migrations, Styleguide, and Paragraphs. 

"I don't know if my session is good enough."

Don't worry. There's help available, you can contact Josef / dasjo directly or get in touch with the organising team via the contact email on the camps website. We are happy to provide feedback about possible talk topics and the general agenda.

Is it fun to speak at events?

Yes. Not only will you further cement your knowledge on the topic by giving a talk about it, you'll also learn from your peers who attend your talk.

So, go ahead and submit your talk and we'll see you 16-19 of February in Davos, Switzerland. In the meantime, follow the camp on Twitter.

The Drupal Project Productivity Curve

There are a lot of things that make Drupal projects unique from your typical software development projects, but one of the most interesting to me is the productivity curve.

Specifically, Drupal projects tend to have lots of visible progress at the start and then things slow down considerably. In contrast, many (most?) non-Drupal projects are the opposite - they have little to show at the beginning but things are being cranked out really quickly closer to the end.

Here's a very technical graph to illustrate:

A typical Drupal project

Drupal projects make the first 80% pretty easy and the last 20% really freaking hard, which is the exact opposite of many other common frameworks or technologies. Let's look at an example.

You're building a community site for shoelace enthusiasts. It contains a forum, a blog with commenting, some basic page content, media upload and browsing, photo albums, whatever. All the normal stuff that you see a lot.

The interesting thing here is that Drupal allows you to build simple versions of all of that stuff really quickly in the GUI without having to do any real "work" (i.e., programming). You can have a working (for some definition of that word) site up in a matter of days or a couple weeks at most that satisfies the high level requirements.

But of course, that's not good enough. We just have a bunch of generated markup dumped onto pages, which looks horrible and is nowhere near the mockups. We need theming, and we have a boat load of tweaks to make to functionality. This field needs to be split into two columns. That sidebar needs to only appear on pages that match a specific URL pattern. The blog needs to allow for customizing the sort order of the first 5 items. We need an extra wrapper div around a specific field so that our stupid 3rd party JS lib can find it. We need to add a custom exposed filter that Views doesn't support out of the box. We have to change the available values for a select list but Drupal is complaining that that field already has data. Drupal makes all of these things difficult because it has to, by nature of what Drupal is.

What we basically had after those first couple weeks is a prototype. Drupal is in a world of its own (in a good way) when it comes to prototyping CRUD. It's all the stuff that comes in the conversion from the prototype to the real, living-and-breathing, hard-to-break-by-even-the-dumbest-of-users, looks-like-something-not-designed-by-a-programmer, website. Altering markup is tough (yes, even if you're just overriding a template). Theming in general is tough. Making little tweaks to functionality or behavior is tough. Drupal is just opinionated to the point that stuff that would be easy in non-Drupal sites becomes a pain. And again, that's not a bad thing. It's just a natural result of what makes Drupal Drupal.

A Typical Non-Drupal Project

(First of all, this is pretty wishy washy because "Non-Drupal" can mean anything from Dreamwaver generated to whatever the latest Rails release is now. So bear with me and keep an open mind for now.)

Remember when I said Drupal makes the first 80% really easy and the last 20% really hard? Well, you must know what's coming next then. 

In general, non-Drupal projects tend to make the first 80% tougher than Drupal, but the last 20% is drastically easier.

It takes a while to create your DB structure, models or data structure, admin forms with things like WYSIWYG and image cropping, user authentication and permissions, content detail pages and listings, user facing forms, user registration and password reminders, comments on content items with threading, etc. All of that stuff can be a big pain, and there's drastically more manual work involved than with Drupal.

But once you have that done, and you've reached the "working" site stage mentioned in the previous section, the rest is really easy. It's easy to split something into 2 columns when you wrote the markup in the first place. It's easy to alter behavior that you yourself defined in code. It's easy to decide when and where a sidebar should appear when you are the one that told it where/how to appear in the first place, in code.

Theming is quicker. Tweaks are quicker. Moving this thing into the footer and that thing into the sidebar is quicker. All of the types of things that tend to make up the last 20% of the project are just much easier to do than if you were using Drupal

Why the difference?

Why are the 80% vs. 20% times so different between Drupal and non-Drupal projects? I think it comes down to one thing: who wrote the code.

One of the main draws of Drupal is that you can accomplish so much without having to write a line of code. This means that a lot of your functionality is powered by code that someone else wrote.

Not writing that code means that it's tougher for you to change things when needed, for two reasons:

1. You just aren't as familiar with it. It takes you a while to understand what the original writers were doing, how they were doing it, and what the best way to make your change will be. The bigger the module that you're altering, the tougher this tends to be, and that's unfortunate because most of the really common modules (i.e., the ones that most commonly need to have their behavior altered) are pretty huge. 
2. You can't just go edit the file wherever it exists in core or contrib, like you could if it was custom code. Hacking contrib or core is a big no-no in Drupal-land so you have to spend your time in alter hooks, preprocess functions, overridden templates, or patches. There's nothing quite like spending hours trying to find a hook that would work or a template that you could override (and with what naming convention?!) just to add a stupid wrapper div to a stupid thing you need to wrap, which would take 2 minutes if you wrote the template to begin with.

So that's the difference. That's why the first 80% is easier with Drupal (because you're able to stick to the pre-written code) and the last 20% is harder (because you've having to extend/alter/theme the pre-written code). 

So what?

Why does it matter? Slow start and fast finish vs. fast start and slow finish, who cares as long as it all gets done eventually and in about the same amount of time?

Well, clients care. You know how we're supposed to be under-promising and over-delivering? Using a fast start/slow finish approach makes this kind of tricky. Stakeholders often don't see "percent complete" in terms of hours spent vs. the budget, or time left until the deadline, or any of those actual numeric factors.

Instead, it often ends up just being a "feel" thing. Wow, the site already works, we're really moving fast! I think we may beat the deadline! It "feels" like we've gotten a lot done! We already can add/edit/delete content with all of these fields, and it all appears on the site, and it's only been 3 weeks! All that's left is the tweaking!

You see where I'm going with this? If you show that much visible progress to a not-super-technical client in the first few weeks, then they can expect that much visible progress on a regular basis. It's a bit disheartening as a client to see so much progress in a few weeks, and then only little bits at a time for the next few months.

Well, what's the answer?

Yeah yeah, everything sucks, but what can we do about it? Sadly, I don't think there is a silver bullet.

One thing that can help is to make more of a focus on feature-based scheduling. If you're starting the project by having everyone lay the foundation (fields, content types, listing pages, etc.) for all of the features, then iterating on top of that by theming all of the features, then you run into the problems described above. That's no good.

But if you get everyone working on the same feature (or 2 or 3 features if you have a really big team), and push it through from start to finish before moving onto the next thing, then that at least gets you to "complete" with a specific thing more quickly than if you sort of built them all out at once.

But that's not exactly a revolutionary idea. We've all heard of sprints and MVPs and iterative development, which is why I certainly wouldn't call that approach a silver bullet; it's more like a best practice at this point.

Other than that, I think it's just important that clients are made aware and expectations are set. Make sure they know that they'll see lots of changes at first and then the visible changes will slow down because that's just the way Drupal is. And work really really hard to find places where you can show them complete features, or even better, hand them off so that the clients can play with them in a client-facing dev environment somewhere.

Am I saying that this is a reason to avoid Drupal? Absolutely not. I think Drupal is awesome, and the amount of work you can get done without coding has many pros which far outweigh the one con mentioned in this post. I'm just saying that this is a caveat to keep in mind, and plan ahead for, and explain to clients ahead of time.

mcrittenden Fri, 01/06/2017 - 07:00

Nine months ago I wrote about the importance of improving Drupal's content workflow capabilities and how we set out to include a common base layer of workflow-related functionality in Drupal 8 core. That base layer would act as the foundation on which we can build a list of great features like cross-site content staging, content branching, site previews, offline browsing and publishing, content recovery and audit logs. Some of these features are really impactful; 5 out of the top 10 most requested features for content authors are related to workflows (features 3-7 on the image below). We will deliver feature requests 3 and 4 as part of the "content workflow initiative" for Drupal 8. Feature requests 5, 6 and 7 are not in scope of the current content workflow initiative but still stand to benefit significantly from it. Today, I'd like to provide an update on the workflow initiative's progress the past 9 months.

The top 10 requested features for content creators according to the 2016 State of Drupal survey. Features 1 and 2 are part of the media initiative for Drupal 8. Features 3 and 4 are part of the content workflow initiative. Features 5, 6 and 7 benefit from the content workflow initiative.

Configurable content workflow states in Drupal 8.2

While Drupal 8.0 and 8.1 shipped with just two workflow states (Published and Unpublished), Drupal 8.2 (with the the experimental Content moderation module) ships with three: Published, Draft, and Archived. Rather than a single 'Unpublished' workflow state, content creators will be able to distinguish between posts to be published later (drafts) and posts that were published before (archived posts).

The 'Draft' workflow state is a long-requested usability improvement, but may seem like a small change. What is more exciting is that the list of workflow states is fully configurable: you can add additional workflow states, or replace them with completely different ones. The three workflow states in Drupal 8.2 are just what we decided to be good defaults.

Let's say you manage a website with content that requires legal sign-off before it can be published. You can now create a new workflow state 'Needs legal sign-off' that is only accessible to people in your organization's legal department. In other words, you can set up content workflows that are simple (like the default one with just three states) or that are very complex (for a large organization with complex content workflows and permissions).

This functionality was already available in Drupal 7 thanks to the contributed modules like the Workbench suite. Moving this functionality into core is useful for two reasons. First, it provides a much-requested feature out of the box – this capability meets the third most important feature request for content authors. Second, it encourages contributed modules to be built with configurable workflows in mind. Both should improve the end-user experience.

Support for different workflows in Drupal 8.3

Drupal 8.3 (still in development, planned to be released in April of 2017) goes one step further and introduces the concept of multiple types of workflows in the experimental Workflows module. This provides a more intuitive way to set up different workflows for different content types. For example, blog posts might not need legal sign-off but legal contracts do. To support this use case, you need to be able to setup different workflows assigned to their appropriate content types.

What is also interesting is that the workflow system in Drupal 8.3 can be applied to things other than traditional content. Let's say that our example site happens to be a website for a membership organization. The new workflow system could be the technical foundation to move members through different workflows (e.g. new member, paying member, honorary member). The reusability of Drupal's components has always been a unique strength and is what differentiates an application from a platform. By enabling people to reuse components in interesting ways, we turn Drupal into a powerful platform for building many different applications.

Drupal 8.3 will support multiple different editorial workflows. Each workflow can define its own workflow states as well as the possible transitions between them. Each transition has permissions associated with them to control who can move content from one state to another.

Workspace interactions under design

While workflows for individual content items is very powerful, many sites want to publish multiple content items at once as a group. This is reflected in the fourth-most requested feature for content authors, 'Staging of multiple content changes'. For example, a newspaper website might cover the passing of George Michael in a dedicated section on their site. Such a section could include multiple pages covering his professional career and personal life. These pages would have menus and blocks with links to other resources. 'Workspaces' group all these individual elements (pages, blocks and menus) into a logical package, so they can be prepared, previewed and published as a group. And what is great about the support for multiple different workflows is that content workflows can be applied to workspaces as well as to individual pieces of content.

We are still in the early stages of building out the workspace functionality. Work is being done to introduce the concept of workspaces in the developer API and on designing the user interface. A lot remains to be figured out and implemented, but we hope to introduce this feature in Drupal 8.5 (planned to be released in Q2 of 2018). In the mean time, other Drupal 8 solutions are available as contributed modules.

An outside-in design that shows how content creators could work in different workspaces. When you're building out a new section on your site, you want to preview your entire site, and publish all the changes at once. Designed by Jozef Toth at Pfizer.

Closing thoughts

We discussed work on content workflows and workspaces. The changes being made will also help with other problems like content recovery, cross-site content staging, content branching, site previews, offline browsing and publishing, and audit logs. Check out the larger roadmap of the workflow initiative and the current priorities. We have an exciting roadmap and are always looking for more individuals and organizations to get involved and accelerate our work. If you want to get involved, don't be afraid to raise your hand in the comments of this post.

Thank you

I tried to make a list of all people and organizations to thank for their work on the workflow initiative but couldn't. The Drupal 8 workflow initiative borrows heavily from years of hard work and learnings from many people and organizations. In addition, there are many people actively working on various aspects of the Drupal 8 workflow initiative. Special thanks to Dick Olsson (Pfizer), Jozef Toth (Pfizer), Tim Millwood (Appnovation), Andrei Jechiu (Pfizer), Andrei Mateescu (Pfizer), Alex Pott (Chapter Three), Dave Hall (Pfizer), Ken Rickard (Palantir.net) and Ani Gupta (Pfizer). Also thank you to Gábor Hojtsy (Acquia) for his contributions to this blog post.

Simple twitter feed with custom block Fri, 01/06/2017 - 08:08 In this article, we will present how we built a simple twitter feed in Drupal 8 with custom block and without any custom module. This block will display a list of tweets pulled from a custom list as in the example shown in the side bar.

• Read more about Simple twitter feed with custom block
• Add new comment
• 6 views

Mike & Matt are joined by a gaggle of Lullabots to talk successes and failures of 2016, and what we're looking forward to in 2017.

Custom Preprocessing

In Drupal 7 there were numerous ways to preprocess data prior to migrating values. This was especially useful when inconsistencies in the data source needed to be addressed. One example I have dealt with in the past was migrating email addresses from an old system that didn’t check for properly formatted emails on its user fields. These errors would produce faulty data in the new Drupal site. I preprocessed the field data for the most common mistakes which reduced the amount of erroneous addresses brought over.

As a follow-up to my previous blog post about the usage of Migrate API in Drupal 8, I would like to give an example, how to import multilingual content and translations in Drupal 8.

Prepare and enable translation for your content type

Before you can start, you need to install the “Language” and “Content Translation” Module. Then head over to “admin/config/regional/content-language” and enable Entity Translation for the node type or the taxonomy you want to be able to translate.

As a starting point for setting up the migrate module, I recommend you my blog post mentioned above. To import data from a CVS file, you also need to install the migrate_source_csv module.

Prerequisites for migrating multilingual entities

Before you start, please check the requirements. You need at least Drupal 8.2 to import multilingual content. We need the destination option “translations”, which was added in a patch in Drupal 8.2. See the corresponding drupal.org issue here.

Example: Import multilingual taxonomy terms

Let’s do a simple example with taxonomy terms. First, create a vocabulary called “Event Types” (machine name: event_type).

Here is a simplified dataset:

Id Name Name_en 1 Kurs Course 2 Turnier Tournament

You may save this a csv file.

Id;Name;Name_en
1;Kurs;Course
2;Turnier;Tournament

The recipe to import multilingual content

As you can see in the example data,  it contains the base language (“German”) and also the translations (“English”) in the same file.

But here comes a word of warning:

Don’t try to import the term and its translation in one migration run. I am aware, that there are some workarounds with post import events, but these are hacks and you will run into troubles later.

The correct way of importing multilingual content, is to

1. create a migration for the base language and import the terms / nodes. This will create the entities and its fields.
2. Then, with an additional dependent migration for each translated language, you can then add the translations for the fields you want.

In short: You need a base migration and a migration for every language. Let’s try this out.

Taxonomy term base language config file

In my example, the base language is “German”. Therefore, we first create a migration configuration file for the base language:

This is a basic example in migrating a taxonomy term in my base language ‘de’.

Put the file into <yourmodule>/config/install/migrate.migration.event_type.yml and import the configuration using the drush commands explained in my previous blog post about Migration API.

id: event_type
label: Event Types
source:
  plugin: csv
  # Full path to the file. Is overriden in my plugin
  path: public://csv/data.csv
  # The number of rows at the beginning which are not data.
  header_row_count: 1
  # These are the field names from the source file representing the key
  # uniquely identifying each node - they will be stored in the migration
  # map table as columns sourceid1, sourceid2, and sourceid3.
  keys:
    - Id
ids:
  id:
    type: string
destination:
  plugin: entity:taxonomy_term
process:
  vid:
   plugin: default_value
   default_value: event_type
  name:
    source: Name
    language: 'de'
  langcode:
    plugin: default_value
    default_value: 'de'

#Absolutely necessary if you don't want an error
migration_dependencies: {}

Taxonomy term translation migration configuration file:

This is the example file for the English translation of the name field of the term.

Put the file into <yourmodule>/config/install/migrate.migration.event_type_en.yml and import the configuration using the drush commands explained in my previous blog post about Migration API.

id: event_type_en
label: Event Types english
source:
  plugin: csv
  # Full path to the file. Is overriden in my plugin
  path: public://csv/data.csv
  # The number of rows at the beginning which are not data.
  header_row_count: 1
  keys:
    - Id
ids:
  id:
    type: string
destination:
  plugin: entity:taxonomy_term
  translations: true
process:
  vid:
    plugin: default_value
    default_value: event_type
  tid:
    plugin: migration
    source: id
    migration: event_type
  name:
    source: Name_en
    language: 'en'
  langcode:
     plugin: default_value
     default_value: 'en'

#Absolutely necessary if you don't want an error
migration_dependencies:
  required:
    - event_type

Explanation and sum up of the learnings

The key in the migrate configuration to import multilingual content are the following lines:

destination:
  plugin: entity:taxonomy_term
  translations: true

These configuration lines instruct the migrate module, that a translation should be created.

tid:
  plugin: migration
  source: id
  migration: event_type

This is the real secret. Using the process plugin migration,  we maintain the relationship between the node and its translation.The wiring via the tid field make sure, that Migrate API will not create a new term with a new term id. Instead, the existing term will be loaded and the translation of the migrated field will be added. And thats exactly what we need!

Now go ahead and try to create a working example based on my explanation. Happy Drupal migrations!

We saw in a previous post how we could automatically generate the image styles defined on a site for each uploaded source image. We will continue this post for this time to carry out the same operation using the Cron API of Drupal 8, which allows us to desynchronize these mass operations from actions carried out by users, and which can therefore penalize performances.

We’re very pleased to announce a new beta release of our popular open source Warden software, developed in-house at Deeson and which reports and keeps track of multiple Drupal websites on different platforms. This version updates the MongoDB PHP driver driver version, but also fixes a number of number of other issues.

As well as this, we’re also planning our next release, which we’re looking at including JavaScript library versions (jQuery, Backbone, React.js etc) and server package versions (Apache, Nginx, Varnish, MySQL etc). This will help provide further information about the package versions being used by sites and servers you’re running, helping you understand where vulnerabilities could be and highlight libraries that need updating.

The Warden server software itself is written in Symfony and can be downloaded from GitHub. It works by providing a central dashboard which lists all the Drupal sites a developer might be working on, highlighting any that need issues, for example those that need updates. It’s composed of two parts - a module which needs to be installed on each of your websites and a central dashboard hosted on a web server.

Hosting companies like Acquia and Pantheon have their own reporting tools, but only if work if you only host websites on their platforms. If you have a number of websites running on multiple platforms, you need Warden to report on them all. Here is a guide to how Warden works.

Last month we began with an overview of our blogs that were written in November. We promised that from now on, at the beginning of every month, you will be able to see, which Drupal blogs we have written for you over the past month. With that, you will be better informed. So, here's our December's work. Besides an overview of November's blogs from us and from other authors, we began our December's work with Drupal Camps in Middle America. There have been some complaints about the choice of the term Middle America, but we stand by our decision, which we also explained in the blog post.… READ MORE

Another year, another Acquia Certification exam... (wait—I think I've said that before).

The latest of the updated Acquia Certification Exams is the Acquia Certified Drupal 8 Site Builder. It's meant for the average Drupal site builder to test and evaluate familiarity with building websites using Drupal 8, and it's the same as all the previous exams in style: a series of 40 questions posed in the conversational manner, with answers you would provide if you were telling a project manager or site owner how you would implement a feature.

Cron is used to perform periodic actions. For example you would like to:

• Send a weekly newsletter every Monday at 12:00 a.m.
• Create a database backup once per day.
• Publish or unpublish a scheduled node.
• Send reminder emails to users to activate their accounts.

... or some other task(s) that has to be automated and run at specific intervals.

Cron in Drupal

Cron configuration can be found at Administration > Configuration > System > Cron

What tasks does Drupal perform when cron is run?

This depends entirely on what modules you have enabled and use of course, but here are some pretty usual examples on what tasks are run in cron:

• Updating search indexes for your search engine when using Search core module.
• Publishing or unpublishing nodes when using the Scheduler module.
• If you have Update Manager module enabled, a task is run to look for updates. It also sends an email if you configured it to do so.
• If you have dblog (Database logging) enabled this task deletes messages after a set limit.
• Temporary uploaded files are deleted by the File module.
• Fetch aggregated content when using Aggregator module.

Running cron

First we have the Automated Cron core module (sometimes referred as Poor man's cron) which during a page request checks when cron was last run and if it has been to long it processes the cron tasks as part of that requests.

Cron is set to run every third hours.

There are two things to consider when using this approach. If no one visits your website the cron doesn't run. Secondly, if the website is complex or the cron tasks are heavy the memory can exceed and slow down the page request.

The second approach is to actually setup a cron job that runs at the intervals you specify. Configuring this up depends on what system you use, but typically isn't that hard to do. If you use a shared host it's most likely you can do that right off in your control panel, and if you have your own server you can use the crontab command.

Read the Configuring cron jobs using the cron command on drupal.org for more details.

Implementing Cron tasks in Drupal

Cron tasks are defined by implementing the hook_cron hook in your module, just like in previous Drupal versions.

/**
 * Implements hook_cron().
 */
function example_cron() {  
  // Do something here.
}

And that's pretty much it. Rebuild cache and next time cron runs your hook will be called and executed.

There are a couple of things we have to take in to consideration:

When did my Cron task run the last time?

One way to remember that is using State API which stores transient information, the documentation explains it as such:

It is specific to an individual environment. You will never want to deploy it between environments.
You can reset a system, losing all state. Its configuration remains.
So, use State API to store transient information, that is okay to lose after a reset. Think: CSRF tokens, tracking when something non-critical last happened …

With that in mind, we could do something like:

 $last_run = \Drupal::state()->get('example.last_run', 0);

  // If 60 minutes passed since last time.
  if ((REQUEST_TIME - $last_run) > 3600) {
    // Do something.

    // Update last run.
    \Drupal::state()->set('example.last_run', REQUEST_TIME);
  }

To ensure our task is only run once per hour. Again though, if our Cron is set to run in a periodic longer than one hour it won't run every hour. (Who could have guessed that?) If you use Automatic cron and have no activity during some hours, the cron won't be run then as well.

How time consuming is my task?

Operations like deleting rows from a table in the database with timestamp as condition is pretty light task and can be executed directly in the hook_cron implementation. Like so:

 // Example from the docs.
 $expires = \Drupal::state()->get('mymodule.last_check', 0);
  \Drupal::database()->delete('mymodule_table')
    ->condition('expires', $expires, '>=')
    ->execute();
  \Drupal::state()->set('mymodule.last_check', REQUEST_TIME);

But if you have to run tasks that takes time, generating PDF, updating a lot of nodes, import aggregated content and such you should instead use something called QueueWorkers which lets you split up the work that needs to be done in to a queue that can later be processed over the course of later cron runs and prevents that a single cron eventually fails due to a time out.

QueueWorkers and Queues

So, we have a long-running task we want to process. As mentioned earlier we shouldn't just put all the processing into the hook as it can lead to timeouts and failures. Instead we want to split up the work into a queue and process them. The queues will later be processed in a later cron.

So let's pretend we've created a site where user can subscribe to things and when they do, they get an email sent with an attached PDF, for the sake of the example we'll also send emails to the admins that someone subscribed. Both sending emails and generating PDF are long running tasks especially if we are doing them at the same time, so let's add those items to an queue and let a queue worker process it instead.

To add a queue, we first get the queue and then add the item to it:

// Get queue.
$queue = \Drupal::queue('example_queue');

// Add some fake data.
$uid = 1;
$subscriber_id = 2;
$item = (object) ['uid' => $uid, 'subscriber_id' => $subscriber_id];

// Create item to queue.
$queue->createItem($item);

So we get an queue object by a name, a name which is later used to identify which Queue Worker that should process it. And then we add an item to it by simply calling the createItem method.

Next we'll have to create a QueueWorker plugin. The QueueWorker is responsible for processing a given queue, a set of items.

Let's define a plugin with some pseudo long running task:

modules/custom/example_queue/src/Plugin/ExampleQueueWorker.php:

<?php  
/**
 * @file
 * Contains \Drupal\example_queue\Plugin\QueueWorker\ExampleQueueWorker.
 */

namespace Drupal\example_queue\Plugin\QueueWorker;

use Drupal\Core\Queue\QueueWorkerBase;

/**
 * Processes tasks for example module.
 *
 * @QueueWorker(
 *   id = "example_queue",
 *   title = @Translation("Example: Queue worker"),
 *   cron = {"time" = 90}
 * )
 */
class ExampleQueueWorker extends QueueWorkerBase {

  /**
   * {@inheritdoc}
   */
  public function processItem($item) {
    $uid = $item->uid;
    $subscrition_id = $item->subscription_id;

    $user = \Drupal\user\Entity\User::load($uid);

    // Get some email service.
    $email_service = \Drupal::service('example.email');

    // Generate PDF
    $subscriber_service = \Drupal::service('example.subscriber_pdf');
   $pdf_attachment = $subscriber_service->buildPdf($subscriber_id, $user);

    // Do some stuff and send a mail.
    $emailService->prepareEmail($pdf_attachment);
    $emailService->send();

    $emailService->notifyAdmins($subscriber_id, $user);
  }

}

So let's break it down.

We use the Annotation to tell Drupal it's a QueueWorker plugin we created.

/**
 * Processes tasks for example module.
 *
 * @QueueWorker(
 *   id = "example_queue",
 *   title = @Translation("Example: Queue worker"),
 *   cron = {"time" = 90}
 * )
 */

The id argument is the most important since it must match the machine name of the queue we defined earlier.

The cron argument is optional and basically tells Drupal that when the cron is run it should spend maximum this time to process the queue, for this example we used 90 seconds.

Then we implement the public function processItem($item) { method which will pass the data we gave for each item when we created the queue.

In the pseudo example I'm loading the user uid we passed in to the queue item and then getting 2 services which one generates a PDF (pretty heavy operation) and the second one that supposedly later emails it. We then send emails to all the admins through the notifyAdmins method. So that was pretty simple. We simply create a new plugin class, use the Annotation to tell Drupal its a plugin and then implement the method which gets the data from where we added the item to the queue.

For this example we just added some operation to be processed in a queue that doesn't necessarily belong in the cron hook but instead when the user actually subscribed for something. So what I'm essentially saying here is that you don't need to create a queue in a cron hook, but can do that anywhere in your code.
In practise its the same thing, you get the queue $queue = \Drupal::queue('example_queue') and then add item to the queue $queue->createItem($data) and then define ourselves a QueueWorker which then processes the queue items when cron is run.

So the question we should ask ourselves here: Should we add individual tasks to a queue and let cron process it? And the answer - it depends. If the task slows down the request and keeps the user waiting, it's definitely something to consider. These things may be a better case for using something like a Background job, but you may not always be able to do that (and nothing that comes out of the box in Drupal) and if so a cron will take of some significant time from the request so it's not too slow for the user (..or timeouts for that matter).

Here's all the code without the pseudo code that you can use as boilerplate:

<?php  
/**
 * @file
 * Contains \Drupal\example_queue\Plugin\QueueWorker\ExampleQueueWorker.
 */

namespace Drupal\example_queue\Plugin\QueueWorker;

use Drupal\Core\Queue\QueueWorkerBase;

/**
 * Processes tasks for example module.
 *
 * @QueueWorker(
 *   id = "example_queue",
 *   title = @Translation("Example: Queue worker"),
 *   cron = {"time" = 90}
 * )
 */
class ExampleQueueWorker extends QueueWorkerBase {

  /**
   * {@inheritdoc}
   */
  public function processItem($item) {
  }

}

For a real example, take a look at the Aggregator module which uses Cron and QueueWorkers.

Introduction

There are many choices out there for Web Content Management Systems (WCMS). Many commercial tools tout features and say that they compare favorably to Drupal, the leading open source solution for sophisticated WCMS. In this brief, I have researched to the best of my ability the features that make Drupal stand out from Adobe Experience Manager SEO.

I offer these caveats to my findings: 1) I have never personally used Adobe Experience Manager (AEM). That, in and of itself, is a drawback to the system. It is difficult to get a working demo of the platform. In Drupal, anyone can download and install it. 2) I have not talked to any Adobe representatives about these findings. Instead, I used Adobe’s public documentation to do my research. I also looked at third party how-to websites and a handful of published books. I have included links to publically available resources when available. 3) I am a Drupal SEO expert, not an Adobe Experience Manager expert so my viewpoint is skewed. However, I am a big fan of Adobe and have been since I started using Photoshop in 1993. I believe that these findings are fair, accurate, and truly reflect some of the advantages that Drupal brings to the table and the work still ahead for AEM.

Community Responsiveness

In Drupal, you get an open source community that has proved willing to do anything to make the product, site builder, marketer, and user experiences better. A very recent example of this is the release of Google AMP (https://www.ampproject.org/). Announced in late 2015, the Accelerated Mobile Pages (AMP) Project is “an open source initiative that embodies the vision that publishers can create mobile optimized content once and have it load instantly everywhere”. It’s a way to give a much faster content experience to mobile users. While still in its infancy, it’s a very promising technology that will benefit the entire web. Google has specifically stated that it will start giving preference (e.g. higher rankings and more traffic) to sites that use AMP. (http://www.wired.com/2016/02/google-will-now-favor-pages-use-fast-loading-tech/) The Drupal community released a beta AMP feature in late Feb, 2016. This allows almost any Drupal 7 or 8 site to serve AMP-powered pages. As of May 16, after extensive online searches, I can’t find any documentation of support in Adobe Experience Manager for Google AMP. (Note that Adobe Analytics is an active partner in AMP so tracking AMP pages does exist however there are no instructions or references on how to serve AMP in any documentation that I can currently find.)

Advanced Tools for Paths

In Adobe Experience Manager, vanity URLs do not support regex patterns. (https://docs.adobe.com/docs/en/aem/6-2/deploy/configuring/resource-mappi...) What this means is that you can’t do redirects like specify a pattern like "old-blog/*" and a target like "new-blog" and all pages under old-blog will be redirected to the page new-blog.

In Drupal, this functionality has been supported since September 2013 with the Match Redirect module (https://www.drupal.org/project/match_redirect). This greatly simplifies and reduces work, as anyone who has decided to change their site structure can attest.

Migration is Easier

Another path-related example that seems to have no corollary in Adobe Experience Manager is Pathologic. (https://www.drupal.org/project/pathologic) Pathologic is an “input filter” module. This means that it runs on your content and makes some adjustment or change to it before the server pushes it out to the visitor’s browser. In this case, Pathologic fixes broken links in situations when URLs have changed. For example, if you move to a new domain name or your site structure changes, say, you moved your Drupal installation from one directory to another. Well, normally, that breaks hundreds or thousands of links, images, and references. Pathologic cleanly fixes this problem easily. Another great example is that relative links or embedded images that use relative URLs don’t work in RSS feeds. Pathologic fixes that quickly and easily.

Automatic Fixes to Rewritten URLs

Yet another path-related issue is that Adobe Experience Manager doesn’t seem to offer any type of automatic fixes if a path is changed. In Drupal, this is handled by the Redirect module. So, for example, you write a Product page on your site called “Keywords and Me” which lives at www.myurl.com/keywords-and-me. But then, after a year, you realize that to SEO that page, you need to change it to “Key Phrases and Me” and change the URL to “www.myurl.com/key-phrases-and-me”. Drupal, when properly configured, would automatically create a 301 redirect from the old URL to the new URL. This would preserve much of the value of your incoming links, provide a better user experience, and update Google that the old content lives at a new address.

Duplicate Content

In fact, the whole vanity URL system in Adobe Experience Manager has a tendency to create duplicate content. That is, content that lives on two different URLs. (See the video: https://helpx.adobe.com/experience-manager/kb/vanity-urls.html). The video demonstrates how content lives at one URL but the vanity URL also shows the exact same content. This would require, at the minimum, a canonical tag to let Google know where the content actually lives. Either Adobe expects users of their system to already know this, it was overlooked, or it’s not possible.

Preventing Common Errors

The page (https://helpx.adobe.com/experience-manager/kb/vanity-urls.html) describes a situation where the Adobe Experience Manager admin accidentally defined two different pages to resolve on a single URL “dealoftheday”. There is a complicated set of steps and a separate “Sling Resource Resolver” tool required to identify the problem and address the issue. In Drupal, this simply cannot happen as a warning would occur that allows the content creator to fix this glaring problem when the content is created. In fact, these kinds of user-friendly warnings that prevent common errors are used throughout the Drupal admin interface to help prevent the inevitable cruft that builds up in long-standing web projects.

Simplicity for Marketers

Drupal has taken great strides in making it as easy as possible for you to SEO your website. There are many tools to accomplish just about anything you can imagine. And, most of them use the same admin interface embedded in Drupal that is familiar. There is extensive documentation as well as embedded help text.

After spending a few hours reading Adobe’s Experience Manager documentation, I’ve concluded that SEO on Adobe Experience Manager is a complex undertaking. Take a look at https://docs.adobe.com/docs/en/aem/6-2/manage/seo-and-url-management.html. An example sentence:

—

The SCR annotation for this type of servlet would look something like this:

@SlingServlet(resourceTypes = "myBrand/components/pages/myPageType", selectors = "myRenderer", extensions = "json”, methods=”GET”)

In this case, the resource that the URL addresses, an instance of the myPageType resource, is accessible in the servlet automatically. To access it, you call:

Resource myPage = req.getResource();

—

That's not exactly marketing-friendly.

Here’s another one:

—

The SlingResourceResolver can be found at /system/console/config on any AEM instance and it is recommended that you build out the mappings that are needed to shorten URLs as regular expressions and include these configurations under a config.publish OsgiConfig node that is included in your build. Rather than doing your mappings in /etc/map, they can be assigned directly to the resource.resolver.mapping property:

resource.resolver.mapping="[/content/my-brand/(.*)$&lt;/$1]"

—

This isn’t something that any marketer can or should have to understand. I understand that there are likely developers involved in a web project that understand this kind of tech-speak. However, the more I rely on a technician to fix my SEO issues, the less control I have and the longer (generally) that it takes to make the changes I need.

The Power of Taxonomy

Drupal has a system called Taxonomy that is an SEO’s dream. When a content creator tags content, Drupal automatically creates a page for that tag that is well optimized for search engines. That tag page is automatically added to the XML Sitemap so it shows up in Google quickly. And, when additional content is tagged with the same tag, the tag page is automatically updated. Of course tag pages can be even further optimized similarly to how node pages are optimized - with additional text and meta data. Adobe Experience Manager does support tagging but it seems to be limited to showing “tag clouds”. It does not support custom tag pages and the site admin must “Select the page to be referenced” by each tag - a time-consuming process that is not updated dynamically. (See https://docs.adobe.com/docs/en/aem/6-2/author/page-authoring/default-com... #Tag Cloud )

The Development Effort Required for Great SEO

Adobe Experience Manager requires significantly more effort in configuration than Drupal to achieve optimal SEO. This means that there is more to maintain, more things that could go wrong, and more reliance on the time and technical expertise of your development team. Examples that can be taken from https://docs.adobe.com/docs/en/aem/6-2/manage/seo-and-url-management.html include Canonical URLs, Case Sensitivity, and XML Sitemap. I’m sure there are others.

Conclusion

It’s clear that there are many distinct SEO advantages to using Drupal for your website. While this review is not conclusive, and it is almost certain that Adobe will continue to improve their product and make it a better tool and easier for marketers, as it stands today, Drupal is the clear winner. Even if Adobe does soon bring parity for SEO, the ongoing competitive advantage that Drupal has is the one addressed first: that of Community. The Drupal community is many, many times larger than the Adobe development team. That means that there is and always will be more resources going into making Drupal the best that it can be. Drupal is backed by Acquia, who provides a level of support on par with Adobe and many more advanced personalization tools that make Adobe Experience Manager so attractive. In my opinion, Drupal wins and will keep winning.

A comparison of major SEO functionality between the two platforms clearly shows Drupal winsdrupal seo, adobe experience manager, seo, Planet Drupal

DevOps is a much used term, but it seems like everyone you talk to has a different definition of it. Here's my own interpretation.

Tags: acquia drupal planet