Oct 09 2015
Oct 09

North America at NightWe are thrilled to announce that we have opened the RFP process and are accepting bids for the 2017 North American DrupalCon, and beyond.

DrupalCon is a pretty special event, it brings together thousands of people from across the globe who use, develop, design, and support the Drupal platform. It is easily the most widely attended Drupal event in the world.

If you are eager for your city to host a DrupalCon we recommend you send this link to your city's Convention Center or Tourism Bureau. We have begun outreach to cities that our DrupalCon team, and the community, has identified as a good fit. That said, we are always welcome to suggestions.

If you are a convention center or tourism bureau and have any questions, feel free to reach out to us.

We appreciate your interest in DrupalCon and can't wait to tell you where the next Con will be!

North America image by Eric Fischer on flickr.

Oct 09 2015
Oct 09

Now that Drupal 8 is in release candidate phase, the goal is to get out of release candidate phase and onto release as quickly as possible. That means we'll be locking down the patches committed to 8.0.x fairly significantly, so as not to potentially disrupt stability.

What patches can get committed now?

This is a complete list of the issues that are allowed in Drupal 8 before 8.0.0:

  • critical issues: Issues that are (legitimately ;)) marked critical are the first priority to resolve ASAP during release candidate. We can and will roll back any other types of patches if they introduce critical issues, or impact our ability to fix a critical issue. Note that we may choose to defer critical fixes to 8.0.x/8.1.x if the impact vs. disruption ratio risks postponing release.
  • rc eligible: This tag is for non-invasive patches which solely make coding standards, testing, and docs improvements. Anyone may add (or triage) this tag.
  • rc target: These are a handful of exceptions to the above; generally major issues with both a high impact and low disruption that would be much better/easier to get in before release than after. Only core committers should set this tag.

And... that's it! :) If you feel your non-critical, non-docs/coding standards/tests patch should be considered for an exception to be committed during RC use the rc target triage tag to alert core committers to it. They can then review and choose to switch to rc target or not. In order to aid committers in making that decision, a good issue summary containing rc target justification will really help. A good issue summary is of course also important on rc eligible issues.

Make sure to read Allowed changes during the Drupal 8 release cycle and in particular the section on release candidates for more detailed information.

How long does this "commit freeze" go on?

Until Drupal 8.0.0's release. That could be a minimum of 4 weeks (RCs are released every two weeks, and we'll need at least two of them [including a 3 week notice on release date] to tell if we're release-ready), or a maximum of $your_bet_here. ;)

Over at Release branches for core patch releases/release candidates we're discussing ways we can potentially commit RTBC patches during RC without disrupting our ability to ship (think feature branches 0.1). Thoughts over there would be welcome.

Oct 09 2015
Oct 09

My skin crawls when I see HTML filled with divs tucked inside each other over and over again like a Russian nesting doll. My shoulders tense up when I see class names spilling out of a class attribute like clowns in a circus car. Conversely, my heart sings at the sight of cleanly crafted HTML that uses just the right elements to describe its contents, with sensible BEM-style classes that simplify styling and clarify how the markup has been structured.

Because I prefer being very particular about markup, I’ve been known to develop an eye twitch from time to time while theming Drupal sites.

In 2013 I started contributing fairly regularly to the development of Drupal 8. Working at Lullabot since September 2014 has made it possible to devote even more of my time to working on Drupal 8 front-end improvements. There’s a great team of developers around the world focused on improving the theming experience in Drupal 8, and it’s been a joy collaborating with them. I’m very excited about how we’ve worked together to make Drupal 8 better for front-end developers and themers.

Thanks to those efforts, I’m looking forward to having much better tools for carefully crafting markup in Drupal 8.

Making markup shine in Drupal 8

The new templating engine in Drupal 8, Twig, makes it easier to change markup without knowing the ins and outs of PHP. Most of the classes in Drupal are now added in the Twig templates themselves, rather than being buried deep in preprocessor and theme functions. Better yet, by turning on Twig Debug in the services.yml file in your sites/default folder, you can see which templates are generating each bit of markup when you view source. You’ll find which template file is currently in use along with suggestions for filenames you can use in your theme to override that template.

The markup itself has been greatly improved as well. Contributors worked to improve template logic so that only necessary divs or other elements are generated: yes, there are fewer wrapper divs in Drupal 8! In previous versions of Drupal, field markup introduced wrapper after wrapper, often unnecessarily. Now if you have only one value and no label for a field...there’s only one div.

Two base themes in Drupal 8: Classy and Stable

In general, your theme has the final say on Drupal’s markup, CSS, and JS. Themes can override templates, CSS, and JS that come from core modules, contributed modules and base theme. Themes can have parent-child relationships, with the parent theme serving as the base theme for a sub-theme. A sub-theme inherits templates, CSS, and JS from its base theme. Themes can also have grandparent themes or even great-grandparent themes: we’ll talk about chaining together contrib themes with core themes in just a bit.

Drupal’s markup comes in two flavors, depending on what you choose as your base theme.

  • If you want to start with markup with sensible classes you can use as styling hooks, then you can use Classy as your base theme. This is similar to the approach used with Drupal 7’s default markup, but with classes and markup significantly improved.
  • However, if you want markup that is even more lean, you can use Stable as your base theme; in fact that’s the default. Stable still has some classes needed for front-end UI components like the toolbar and contextual links, but in general has far fewer classes than Classy, and even fewer wrapper elements.

By providing two flavors of markup with the Stable and Classy base themes, Drupal 8 allows you to choose how you want to approach markup changes:

  • Tweak the classes Drupal provides as a starting point (Classy),
  • Only add classes where you think they are essential (Stable).

If you prefer to start from scratch in order to use highly customized markup patterns, Stable may be the right base theme for you. This approach can be useful when implementing a framework like Bootstrap or Foundation that relies upon very particular markup patterns.

Field markup: Stable vs Classy

Let’s look at one example of how markup can differ between Stable and Classy.

Here’s Classy field markup when you have a label and multiple field values:

<div class="field field--name-field-favorite-horses field--type-string field--label-above">
  <div class="field__label">Favorite horses</div>
  <div class='field__items'>
    <div class="field__item">Black Stallion</div>
    <div class="field__item">Shadowfax</div>
    <div class="field__item">Hidalgo</div>

In contrast, here’s the same markup when using Stable:

  <div>Favorite horses</div>
    <div>Black Stallion</div>

Just for fun, look how much slimmer Classy’s markup is when only one value is allowed on a field, and the label is hidden:

<div class="field field--name-field-best-horse field--type-string field--label-hidden field__item">Mister Ed</div>

That markup gets even leaner with Stable:

<div>Mister Ed</div>

To see how far we've come, here's how that markup would look by default in Drupal 7:

<div class="field field-name-field-best-horse field-type-text field-label-hidden">
  <div class="field-items">
    <div class="field-item even">Mister Ed</div>

That’s a lot more markup than you really need when you know there will only ever be one value for a field.

From this example, you can see that Stable is a starting point. You would want to customize Stable’s markup in your theme to add sensible classes. Writing CSS using only HTML elements in your selectors is painful. However, with Stable you can build up only the classes you need, rather than spending time evaluating which classes in Classy should be retained.

Keeping Core markup reliable

One of the primary purposes of the Stable theme, which is new to core, is to provide a backwards compatibility layer for Drupal’s core markup, CSS, and JS. Those will all be locked within the Stable theme as of Drupal 8 RC1. You can rely upon Stable as your default base theme without worry that the markup will change on you during the Drupal 8 cycle.

The Classy theme will also provide reliable markup, CSS and JS, most likely by using Stable as its base theme.

So whether you choose Stable or Classy as your base theme, you can also rely on its markup whether you have Drupal 8.0.5 or Drupal 8.3.4 installed. Both Stable and Classy will still receive bug fixes—for example, if the wrong variable is being printed by a template. The goal is to make these fixes in a way that ensures backwards compatibility.

Drupal 8 also ships with two other themes, Bartik and Seven.

  • Bartik is the default theme when you install Drupal 8 and demonstrates one possible front-end implementation.
  • Seven serves as the default admin theme.

Both have been improved in Drupal 8 and use Classy as their base theme. Bartik and Seven can also continue to change throughout Drupal 8, so you wouldn’t want to use Bartik or Seven as a base theme. Bartik or Seven’s markup could be tweaked in 8.1 or 8.2, which could break your site’s appearance if you use Bartik or Seven as a base for your theme.

In the meantime, during the Drupal 8 cycle, core markup can continue to evolve. Contributors can continue to clean things up so that we don’t need to spend nearly as much time working on tidying our markup when work on Drupal 9 begins.

How to define the base theme in .info.yml

Many of a theme’s basic settings are defined in a file called MYTHEME.info.yml within your theme folder, where MYTHEME is replaced with the name of your theme. This is similar to the .info file in Drupal 8.

If you want to use Classy as your theme, add the following in your theme’s .info.yml file:

base theme: classy

If you want Stable as your base theme, you do not need to add a base theme setting to your theme’s .info.yml. If no base theme is declared, by default your base theme will be set to Stable.

If you don’t want a base theme at all, add this to your theme’s .info.yml file:

base theme: false

That would mean your theme would use Drupal 8’s core templates, CSS, and JS directly, rather than passing through Stable or Classy first. That’s a risky strategy. If something changes in core, you might need to update your theme accordingly.

Using Classy or Stable as your base theme is a more reliable way to ensure the stability of your theme.

Chaining base themes together

Contrib themes can also choose to use Classy or Stable as their base theme, or no base theme at all. That’s right, a base theme like Zen can have Stable or Classy as its base theme. A sub-theme of Zen would have Zen as its base theme, but would also inherit from Zen’s base theme, whether that’s Classy or Stable. So while you might end up using a contrib theme as a base for your theme, ultimately that contrib theme will likely trace back to one of the two base themes in core, Classy or Stable.

When you evaluate base themes like Zen or Omega or Adaptive Theme, make sure to check their info.yml file for the base theme setting. If you see base theme: false, you may want to be wary as core markup will surely change. If you see Classy or no base theme setting at all, you’ll have an idea what kind of markup (and stability) to expect from that contrib theme.

To pull together what we've learned so far, this graphic created by Morten DK shows how Drupal's core themes interact with contrib themes or themes you might develop:

Graphic showing how various Drupal 8 core themes relate to each otherHow Drupal 8 themes relate to each other

This is a good look at how things stand in October 2015, with Drupal 8 RC1 recently released. As more and more people try out Drupal 8 and build themes, we'll continue to develop a better understanding of how best to set up contrib and custom themes.

Learning more

You can learn more about theming in Drupal 8 by checking out John Hannah’s great articles on the subject, Drupal 8 Theming Fundamentals Part I and Part II

I’m definitely looking forward to working with markup in Drupal 8, more so than I ever have before. Hopefully you will too!

Oct 09 2015
Oct 09

Last week we did not have this meeting, because .... there were no critical issues to talk about. This time however, we did have one and we also took the opportunity to talk about what is going to happen to Drupal 8 now, what things would be allowed, and so on. Watch this recording for some practical information and questions answered as well as discussion of some specific issues we raised. (See all prior recordings).

[embedded content]

If you also have significant time to work on issues important for Drupal 8's release and we did not include you, let me know as soon as possible.

The meeting log is as follows (all times are CEST real time at the meeting):

[11:12am] jibran: https://www.drupal.org/node/2479487
[11:12am] Druplicon: https://www.drupal.org/node/2479487 => ImageStyles can be deleted while having dependant configuration. [#2479487] => 57 comments, 7 IRC mentions
[11:12am] Druplicon: jibran: 1 day 45 min ago tell jibran https://www.drupal.org/node/2582955
[11:23am] GaborHojtsy: issue levels is https://www.drupal.org/core/issue-priority
[11:23am] GaborHojtsy: jibran: ^^^
[11:25am] dawehner: alexpott: yeaah colors!
[11:28am] jibran: https://www.drupal.org/node/1823450
[11:28am] Druplicon: https://www.drupal.org/node/1823450 => [Meta] Convert core listings to Views [#1823450] => 73 comments, 2 IRC mentions
[11:34am] jibran: https://www.drupal.org/node/2520526
[11:34am] Druplicon: https://www.drupal.org/node/2520526 => Calculate configuration entity dependencies on install [#2520526] => 76 comments, 14 IRC mentions
[11:35am] jibran: https://www.drupal.org/node/2581459
[11:35am] Druplicon: https://www.drupal.org/node/2581459 => UpdatePostUpdateTest is extremely fragile to change and does not test batches in post updates [#2581459] => 6 comments, 2 IRC mentions
[11:44am] WimLeers: https://www.drupal.org/node/2542868
[11:44am] Druplicon: https://www.drupal.org/node/2542868 => Allow a header value size limit to be specified [#2542868] => 22 comments, 2 IRC mentions
[11:44am] WimLeers: https://www.drupal.org/node/2527126
[11:44am] Druplicon: https://www.drupal.org/node/2527126 => Only send cache context/tags if frontend proxy exists [#2527126] => 73 comments, 19 IRC mentions
[11:58am] dawehner: https://www.drupal.org/node/2576809
[11:58am] Druplicon: https://www.drupal.org/node/2576809 => Remove the usage of ChainRouter by default [#2576809] => 22 comments, 8 IRC mentions
[11:59am] jibran: i didn't know this at all
[12:04pm] dawehner: WimLeers: alexpott I didn't knew that! http://pastebin.com/FD2WgfiC
[12:04pm] WimLeers: dawehner: hHHAHAHAHHAHAHAAHA
[12:05pm] WimLeers: dawehner: you trolled yourself
[12:05pm] WimLeers: nice :D
[12:05pm] GaborHojtsy: https://www.drupal.org/project/issues/search/drupal?project_issue_follow...
[12:05pm] dawehner: WimLeers: well I think this was just the interface ... I was looking whether we could provide a more dense implementation of the chain router
[12:05pm] WimLeers: :)
[12:05pm] dawehner: WimLeers: as well, one reason is that it support multiple types of routers internally
[12:05pm] WimLeers: dawehner: you gotta admit it's funny though :D
[12:06pm] dawehner: WimLeers: oh yeah absolutely. You might have heard my "oh shit" earlier
[12:06pm] WimLeers: dawehner: right :P
[12:06pm] WimLeers: dawehner: now it makes sense
[12:06pm] dawehner: https://www.drupal.org/node/2469713
[12:06pm] Druplicon: https://www.drupal.org/node/2469713 => Step 2: Create a JavaScriptTestBase using PhantomJs Driver/Binary [#2469713] => 26 comments, 5 IRC mentions

Oct 09 2015
Oct 09



In the 6 years that the Penn State University Libraries has been using its current enterprise Content Management System, the number of author/publishers has grown to over 200, the number of pages has increased from 5,000 to over 10,000 and the number of media files now sits at several thousand. When the libraries made the decision to switch to a Drupal platform, the time was right for a shift: to fewer editors, to a surefire way to keep content fresh, and to a dead simple workflow that won’t get in the way.


The primary goal in redefining the workflow is to avoid content “ROT" (Redundant, Outdated and Trivial) on the site. Hundreds of authors, contributing content with no oversight, has naturally led to a bloated site with lots of unnecessary, duplicate, and obsolete content. We conducted a full content inventory prior to our move to Drupal, and after having analyzed 10,000 pages of content, page by page, we clearly understood the importance of managing and maintaining content control. It is critical that every piece of content on the site has an owner, is easily reusable across the site, meets all copyright guidelines, and is fully accessible to users with any disability or learning difference. Many areas of the site have content that changes regularly; therefore, minor edits to the site need to be taken care of without delay. And, if there’s a problem identified with the site, it needs to be easily reportable and quickly addressed.


So what's the key to making all of this happen? A simple, streamlined workflow that doesn’t get in the way or allow changes to get stuck in limbo. Our new workflow involves a small group of frequent users who are empowered to make regular content additions and changes, and a content board led by a content strategist that will review these changes after-the-fact, in batches.

Sure, Drupal has a slew of options (see, e.g., Workbench, Workflow, and Maestro modules) for managing editorial workflows. And these workflow solutions might work great in other environments - environments that are smaller or environments that are geared for publishing (like a newspaper or web magazine). But for a large (500+ FTE staff) organization with a number of autonomous authors, establishing a traditional publishing workflow could be a serious challenge. The addition of editorial layers is doomed to fail here because changes won’t ever be reviewed quickly enough (or at all), and “draft only” editors will end up with full publishing access, just to keep things moving, defeating the purpose of the workflow entirely. So, while content is incredibly important and must be vetted, having an after-the-fact review by a small and highly trained group of regular editors allows for speedy content updates and less ROT. Once we get in the swing of things, we anticipate that problems discovered during editorial review will become less and less frequent.

PhotoConvincing librarians that our libraries' web content is a valuable library resource and should be curated, reviewed and weeded like any other important library collection, was an easy sell. This understanding and acknowledgement encouraged buy-in from administration, enabling an overhaul of the old author model and workflow and paving the way for acceptance of the proposed editorial review and oversight.



The proposed workflow begins with a small cadre of editors who have permissions to create and change libraries web site content. These editors will be regularly trained in writing for the web, accessibility, and best practices. Each editor will create and edit content for their own department or library and will act as backup for other units when needed. Each node on the site will have a specific single editor listed as owner, and it will be social convention and that after-the-fact review that will keep our editors working within their own realms. Ultimately, anything that belongs to an owner is that owner’s responsibility to keep up-to-date. And while permissions-wise we won’t be adding restrictions, we will be providing editors with a view of the content they own. And finally, most importantly, although web editing and content creation may only be a part of an editor’s day-to-day responsibilities, these duties are written into their job description, recognizing the effort and importance of this valuable work.

Content Board

The content board is made up of a small group of highly-engaged editors who regularly review changes made to the Libraries’ web site. They ensure that content remains valuable and relevant by working closely with editors on all web content, making changes or corrections where necessary. Membership on the board is voluntary, with the exception of the content strategist, a user experience librarian, and an IT representative. An editor on the board cannot review her own content, and a module is under development to aid in the tracking and review of the content changes. The module will supply a simple table (provided by Views) of recently updated content that has not yet undergone review. The table has a “Review” link that will open the node referenced for that row; when the reviewer looks at the node in edit mode, he will see an extra field based on his role as Reviewer that allows him to “mark as reviewed.” When that is saved, the node disappears from the aforementioned View.

Content Strategist

The content strategist heads up the content board and is ultimately responsible for ensuring compelling and sustainable content through the content life cycle. Working with the content board and web site stakeholders, the strategist defines the structures of the libraries’ web site and associated sites within Drupal to meet best practices and ensure clear and concise engagement with and communication to users. The strategist will work with the content board and editors to develop content that reflects the libraries’ goals and user needs – content that is up-to-date, factual, consistent, and accessible to all. The content strategist, along with the content board, will review and edit content for accuracy, grammar, clarity, style and messaging and assist editors in creating attractive and user-friendly web pages.

The content strategist will meet regularly with the cross-departmental stakeholders to report on content strategies, progress and any other issues. Additionally, significant changes, including page creation, changes to the information architecture, or changes in navigation, will be approved or initiated by the content board, content strategist and stakeholders. Content issues will be brought to the attention of the content board and the content strategist for review and resolution.


The quality of the libraries’ web site content is critical to serving our users and connecting them with the resources they need. As is, creating and maintaining this valuable content without getting bogged down by approval paths and confusing permissions. We believe our simple, effective workflow, involving a dedicated group of editors, an engaged content board and content strategist and the understanding of the need for after-the-fact reviews, will allow us to meet our web site goals without getting in the way. Wish us luck!

Image: Pattee-Paterno Library-Tulips_5by Penn State is licensed under CC BY-NC 2.0

Oct 09 2015
Oct 09

UX Designer vs UI Designer — Infographics

Nowadays in our high-tech and inventive society, the terms UI (User Interface) Designer and UX (User Experience) Designer are being used more than ever. Rahul Varshney, a co-creator of Foster.fm clearly explains these terms: “User Experience (UX) and User Interface (UI) are some of the most confused and misused terms in our field. A UI without UX is like a painter slapping paint onto canvas without thought; while UX without UI is like the frame of a sculpture with no paper mache on it. A great product experience starts with UX followed by UI. Both are essential for the product’s success.” In order to create a stunning website you need a professional development team that will bring together both, UI and UX. Hence, let’s take a closer look at some of the differences and similarities that these notions have.

User Interface Design is a Tool

User Interface Design is quite a powerful tool for Web Design, since it allows a visual, tactile and innate connection with the user. A UI Designer is responsible for everything visitors will see on the web-site interface.

UI incorporates:

  • Visual Design
  • Color Balance
  • Interface Design
  • Typography
  • Iconography
  • Graphics

User Experience Design is About User Comfort

UX embraces everything UI has and much more. Being a UX Designer means to deeply understand your users’ needs and desires as well as to have a hand in analysis and research of the feedback, and test a design process. Overall, it encompasses all interactions between a customer and a company.

UX incorporates:

  • Field Research
  • User Interview
  • User Profile Creation
  • Data Gathering
  • Information Architecture
  • Diagraming
  • Wireframing
  • Prototyping
  • Process Maps
  • User Evaluation
  • Content Development
  • Coordination with UI Designers

So, why UX is so important? According to statistics, more than 70% of people who don’t like what they find on the site will go back and search for another one. Also, more than 60% of users give up, because they think you don’t care about them. That’s why interaction between a customer and a company is vital.

Of course, UI and UX have some common features, such as:

  • Visual Design
  • Interface Design
  • Typography
  • Iconography
  • Graphics

Now that you know the basic concepts of User Interface and User Experience Design, let’s proceed to the differences between UI and UX designers.

UI Designer vs UX Designer

Actually, these two types of designers might have a lot in common, though, in fact their responsibilities are quite different. A UX Designer has to be analytical, a bit theoretical and rational, while UI Designers are visual, inspired and somewhat artistic. What are their duties, then?

A UI Designer is concerned about the layout and color scheme (making alignments, choosing colors and fonts that complement each other), and visuals (determining whether design trends fit the interface and creating pictures that will improve a website’s usability).

A UX Designer cares about the system organization, which means system improvement for the user to feel comfortable searching needed information, and quite obviously, he should understand a user, conducting an interview and evaluation. The role of a UX Designer is extremely challenging and multi-faceted.

Being completely different, they complement each other, helping to improve a website’s usability.


To cap it all, UI and UX are extremely instrumental in finding solutions to issues in visual and interaction design, and should always come hand in hand. With the kind of design embracing both of them, UI and UX, you will hit exactly the right note. You will develop a product that is truly cutting edge, pushing ideas to life with UX and UI!

Oct 09 2015
Oct 09

When migrating a site from Drupal 6 to Drupal 8, we had to write some very basic Plugins. Since plugins and some of their related pieces are new to Drupal 8, here is a walk-through of how we put it together:

Use case

In Drupal 6, the contrib Date module provided a date field that had both a start and end date. So, the beginning of Crazy Dan’s Hot Air Balloon Weekend Extravaganza might be July 12, with an end date of July 14. However, the datetime module in Drupal 8 core does not allow for end dates. So, we had to use two distinct date fields on the new site: one for the start date, and one for the end date.

Fields in D6:
1.  field_date: has start and end date

Fields in D8:
1.  field_date_start: holds the start date
2.  field_date_end: holds the end date

Migration overview

A little background information before we move along: migrations use a series of sequential plugins to move your data: builder, source, process, and finally, destination.

Since we are moving data from one field into two, we had to write a custom migration process plugin. Process plugins are where you can manipulate the data that is being migrated.

Writing the process plugin (general structure)

The file system in Drupal 8 is organized very differently than in Drupal 7. Within your custom module, plugins will always go in [yourmoduledir]/src/Plugin. In this case, our migrate process plugin goes in [yourmodulename]/src/Plugin/migrate/process/CustomDate.php.

Here is the entire file, which we’ll break down below.

 * @file
 * Contains \Drupal\custom_migrate\Plugin\migrate\process\CustomDate.

Standard code comments.

namespace Drupal\custom_migrate\Plugin\migrate\process;
use Drupal\migrate\ProcessPluginBase;
use Drupal\migrate\MigrateExecutableInterface;
use Drupal\migrate\Row;

Instead of using functions like include(); or include_once(); to add various PHP files, now we “include” them by referencing their namespaces. Or rather Drupal knows which files to autoload based on the namespace.  This way, if a class is ever moved to a new directory, we won’t have to change code elsewhere, as long as the namespace stays the same. We will allow our code to be used the same way, by defining its namespace.

* This plugin converts Drupal 6 Date fields to Drupal 8.
* @MigrateProcessPlugin(
*   id = "custom_date"
* )

This class comment includes an annotation. When the Migrate module is looking for all available migration plugins, it scans the file system, looking for annotations like this. By including it, you let the migration module discover your migrate process plugin with the unique id ‘custom_date’.

Our new class will inherit from the ProcessPluginBase class, which is provided by the Migrate module in core. Let’s step back and look at that class. This is it’s definition:

abstract class ProcessPluginBase extends PluginBase implements MigrateProcessInterface { ... }

Since this is an abstract class, it can never be instantiated by itself. So, you never call new ProcessPluginBase(). Instead we create our own class that inherits it, by using the keyword extends:

class CustomDate extends ProcessPluginBase { ... }

The ProcessPluginBase class has two public methods, which will be available in child classes, unless the child class overrides the methods. In our case, we will override transform(), but leave multiple() alone, inheriting the default implementation of that one.

(A note about abstract classes: If there were any methods defined as abstract, our child class would be required to implement them. But we don’t have to worry about that in this case!) To override transform() and create our own logic, we just copy the method signature from the parent class:

public function transform($value, MigrateExecutableInterface $migrate_executable, Row $row, $destination_property)

Writing the process plugin (our specific data manipulation)

In order to write custom code, let’s review our use case of dates again. Since this is our mapping:

OLD D6 field_date (from component) -> NEW D8 field_date_from
OLD D6 field_date (to component) -> NEW D8 field_date_to

We will migrate field_date twice per node. The first time, we will pull the from date. The second time, we will pull the to date. Since our process plugin needs to be aware of which piece we’re looking for in that particular run, we will allow the process plugin to have additional configuration. In our case, we will call this configuration date_part, which can be either from or to, and defaults to from:

$date_part = isset($this->configuration['date_part']) ? $this->configuration['date_part'] : 'from';

Depending on which date part we’re looking for, we’ll grab the appropriate date from the D6 source field, which is stored in the array $value.

$value = ($date_part == 'from') ? $value['value'] : $value['value2'];

And we’ll return the string, which will populate the new field:

return $value;

That’s it for writing our process plugin! Now we just have to use it.

Using the process plugin

In our migration definition, we need to call this plugin and feed it the correct information. So back in [yourmodulename]/config/install/migrate.migration.d6_node.yml, we map the new and old fields:

  plugin: custom_date
  source: field_date
  date_part: from
  plugin: custom_date
  source: field_date
  date_part: to

Which reads like this: For field_date_start on the new site, pass the old field_date to the custom_date process plugin, with the configuration date_part = ‘from’. Do this all again for field_date_end, but with the configuration date_part = ‘to’. Both of our D8 fields get filled out, each getting its data from a single field on the old D6 site.


Time to fly! (Image courtesy of Wikimedia)


Hopefully this helps. If you have any corrections, improvements, questions, or links to how you use plugins, leave them in the comments!

Oct 09 2015
Oct 09

This is tutorial #4 in the Drupal Commerce tutorial series. In the previous article, we showed you how to add fields and metadata to a product. If you haven't read it, please go and read it now, or get the free eBook on Drupal Commerce 101 from the right sidebar (below the content if you are viewing in mobile).

In this article, we will go through the basic steps required to set up inventory management on your site. You will learn how to manage the quantity of products in your store. For example, buyers on your store will be advised to reduce the quantity of a certain product in his cart if you run out of stock.

Here is a screenshot of what we seek to achieve through this article:

Notice the warning on top telling the user that he can purchase only a maximum of 9 flashlights. Let’s get started to achieve this functionality.

Visit https://www.drupal.org/project/commerce_stock to install and unzip the Commerce Stock to your Modules folder.

In the back-end, search for and enable the following modules as shown in the screenshot below:

  • Commerce Simple Stock
  • Commerce Simple Stock Rules
  • Commerce Stock API
  • Commerce stock UI 

Click “Save configuration”:

Let’s explore the updates that have taken in place in the store after these modules were enabled. Click “Store”:

Click “Configuration”:

In the next page, click the newly created link “Stock management”:

In the new page, you will notice 4 tabs on the top-right:


Under "ENABLE STOCK MANAGEMENT FOR THESE PRODUCT TYPES", tick the box against "Product (product)". Click “Submit”. This step will activate the stock functionality for all the products in your inventory:

You will receive the following message. This indicates that all products in your inventory are now set to zero. Buyers won’t be able to purchase them unless you assign the quantity available for each product in the back-end:

To demonstrate this, I will go to a product in my inventory. Notice the “Out of stock” button below that prevents me from adding the product to the cart:

Let’s now assign a quantity in the back-end for this product, the 3-LED Flashlight. Click “Store” -> “Products”:

These are the 3 products in my inventory:

Click "Edit" on the right for 3-LED Flashlight. You will get the following screen. Specify a value for the "Stock" field. I am typing in “20”, which means buyers can purchase a maximum of 20 flashlights from my store:

Click “Save product” at the bottom of the page:

I am going to make a purchase of eleven 3-LED Flashlights from my store. Click “Checkout” and complete the purchase by filling in your shipping details:

You have now purchased 11 3-LED Flashlights out of a possible 20. Let’s now visit the back-end to confirm this.

Click “Store” -> “Product” and access the fields for 3-LED Flashlight. You will notice that the “Stock” field has been updated. I earlier typed in 20 as the quantity. It now displays 9 as the quantity after deducting 11 from your purchase:

Let’s now make one more purchase. As you can see here, I am trying to purchase 11 more of these flashlights when I know there are only 9 available. Click “Update cart”:

As seen in the screenshot below, my Drupal Commerce store prevents me from purchasing anything above a quantity of 9. 

We have now gone through the basic configuration required to set up inventory management for your store.

Next article: Adding a Shopping Cart

Oct 09 2015
Oct 09

The New Hotness

I read a post recently that had the click bait title "Is Drupal Dying?" Ironically I read this while attending ElixirConf. The basis of that post was clients asking for the next thing --expecting Drupal to be old and busted in five years.

I am at ElixirConf because I see great potential in Elixir, Erlang, and Phoenix. I expect it to be the next big thing and for it to help provide a scalable platform for highly available, highly scalable, and interactive / dynamic websites.

I consider myself a technologist. As such, I am always looking for the next thing. However, I would caution my clients against it.

Elixir is a functional language that compiles down to Erlang. Erlang was developed by Ericson to run their phone switches. It is a fault-tolerant language that is designed to handle connections. However, Erlang is a difficult language to work with. Here are some examples about how Elixir simplifies Erlang.

Phoenix is a Rails-like MVC framework that is written in Elixir. Phoenix makes good use of Elixir's tools (such as mix, plug, and ecto) and other Elixir components to create a highly scalable, fault-tolerant, and highly available web-application framework. This is still a very bare-bones and brand new framework. Phoenix 1.0.0 was just released. While I am very impressed, there are still some pieces that are missing. Some of these piece are missing in Rails and other MVC based frameworks as well. This is one reason I seldom use (or recommend) a MVC for back-end development.

Phoenix feature overview?

The thing to remember is that phoenix is a bare metal type of framework. All it gives the developer out-of-the-box are: Endpoints, Routes, Plugs, Models, Views, and Controllers.

  • Endpoints
    • Where the client can connect; web-sockets and http.
  • Routes
    • Paths to content, these can be dynamic.
  • Plugs
    • Modules of additional functionality. The connections is pushed through the Plugs and the Plugs affect the connection.
  • Models
    • Definition (schema) of data.
  • Views
    • How the data is displayed
  • Controllers
    • How the data can be manipulated.

The nice thing about Phoenix is that it uses many pieces of tech form Elixir but it is also built to play well with other technologies.

I am testing with apache benchmark. Running 1000 requests with 100 concurrent users. I am not going to do a test of Drupal, I will only be comparing Phoenix to a site that was statically generated beforehand and delivered with NGINX. Test where done with apache benchmark.

I am not testing Drupal, because it wouldn't be a fair comparison. Drupal does much more than Phoenix on each request. Really this is a far more apples–apples comparison.

Static Site served with nginx

This is a site that I have in production. It was Drupal, I retired the site and archived it to static html. The web-server is running nginx and it only serves static sites. Neither Phoenix or NGINX are being used in a completely optimized way. Remember, these are not-scientific-at-all™ benchmarks.

01:18 $ ab -n 1000 -c 100 http://www.lnltowing.com/
This is ApacheBench, Version 2.3 <$Revision: 1663405 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.lnltowing.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software:        nginx
Server Hostname:        www.lnltowing.com
Server Port:            80

Document Path:          /
Document Length:        3142 bytes

Concurrency Level:      100
Time taken for tests:   5.490 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      3392000 bytes
HTML transferred:       3142000 bytes
Requests per second:    182.15 [#/sec] (mean)
Time per request:       549.001 [ms] (mean)
Time per request:       5.490 [ms] (mean, across all concurrent requests)
Transfer rate:          603.37 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      100  237  58.8    244     665
Processing:    70  251  80.5    232     777
Waiting:       70  249  79.3    231     666
Total:        170  488 113.0    476    1089

Percentage of the requests served within a certain time (ms)
  50%    476
  66%    487
  75%    497
  80%    510
  90%    581
  95%    758
  98%    875
  99%    936
 100%   1089 (longest request)

Dynamic site served with Phoenix

This is Phoenix running on my local machine in dev mode with live code reloading. I added a couple custom models and controllers, but otherwise it is basically vanilla Phoenix in development mode.

01:16 $ ab -n 1000 -c 100
This is ApacheBench, Version 2.3 <$Revision: 1663405 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software:
Server Hostname:
Server Port:            4000

Document Path:          /admin/content
Document Length:        41373 bytes

Concurrency Level:      100
Time taken for tests:   7.488 seconds
Complete requests:      1000
Failed requests:        0
Non-2xx responses:      1000
Total transferred:      41567000 bytes
HTML transferred:       41373000 bytes
Requests per second:    133.54 [#/sec] (mean)
Time per request:       748.844 [ms] (mean)
Time per request:       7.488 [ms] (mean, across all concurrent requests)
Transfer rate:          5420.73 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.7      0       4
Processing:    30  726 128.0    710    1168
Waiting:       30  726 128.0    709    1168
Total:         33  727 127.9    711    1168
WARNING: The median and mean for the initial connection time are not within a normal deviation
        These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
  50%    711
  66%    752
  75%    809
  80%    828
  90%    892
  95%    953
  98%   1022
  99%   1073
 100%   1168 (longest request)

All this test does is make me think Phoenix might be onto something. This isn't decisive, however, Phoenix was delivering dynamic pages to the browser nearly as fast as nginx was delivering static files.

This definitely warrants further testing. My next test might be with some more complicated models and user access controls. However, my interest with Phoenix has more to do with the web-socket handling. These where the preliminary tests to see if Phoenix is even worth my limited time.

It is.

My opinion is that Drupal's biggest strength (and the root of it's staying power) comes from our (as in the Drupal Community) acceptance that things change. Drupal 7 was a huge step forward from Drupal 6. Old apis where gone or changed in ways that where incompatible with Drupal 6. Remember that when Drupal 7 was released, no one was even developing on Drupal 6 anymore --everyone was using Pressflow.

Drupal 8, from all I can see, gives us more tools out of the box than any other site building platform. This is a good time.

For the longest time I thought Drupal's biggest problem was PHP --and I mostly still think that. The difference between now and 5 years ago is that PHP's development is starting to gain velocity. We are starting to see some of the improvements from HHVM and PHPng being brought into PHP. PHP7 holds some real potential. PHP has always been really fast and it is still really fast. Big pipe is the new thing for PHP and it can work, things are possible. All of this gives me hope. It gives me hope for Drupal.

Oct 09 2015
Oct 09


Since its earliest releases (2011) Leaflet JS has been a huge hit in map land. For many happy mappers across the world it is the preferred light-weight mobile-friendly API. No matter what map tiles you want to bring to life, Esri, Mapbox, OSM, even Google, Leaflet makes them shine.

Although it’s been around for years, Leaflet is yet to make its official debut: version 1.0.0 is to be released soon.

Version 1.0.0-beta is out now.

Thousands will ask: what does Leaflet JS 1.0.0 have to offer over 0.7.5? And: can I use 1.0.0-beta in Drupal today?

To start with the improvements, most of the new offering is under the hood. Better performance, bug fixes, improvements in UX, animation, projections. Check the Changelog for details -- there are many.

Visually, a striking new feature is the flyTo() function, which you can see in action by pressing the 3-letter airport codes above. [Note: for now this works best on non-mobile devices]. For a full screen version with more destinations and different map styles, head over to our friends at RegionBound, who have a similar demo.

With Leaflet JS 1.0.0 come some API improvements.

And herein lies the rub. Some of the API changes may break some of the hundreds of free Leaflet JS add-ons strewn across the Internet and on drupal.org. Including the base Leaflet module. Yesterday we checked in a patch to deal with multi-polygons, multi-linestrings and circles. With that and some other changes the Leaflet-the-D7-module is now in pretty good shape. So are some of our other favourites: Leaflet More Maps, Leaflet Hash, Leaflet Label, IP Geolocation Views & Maps.... These were already ok, or required minor fixes.

To cut to the chase... in D7, can you upgrade to Leaflet JS1.0.0-beta now ?


In three easy steps:

  1. You need to use Leaflet-the-Drupal module version 7.x-1.3 (or latest 7.x-1.x-dev), which has the patches described above. It will continue to work with Leaflet JS 0.7.5 too, if you need to fall back.
  2. Then Replace your current Leaflet JS in sites/all/libraries/leaflet with the latest Leaflet JS 1.0 downloaded from here.
  3. Check which of the Leaflet add-ons you are currently using. Some will work fine unchanged, some may require patches or simply updated versions of their associated libraries, most notably Leaflet Markercluster -- see its project page.

Should you find an issue after switching to Leaflet JS 1.0.0, please let the drupal.org community know via the respective Leaflet extension modules issue queues,

What about D8 ?
There is no Leaflet D8 version yet. Some have suggested re-architecting the Leaflet module. If these plans go ahead, it would make sense to target compatibility with Leaflet JS 1.0.0.

Whether it’s D7 or D8, let’s all chip in to make sure that Leaflet continues to fly in Drupal!

* * *

Oct 09 2015
Oct 09

Here at Lucius HQ we are always interesting in cool new stuff. So to discover the decoupled world, we built our new corporate website with Node.js and headless Drupal 8. In this blog serie we explain the implementation.

This is the third and last part of the 'Headless Drupal & Node.js' serie. Previously:

In this last part I'll show you:

  1. Installation and intro Express JS in Node.js
  2. Routes and dynamic templates with EJS in Express JS.
  3. Connect the JSON data from the RESTful Drupal 8 web service

1) Installation and intro Express JS in Node.js

As described in in part 2, Node.js on it's own is a minimalistic webserver and not primary developed for websites. If you want to implement websites in Node.js, then Express JS will give you the needed kick-start. It's a 'Fast, unopinionated, minimalist web framework for Node.js'.

It contains robust features to build web -and mobile applications, you can also implement is for building API's. Express JS provides Node.js with the needed structure that's not present if you use Node.js on it's own. Express JS facilitates in:


Express JS contains two templating engines: the default is Jade, the second is EJS. Jade is ‘whitespace based’ and is used as follows:

EJS is more 'full HTML' based, we choose to work with that.


Express JS also provides a routing system so you can manipulate the content of your website based on URL as needed for dynamic, cms driven websites.


Express JS is MVC based: Model View Controler, a modern way to build web application. This facilitates a modular based implementation of your web application so your application is more structured, better to maintain and extend.

  • Model: the data that your web application is going to use.
  • View: this is where the data will be poured into - the template in EJS.
  • Controller: the Javascript that pours the data in the dynamic templates.

Installation Express JS

In part 2 I described the install of modules with NPM. You can install NPM modules in two ways on your server:

  1. As a global application
  2. Per project based

It depends on your project how to install, for this project I install it both ways: global and in the project.

Global installation Express JS

The global version is needed, because that also installs needed Command Line Interface Tools (CLI’s). In your terminal enter:

npm install -g express

If you get an error, then try as super user:

sudo npm install -g express

Now when you enter express --version you should get a response like:

Installation Express JS in your project

Now enter npm install express --save

Express JS will be added to your project as a dependency, you can also see that in the package.json file (see also part 2).

Express JS is now installed, we can start with a 'Hello Express'.

‘Hello Express’

We implemented hellotest.js as the main app file in part 2. I open that file and add following code:

var express = require('express');

==> Create the variable 'express' and define the library 'express' you want to use.

var app = express();

==> Create the variable 'app' for this application that we'll build with Express JS. By namespacing this application we can now use the methods that Express JS provides in the global variable 'app'.

app.get ('/', function(req, res){
    res.send('Hello Express');

==> This simple example provides a route for a homepage request. It answers with a short text.

As you can read in part 2: in Node.js you needed to define the mime-type yourself. But because Express JS knows you're working with a web protocol that's not needed anymore.

var server = app.listen (2000, function(){
    console.log('Waiting for you on port 2000');

==> Create the server on port 2000.

To test this in a browser I first need to start the app: enter node hellotest.js in a terminal:

Now when I browse to http://localhost:2000 I see

As you can see, this is similar to the example in Node.js as described in part 2, but we use Express JS methods that make thing easier for us. For a complete overview of all methods, properties and events, see Express JS API.

Routes in Express JS

Routes take care of dynamic, url-based websites. Express JS excels in facilitating the needed routes, it's like Drupal's hook_menu(). I add two routes as follows:

When I go to my browser /about-us:

Routes with variables

It's also possible to parse information via routes to the application. The information can be placed in the parameters variable within the request object. The variables will be mapped to - and will be available in - the request parameters array:

var name = req.params.name;

==> Places everything after /about/ in a variable 'name'. This is done via the request parameters array req.params of Express JS: it places an object 'name' in the array and sends that to a local variable 'name'.

Then I'll print 'name' within h1 tags, wich generates simple dynamic output based on URL.

You can add multiple variables:

This wil result in:

The 404 for example:

2) Routes and dynamische templates with EJS in Express JS

Till now we used res.send, but there is a better way to do this: via dynamic templates. As described above, Express JS uses Jade as default templating engine. We use EJS:

Within EJS you can use full HTML and provide dynamic content via tags.

Installation EJS

Enter in your terminal: npm install ejs --save

You should now see the dependency in the package.json:

Now EJS is installed, you can activate it in the application:

app.set('view engine','ejs');

Now we create a new folder 'views', where we place a default HTML document 'default.ejs':

And we can call this template with res.render(). Applied to the homepage:

Express JS knows that he has to look in the folder 'views' for template files, that's a default. You can define your own custom folder:

app.set(‘views’, __dirname + ‘/YOURFOLDER’);

__dirname is a global, so you can use this anywhere.

Send data (content) to the template

You can add an extra object with data to your template:

In the template, you can print this:

In browser:

You can also use Javascript in the EJS templates like this instead of .

Good to know:

  • 'templates' are the same as 'views'.
  • 'data' is also called 'the modal'.
  • if you put together the 'modal' with 'views' you'll get dynamic websites.

Structure routes an templates in Express JS

When you define routes than it's a best practice to place them outside of the 'main app' file. This way you keep your stuff more organized:

  • Create a new folder 'routes'.
  • Create a new file in there 'index.js'.
  • Import the express module and define the 'router' variable.
  • Move the routing code to the new file:

Now change the main-app file, 'hellotest.js' in this example:

  • Define the 'routes' variable
  • Add app.use  (‘/’, routes):

Alrighty, now your routes and views are split up in different folders, so your application is better organized.

Last thing to do is integrated the content data from the Drupal 8 RSSTful API.

3) Drupal RESTful API data integration in Node.js

We now have implemented the fundamentals in Node.js with help of Express JS. Also, we have the Drupal data available in JSON, see part 1. Now it's time for the magic: integrate these two.

Installation NPM 'Request' module

To import the external JSON data we first need an extra NPM module Request. This is a populair module, that makes it easy to make http calls and exchange data. So to install it, enter in your terminal npm install request (prepend ‘sudo’ when you get an error):

Now the module is installed, we have to import it in our project:

var request = require(“request”);

Importing the JSON data from the Drupal web service

Now the Request module is installed, we can use it's functions. I use this script to read the blog data:

  • Line 5: I create the variable that will contain the URL of the Drupal JSON export.
  • Line 13-32: read the JSON object and add the correct fields in an array. That array is placed in a global variable app.locals.blogsdata.

app.locals.XYZ is used in Node.js for global variables, these will be available in all templates. To make this easy for myself I place the blog data in a global var for now. Because we also need it on all pages in the footer.

So now all blog content data from the Drupal API is available in the global var app.locals.blogsdata.

Integration the Drupal data in a dynamic EJS template

As an example we use our blog overview page, that shows the 5 most recent (Dutch) Drupal blogs. We can build this page as follows:

Create the base HTML page and include the content part with an extra file:

Create a new folder 'content' within the 'views' folder and create a file 'blog-overview-articles.ejs'. In this file we print the Drupal blog data with help of some server-side Javascript:

To fresh up your memory, this is the JSON object we are working with from part 1

Now we've built the blog overview page in Node.js combined with content data from the Drupal 8 API. You can see the result here (Dutch Drupal blog).

Integrating the Drupal API data on blog detail page

The URL format is as follows: '/blog/blog-item-title/'. The content of the page depends on this variable URL, especially the part after '/blog/'. Earlier in this post you saw how to handle variables via URL. So we now can route the data as follows:

We check the current URL and see if there is a match on a URL in the JSON object. When that is found, the associated data is placed in an array that will be send to the template.

Wrap up

Ok, that's it for the serie 'Headless Drupal & Node.js'. Off course this is just an quick intro of Drupal Web services, Node.js and Express JS.

We only touched the 'GET' of the Drupal RESTful API. Stuf like POST, PUT, DELETE, OPTIONS are also possible in Drupal 8. But we didn't need them in this example.

Also we only touched the surface of Node.js and Express JS, but hopefully enough to build some cool high performance dynamic websites.

We are planning to write more in-depth blogs about this stuff, so stay tuned!

-- Cheers, Joris

Oct 09 2015
Oct 09

Here at Roomify our long-term goal is to provide tools that can support the widest possible range of booking problems. There is an increasing demand for such solutions both from "traditional" companies (especially within travel) that want to leverage new online tools, as well as from the new breed of "sharing economy" startups. We view our role as technology providers to all of them. We build platforms that allow you to create your own special coctail of Content + Reservation/Booking + Commerce + Community and target your particular niche. 

Our Agency solution does this for whoever is interested in building their niche AirBnB-style site and today we are very excited to introduce Tours! Tours enables people to create platforms through which to describe and offer tours that can either last a few hours or a few days. Here are a few of the key highlights. 

Roomify Tours Front End Functionality


Our Tours solution allows users to use faceted search to find available tours and apply filters to find just the type of search they need.

Tour Search


Pick A Tour

The front-end widget lets you pick a “tour slot” available and figures out pricing based on the type of tour and number of people participating. It can handle both private tours (with pricing depending on group size or fixed) and open tours (pricing is per person and anyone can book into them with Roomify managing availability). 

A user can then either do an instant booking or send an enquity.

Front End Tour Widget

We can also handle multi-day tours and display availability in a table format as shown in the example below:

Multi-Day Tour


For instant booking the product is created and dropped in a Drupal Commerce cart which provides full access to all the great features of Drupal Commerce from coupons to taxation and a very flexible checkout process. 

Tours Checkout

Roomify Tours Administration

Tours themselves are administered in a way that is familiar to anyone that has used our open-source Rooms module.

Creating a Tour

A tour has a name, price and capacity and since we are within the Drupal CMS we can also associate any number of other fields that may be required. Finally, tours get time slots (either open or private).

Tours Administration

Managing Tour Availability

Tours are separated between open tours and private tours and each tour can have its availability managed. We built in the nifty recurring rules widgets to allow administrators to create multiple tour slots in a single go. 

Availability Management


Managing Tour Bookings

Tour bookings can also be added by administrators using a similar widget to what is available on the front-end and it all integrates nicely with Commerce and Orders.

Order Management for Tours

So there you have it - Tours with Roomify solutions integrated in Drupal and Drupal Commerce. Our first sites are launching soon and if you would like to find out more just get in touch

Ronald Ashri

Ronald is a founder at Roomify and the creator of the Drupal Rooms module.

Oct 09 2015
Oct 09

First release candidate for Drupal 8 is out. Here is how to install it with Mamp.

1. Download the core
2. Create database
3. Go through the installation

1) Download the core

- Download the recommended release for Drupal 8 from here:


- Extract that packet under your document root and rename it to something like mysite.

My document root in MAMP is in /Users/samuli/Sites and the actual site goes here:

So now you have this kind of file structure:

2) Create database

Note: If you don't create the database manually, the installer will attempt to create the database for you. In this example we create it manually.

- Go to the phpMyadmin page.

For me it's found here: http://localhost/phpmyadmin. You can click the Open WebStart page link in MAMP control panel to go to the default start page and find your phpMyadmin link there.

- Click Databases tab:

- Write database name, select utf8_general_ci for the collation and click Create:

3) Go through the installation

- Visit the site url to start the installation.

For me the url is here: http://localhost/tutorials/d8/mysite/

- Choose language:

- Select installation profile:

You can create your own profiles to modify the installation process (like have some modules to be enabled / disabled by default).  Bare installation profiles are stored in the profiles directory before you start the installation. Bigger modifications that include core and all other necessary files are called distributions (like Commerce Kickstart or Open Atrium).

- Depending on your system/setup, you might or might not see some notices/errors in the Requirements review:

Drupal 8 requires PHP 5.5.9 or higher

PHP versions higher than 5.6.5 or 5.5.21 provide built-in SQL injection protection for MySQL, so it might be a good idea to implement that in your production envinronment.

It is also recommended to install OPcache to improve PHP performance. There is an OPcache setting in MAMP but it didn't seem to effect the notice here. Problem might be my outdated MAMP setup (I don't use it for development anymore) or the fact that this was a Drupal 8 release candidate (RC1).

Check out other Drupal 8 system requirements here: https://www.drupal.org/requirements

- Type in the database name and credentials (for MAMP the default username/password is root). If you didn't create the database before, the installer will try to create it at this point.

- Configure site:

'Check for updates automatically' will enable the Update Manager module that checks updates and enables you to install/update modules with web interface. You might want to disable the email notifications (you don't want to get update emails from all your sites), and instead subscribe to the security announcements here: https://www.drupal.org/security.

Congratulations, you just installed Drupal 8!

Oct 09 2015
Oct 09

I've been a part of the Swedish podcast Drupalsnack for over 2 years now, and it's always fun to do a podcast while at a DrupalCon. This year, we managed to record the podcast in one of the BoF rooms, but some interference with the recording led up to a re-recording a couple of days later. 

This year, we did three interviews: Kristoffer's colleague Kevin who was a first-time-attendee at a Drupal event ever, Antje from the Drupal Documentation Group and Holly Ross. Furthermore we talked about the conference itself, highlighted some of the sessions we attended and also covered the upcoming release of Drupal 8 RC1 (that was released two days ago). 

You can click here to download the mp3-file or visit the official site of the Drupalsnack podcast to listen in your browser. We apologize for grammatical errors and that we sometimes sound like The Swedish Chef (hurdy-burdy-gloop).

Oct 09 2015
Oct 09

If you are running Drupal 7 on Nginx, the good news is that your existing Nginx configuration is almost fully compatible with hosting Drupal 8. Except one thing: Drupal 8 Update module has been re-implemented, and your existing Nginx configuration will probably return 404. For more details on Drupal 8 Update module change, please see Move update.php back to a front controller.

The change matters to Nginx config is that Drupal 7 update.php URL is like

/update.php?op=info or /update.php?op=selection

while Drupal 8 update.php URL pattern is like

/update.php/selection or /update.php/result

So, what we need to change in the existing configuration is very simple. Look for your matching condition like

location ~ \.php$ {...}

then, change it to

location ~ \.php$|^/update.php {...}

This change is adding a new case to tell Nginx, if you run into update.php on the root level, just pass it to your downstream.

I have updated my Nginx template for running Drupal 7 and Drupal 8, you can see it https://gist.github.com/skyred/4248423 to look at the full picture.

Oct 09 2015
Oct 09

Drupal 8.0 RC1 has just been released! I've been looking forward to improved performance since Wim Leers wrote about Drupal 8's new caching system six months ago.

Benchmark tool

I performed a quick benchmark using siege, which was run on a separate computer and connected to the server via a HP 1810-24G gigabit switch.

Server setup

  • HP DL160
  • 2x Intel Xeon L5520
  • 18GB RAM
  • 2x Gbe network ports
  • FreeBSD 10.2 RELEASE
  • ZFS filesystem over iSCSI

Testing methodology

  • Fresh install of Drupal 6, 7, and 8
  • Create one article node to appear on the front page
  • Caching was enabled on all sites
  • Used nginx v1.8.0 and php-fpm
  • Run 100 concurrent connections for 30 seconds


Transaction rate (requests/second) - higher is better

Response time (seconds) - lower is better

Raw data

Drupal 8 - caching enabled
siege -b -c 100 -r 1000 -t 30S http://drupal.8.dev3

Transactions:                  10615 hits
Availability:                 100.00 %
Elapsed time:                  29.49 secs
Data transferred:             118.18 MB
Response time:                  0.28 secs
Transaction rate:             359.93 trans/sec
Throughput:                     4.01 MB/sec
Concurrency:                   99.47
Successful transactions:       10615
Failed transactions:               0
Longest transaction:            0.43
Shortest transaction:           0.02

Drupal 7 - caching enabled
siege -b -c 100 -r 1000 -t 30S http://drupal.7.dev3

Transactions:                  29577 hits
Availability:                 100.00 %
Elapsed time:                  29.48 secs
Data transferred:             235.08 MB
Response time:                  0.10 secs
Transaction rate:            1003.14 trans/sec
Throughput:                     7.97 MB/sec
Concurrency:                   99.79
Successful transactions:       29577
Failed transactions:               0
Longest transaction:            0.21
Shortest transaction:           0.05

Drupal 6 - caching enabled
siege -b -c 100 -r 1000 -t 30S http://drupal.6.dev3

Transactions:                  31246 hits
Availability:                 100.00 %
Elapsed time:                  30.02 secs
Data transferred:             126.20 MB
Response time:                  0.10 secs
Transaction rate:            1040.72 trans/sec
Throughput:                     4.20 MB/sec
Concurrency:                   99.77
Successful transactions:       31246
Failed transactions:               0
Longest transaction:            0.75
Shortest transaction:           0.01


Drupal 8 is about 3 times slower than Drupal 7 and Drupal 6.

I believe this might not be due to Drupal itself, but the Symphony PHP framework that it uses. Symphony has been shown to be one of the slowest PHP frameworks available. Symphony is 14 times slower than Phalcon.

Oct 09 2015
Oct 09

Rare is the site where the user who logs into the site, and needs to end up on their User page.  This is the default behavior of Drupal.  It makes sense if you are making a community or social media type website.  But for most of us, building publishing, marketing, and general business sites, we want to send our users to a specific place so they can start or continue their workflow.

The Drupal Login Destination module comes to our rescue.  With this module, we can redirect a user after logging in, after registering to the site, after using a one-time login link, or after logging out.  We can set rules based on the user's Role, and can direct users to internal or external links, keeping any variables needed.  It is a very powerful tool that you can use to help administrators on their way into their work, or help users into a conversion funnel of your design.

Installing Login Destination

Installation is simple, download to your modules folder and enable to the modules screen, or do so using drush:

drush dl -y login_destination
drush en -y login_destination

  • After installation, visit:
    • /admin/config/people/login-destination or
    • Admin Menu > Configuration > People > Login destinations
  • Click the "Add login destination rule" button and a new screen will present itself.
  • Redirect to page: Enter the Internal page or external URL
  • Redirect upon triggers: Set the trigger that this redirect will happen upon.  Your options are:
    • Login, registration, one-time login link
    • Logout
    • All
  • Redirect from specific pages: You can set this rule to be used on specific pages.  Examples include the login page, a 404 or a 403, or even a specific landing page!  You can set to be:
    • All pages except those listed
    • Only the listed pages
  • Redirect users with roles: Set the rule based on the role of the user.
  • Weight:  In case there are rules that are similar, you can add a weight to order them.

Login Destination is a great, simple helper module that gives Site Builders a method to direct users to destinations based on simple actions.  Below you will find some common recipes that I have used.

Common Login Destination Recipes

Redirect to Home Page after Logout

  • Redirect to page: <front>
  • Redirect upon triggers: Logout
  • Redirect from specific pages: All pages except those listed - [none]
  • Redirect users with roles: All Roles Selected

Redirect Content Editors to admin/content

  • Redirect to page: admin/content
  • Redirect upon triggers: Unchecked, lists all
  • Redirect from specific pages: All pages except those listed - user/logout
  • Redirect users with roles: Administrator, Webmaster, Content Editor

Redirect to Twitter/Facebook after Logout for Subscribers

  • Redirect to page: http://www.twitter.com/thejimbirch
  • Redirect upon triggers: Logout
  • Redirect from specific pages: All pages except those listed - [none]
  • Redirect users with roles: Subscribers

Redirect to Page after Landing Page Login

  • Redirect to page: /landing-page-success
  • Redirect upon triggers: Login, registration, one-time login link
  • Redirect from specific pages: /landing-page-url *
  • Redirect users with roles: All Roles Selected

*Add a register or login block to a specific URL using Panels, Context or your preferred method of content placement.

Oct 09 2015
Oct 09
*/ Fly
to: LHR JFK SFO GIG CAI CPT DME PVG MEL File under:: Planet Drupal
Oct 08 2015
Oct 08
Tags: community, Drupal, PHP

In case you hadn't heard yet, Drupal 8 RC 1 is out. And there has been much rejoicing! I'm going to save my own lengthy celebration-and-thank-you post for the 8.0.0 release, so for now I will just point everyone at Campbell Vertesi's post and say "what he said!".

But it's also a good time to consider the impact that Drupal 8 has had on the PHP community. The "off the island" movement has grown large, and people outside of Drupal are echoing the same message. In fact, not one but two conferences this fall are actively trying to build bridges between PHP sub-communities: ZendCon and php[world].


php[world] began last year, as the second conference by php[architect] after their long-running php[tek]. (Side note: I know brackets are not letters. Sorry. I blame Eli White.) It's explicit goal is to be a "summit" of different PHP projects. Last year's keynotes included Drupal's Angie "webchick" Byron and Jeffrey "JAM" McGuire, as well as WordPress's Andrew Nacin. It's back this year, and I expect it to be just as good.

The idea of php[world] is to encourage cross-polenation and collaboration between projects. There are distinct tracks for Magento, Laraqvel, WordPress, Drupal, Joomla, Zend Framework, Symfony, and Cake PHP: Most of the big players. Some sessions are targeted at just one framework, others at several. Importantly, however, they're all mixed up. It will be really hard to go to just Drupal, or just Joomla, or just Cake sessions. That's by design. The goal of the conference is to break down barriers and encourage attendees to learn and experience beyond their own island. Keynotes this year include Andrew Nacin of WordPress, Tessa Mero of Joomla, Taylor Ottwell of Laravel, and general PHP luminaries Lorna Mitchell and Anthony Ferrara (both of whom have graced DrupalCons before). And lunch will, of course, by a smorgasbord of everyone. A perfect opportunity to chat with people you probably don't know yet but could learn from (and vice versa).

Even then, there's still 9 Drupal-targeted sessions (including by yours truly) as well as many general PHP talks that should be applicable to everyone, Drupal or not (also including yours truly). As Drupal is now a multi-island project, attending an archipelago conference is something I invite everyone to do. Hopefully I'll see many of my readers there in Washington, DC, 16-20 November.


One of the oldest PHP conferences around, ZendCon this year is taking a cue from php[world] as well. Featuring sessions targeting a variety of frameworks, including 6 on Drupal (including, again, yours truly), this "more corporate" (relatively speaking) conference is trying to do its part to bring communities together as well. Plus, there are many sessions of general PHP interest, including multiple on asynchronous PHP. (Why does that matter? Check out the video of my DrupalCon Barcelona talk on Drupal in 2020 to see. You need to be ready for this.)

ZendCon is one of the largest PHP events in the world (even if it's dwarfed by DrupalCon), so if you want to get off the island and meet more non-Drupal developers (Tip: Yes you do), this is another good place to do it. ZendCon is coming up fast, 19-22 October in Las Vegas. That's just 2 weeks away. If you're in the area, come on by.

The PHP islands are dead. Love live the new, collaborative PHP community. Let's get together soon.

Share with

Oct 08 2015
Oct 08

Deeth Williams Wall Tagline

Deeth Williams Wall is a specialized law firm focusing on intellectual property and information technology law. Not only does the firm have experienced lawyers, but their team has an impressive mix of computer science, engineering, and “hard” science degrees appended to their job titles.

Their team is smart, experienced and ready to think outside the box to position their firm in a crowded marketplace.

The Playing Field

I’ll be frank - The legal practice isn’t exactly a sector which tends to be innovative when it comes to technology or marketing. DWW is based in Canada which is dominated by the “Seven Sisters” Law Firms which are monolithic organizations each with hundreds of lawyers. You’re going to see a lot of greys and blues in the sister’s websites, and they often feel stark, and clinical.

DWW has 25 lawyers and the last thing they needed was a “me too” approach on their website. Their firm is specialized and their website needs to be specialized as well.

Project Goals

After our initial brainstorming sessions we focused on 3 main goals for the site:

Content Strategy: People First - Emphasize the team at every opportunity.

Design Approach: Have personality, be friendly, be human, be memorable.

Editorial Process: Creating & distributing content must be easy and/or automated.

Legacy Wordpress Site

DWW was running a wordpress website. They have produced a remarkable amount of content including about 2500 articles on law and legal news. Unfortunately their legacy site had some technical problems that harmed their performance in search engines. We needed to keep all that great content, while dramatically improving the site’s Search Engine Optimization (SEO).

Technology Platform: Drupal 8

We built a conference site, and our company site in Drupal 8 (D8) and knew it would be a great fit for DWW. Like any technology choice there were trade-offs. By using beta software, the initial build progressed slowly compared to a Drupal 7, but in the long run knew we’d be building a more sustainable platform with a longer lifespan.

We launched the “Minimum Viable Product” website in mid-July focusing on the new art direction along with SEO improvements. We have a road map of planned features and A/B testing for aspects of the site. As time (and Drupal 8) progresses we have applied small incremental updates to dww.com.

Challenges working with a Drupal 8 Beta


Working with beta software certainly provided some challenges. There were some bugs, but most affecting the site have now been fixed as Drupal 8 moves closer to a stable release.

Contrib Modules

Many of the contrib modules we normally use in a Drupal 7 site simply didn’t exist. But I have been pleasantly surprised to find the features available in Drupal 8 dramatically reduces the need to use contrib modules at all.

Only 3 Contrib Modules Needed!

The 3 contrib modules we used were Token, Pathauto, and “Simple XML Sitemap”, (The “regular” XML sitemap module was not yet stable). In comparison our typical Drupal 7 websites would include 30+ contrib modules for a site of similar scope.

Benefits of Using Drupal 8

Drupal 8 provides some killer features which really helped accomplish our goals for this project.

Content Authoring Experience

Drupal 8 includes a great content authoring experience out of the box. Inline editing, file asset management, and systems for simplifying the content UI are included by default. These systems were very easy to change for our specific editorial requirements. Accomplishing this in Drupal 7 is certainly possible, but it’s a heck of a lot more work.

Responsive Images

Drupal 8 includes support for <picture> element out of the box. This is a new HTML spec that allows a web browser to load small images on small screens, and large images on larger screens. This is a critical component for making mobile-friendly websites load fast.

Flexible Template Engine

We’re picky about how HTML and CSS are coded in our websites. Drupal 8 has a very flexible template engine called TWIG which would allow us to easily and very precisely control the markup generated by Drupal. This allows us to easily implement 3rd party tools and libraries into the site without the need for a Drupal contrib or custom modules.

Project Highlights

Migrating 2500 Articles from Wordpress to Drupal 8

Drupal 8 includes a framework for migrating content into your website. This framework can be extended to import content from older versions of Drupal CMS’s. Currently D8 only supports Drupal 6 migrations with a “point and click” interface so we needed to improvise a little.

Drupal 6 to the rescue

Because we had a few thousand articles in Wordpress, we created a disposable Drupal 6 website to “stage” the content. Drupal 6 has a number of aging, but very reliable tools for migrating wordpress websites to Drupal 6. Once we had the content in Drupal 6, migrating all that content to Drupal 8 was literally a 45 minute job.

SEO Improvements with Schema.org Metadata

Schema.org outlines a specification for adding special metadata to you website to allow search engines to better understand your content. Specifically, you can tell search engines whether a chunk of content is describing a member of the firm, news about law, or a specific service offered. This improves a website's SEO and allows search engines to customize how your search results appear with rich snippets.

Drupal 8 supports schema.org out of the box, and with it’s flexible template engine, we were able to customize the metadata even further. Here’s an example from the Practice Areas page.

View “Practice Areas” with Google’s Structured Data (Testing) Tool


he tool shows the following metadata for the page:

An “Attorney Type” business

  • That has contact info (Address, Tel, Email, etc)

  • Social Media Accounts (Facebook, Twitter, LinkedIn)

  • Has a Logo

  • Offers Services including:

    • Intellectual Property

    • Patent

    • Trade-mark

    • (and so on)

Automatic Email Newsletter Generation

The articles written by DWW are distributed in a bi-monthly email newsletter called e-tips™.

The Old (Manual) Process

DWW’s content team sent articles in word docs to the IT department. They in turn loaded each article into the website. They then copied each article into their email system, applied some formatting, and then deployed the newsletter.

The New Process

With the new website the DWW content team enters content directly into Drupal and tags the content to belong to a specific e-tips issue. The e-tips content is automatically generated and formatted for the newsletter. IT does a single copy n’ paste from Drupal to the email system to create the newsletter.

This system saves time, and reduces the chance of errors. It was built very quickly using D8 core views module, and some simple theme templates.

Hootsuite RSS Feed for Automating Social Media

We also wanted to automate the distribution of articles to social media channels.

The content team simply flags content for Social Sharing and fills out a few extra fields. This is published to a customized RSS which is read by hootsuite.com, and is put in a queue which the content team then schedules for distribution to their social channels. The process can be fully automated. In this case DWW wanted more control. The content is automatically added to a queue which is moderated and scheduled by the team.

Automating Social Media

Mission Accomplished

The site has been successful achieving our project goals. DWW.com is a memorable, and highly functional website. We’ve be able to automate a number of content workflows while greatly improving the site’s SEO performance.

Our analytics show a major improvement in the bounce rate, along with a very significant increase in the average time spent on the site. By no means is the site complete. We’ve identified further design and SEO improvements; however, we have created a good base site that will serve DWW for years to come.

Drupal 8 Is Now Our Default Platform

Drupal 8 has allowed us to implement several very customized features for dww.com. We launched the site in Drupal 8 Beta-10 and have since upgraded to Beta-16. Most of the bugs we experienced no longer exist.

Unless there’s some specific Contrib module required for a project, Drupal 8 is our new default platform.

Oct 08 2015
Oct 08

Drupal 8 training

Drupal 8 is almost here! If you're ready to learn it, I'm ready to teach it!

Monday October 12th 1pm ET to 5pm ET REGISTER  [FREE bonus day not associated with 2015 Global Training Days]
Friday November 20th 1pm ET to 5pm ET REGISTER [This is part of the FREE 2015 Global Training Days]
Saturday November 21st 1pm ET to 5pm ET REGISTER [This is part of the FREE 2015 Global Training Days] 

Pick a day. Click the link. Get the skills!

For 4 hours, we're going to take a byte sized chunk of Drupal 8 as we wrap our minds around the NEW way of doing the old things and the NEW things we can do now!

We will be installing Drupal 8, creating content, creating pages, managing users, and finding out what all the fuss is about!
Big Thanks to PANTHEON for letting anyone launch a FREE Drupal 8 site with this link:  https://dashboard.pantheon.io/products/drupal8/spinup
What we'll do together:
[1] Install Drupal 8 via PANTHEON. 
[2] cruise around the User Interface to familiarize ourselves with the new layout and options.
[3] Next we'll create some content and experience the NEW UI. 
[4] We'll experiment with the new, fancy way that imaged are handled.
[5] We'll create some Listing Pages & Dynamic Blocks with the new VIEWS module included in Drupa Core.
[6] Manage users
[7] Some time for QnA at the end.

Oct 08 2015
Oct 08

I feel lucky to be a part of creating and building Drupal. According to BuiltWith, Drupal powers 2.8% of websites in the top 1 million. That translates to 1 out of 35 websites. I've been thinking about what that means in terms of real impact: if any of the 3.2 billion internet users today have visited 35 or more of the top 1 million websites, they've "used" Drupal. I imagine most active internet users have visited more than 35 websites, and as such, Drupal must have "reached" almost everyone on the internet. That is a pretty incredible thought.

I've heard so many amazing stories about how Drupal sites have been a part of cultural, social and political movements. One of the stories that I'll never forget is from the Egyptian uprising in 2011, when the internet shut down for days and people took to the streets in protest of the Mubarak regime. This moment showed the profound impact of the web and the injustice citizens feel when it is taken away. The Drupal site Al Jazeera was an essential news source on this uprising for the rest of the world and remained online despite traffic to its live blog spiking 2,000 percent during the crisis.

Another such story is that of the Global Disaster Preparedness Center (GDPC), whose 189 partner organizations (including the American Red Cross) needed a better way to collaborate on disaster relief issues. GDPC embraced Open Source and built a multilingual Drupal site where disaster preparedness professionals can share information and resources that otherwise wouldn't be available. Considering the recent rise in natural disasters, this information has saved lives.

These two stories show how the web has the power to change lives, fuel economies, educate the masses and make the world much smaller in the best of ways. According to Cisco, Internet traffic in 2019 will be 64 times the volume in 2005. It is expected that another 1.8 billion people could come online by the end of 2018.

Yesterday, we announced the first Drupal 8 release candidate after almost five years of hard work by thousands of people in our community. The road towards Drupal 8 has been long and hard, but I'm excited that Drupal 8 will touch the next billion people who join the internet. They are joining fast. I hope you'll share stories of the impact Drupal has made on your lives as we continue to grow.

Oct 08 2015
Oct 08
Mark Pavlitski's picture Oct 8th 2015Technical Director

We're really excited to see that Drupal 8 has officially passed Beta and entered the Release Candidate phase on schedule.

What does this mean for Drupal 8?

Drupal 8 has been a long-time coming (development started in early 2011!) but a lot has changed in that time. Fortunately the Drupal community has done an admirable job of keeping pace with advances in the web and supporting technologies, and have made numerous improvements over Drupal 7, but this has meant a lot of ongoing churn within Drupal 8's internals.

The Release Candidate phase marks the beginning of guaranteed backwards compatibility between releases, and means that the Drupal 8 community are now focussing on stabilisation and bug-fixes ahead of the official 8.0 launch rather than new features and improvements.

The recent announcement at DrupalCon Barcelona and subsequently meeting their target release date for Drupal 8 RC1 stands to highlight changes within the Drupal 8 roadmap and project planning mechanisms which are taking place throughout the Drupal community and the Drupal Association. This shows just how rapidly Drupal and the Drupal community are growing up to become a truly enterprise-grade system. 

And most importantly of all it means that the wider Drupal community, including agencies, businesses and end-users, are readying for Drupal 8's widespread adoption.

How does this affect Drupal 8 adopters?

The most obvious benefit is for Drupal 8 developers, who can now be confident that when they next update Drupal 8 they won't be caught out having to fix their own custom work or wait for module maintainters to release an update. This will help spur adoption within the community as more and more developers can be confident that their hard work won't be wasted the next time a new version of Drupal 8 is released.

Perhaps less obvious, but arguably more important, is that it means businesses can push forward with adopting Drupal 8 as an enterprise-ready product, without fear of compatibility issues or feature regressions down the line. Now that Drupal 8 is entering the final stabilisation phase you can be confident that this means only bug fixes and incremental improvements - no one is thrashing around under the hood anymore.

What does this mean for Drupal agencies?

We've been working internally with Drupal 8 for a while now, but this latest announcement has triggered a shift in our own perceptions of Drupal 8 from 'cool new toy' to enterprise-ready product.

We're already starting to see growing interest in Drupal 8 amongst our existing customer base and from new business, and only expect this to grow even faster now that Drupal 8 is approaching final release.

You can find more information about Drupal 8's features and benefits in the official release announcement.

If you're interested in a Drupal 8 project or want to know more about how Drupal 8 can help your business, please get in touch.

Rob Humphries's picture

You may also like...

Acceptance Criteria: What, why and how?

Building a website is a complicated process. I don’t want to downplay the importance of technical expertise, but for me the most difficult part of a website build is clearly and concisely capturing a client’s requirements.

Oct 08 2015
Oct 08

After what seemed like an eternal wait, yesterday's announcement that the first release candidate of Drupal 8.0 is ready means that we will be working with a very different Drupal going forward.

We’ve been gearing up for Drupal 8 since early 2013 so we would be ready to begin working on production websites on day one. We've kept track and learned the ins and outs of what makes the new Drupal tick; we've run internal training, attended conferences, blogged and presented talks at conferences on the changes ahead.

As of today, all new Drupal websites we work on will be delivered on the new platform. Our multidisciplinary full-time team in Research, UX, Design and Digital Strategy are already researching and preparing to make the most of what the CMS, right through from ideation, deployment and support.

We're relishing the opportunities the new system provides and to continuing to offer industry leading expert Drupal development services in Ireland to the highest profile adopters of the system.

Our Drupal based projects have been recognised by premier industry awards bodies, most recently securing five finalist nominations, including Web Agency of the Year, at the upcoming 2015 Realex Web Awards.

Why did we hold off until now?

Beta versions of Drupal 8 have been available for some time. In theory, we could have began to work with the new system before now and transitioned websites to a stable version once released. However, after much debate we felt this was too risky a proposition for both our clients and us given the nature of the bugs that existed at the time.

Oct 08 2015
Oct 08

Too many websites claim to be able to turn your website into a mobile app but not one of them deliver results as expected, the simple truth is you can’t automate the process, it will always leave something to be desired. Our software couple with custom implementation can turn your Drupal or WordPress website into a mobile feeling app. With native login functionality the user does not need to repeatedly login to the app giving the illusion of a 100% native mobile app from a website that lies behind a login.   After logging in once the user simply clicks the homescreen icon and will be taken to the authenticated/logged in website area. All viewed from within a native iOS or Android wrapper. Custom offline messages and native navigation can all be implemented out of the box with our software. The overall time to implement the basic service for your app is $3000, the source code is yours forever with no annual fees, and you publish directly from your developer account. This services service will get you better results than an automated do-it-yourself platform,and also authentication and login which platforms like Appresser can’t do. To convert a a website/webapp the one click homescreen icon app experience.  The API currently exists for Drupal 6 or Drupal 7 sites. App software is written in both native iOS (Objective C) and Android (Java) code.


Sign up using your email or Facebook SDK, the app communicates via REST to your website.

Choose to sign in with Facebook once and then sign in automatically by clicking your homescreen icon.


App gets added to homescreen and login via one click.

Preloader provides instant touch feedback for a native feel.


Custom offline message instead of web browser “page not found”.


Turn any responsive website into an app.

Oct 08 2015
Oct 08

Last night (my time) I got the good news over twitter:

Blue smoke from the chimney, I repeat blue smoke from the chimney! #Drupal8 release candidate 1 has been released! Good day for #Drupal!

— Marc Drummond (@MarcDrummond) October 7, 2015

That’s right, Drupal 8 has it’s first release. But what does that mean? Is it done? Can I start using it yet? What kind of changes are coming? Will dawehner get to sleep, at last?

Are we there yet?

Despite all the rejoicing on social media, this isn’t the final release for Drupal 8 – it’s only the first Release Candidate. This means that we have (officially!) 0 “critical” bugs left to fix in Drupal 8. That means exactly what it sounds like: there are no critical, world-ending bugs left… that we know of. Just like any software product, we’ll continue to discover critical issues through its entire life cycle. We’re still finding occasional critical issues in Drupal 7 almost five years since its first release candidate; that’s just a part of supporting a piece of software over the long term. The RC phase means that while Drupal 8 is stable enough to use, we’re still discovering critical bugs a little too frequently to recommend it for everyone, in every use case.

“A little too frequently” means that the rate of critical bugs incoming is still too high to be able to promise the fast respond-and-fix turnaround that we want. Every two weeks we’ll create a new Release Candidate version that fixes whatever new criticals have been discovered. Once the core team is confident that they can squash bugs in a timely enough manner, they’ll (finally) release Drupal version 8.0.0.

But when will it REALLY be released?

“When it’s ready” still applies! But we are very, very close now. To give you a point of reference, Drupal 7 went through four Release Candidates before release (two months). That codebase was a lot more fragile than this one, so it’s reasonable to hope that we’ll have a very Drupally Christmas season this year. Personally I’m betting on January.

Can I use it yet?

Yes! Some terms and conditions apply.

Just because there are no criticals left, doesn’t mean that D8 is completely bug-free! We have a big pile of known “major” issues that have been deferred until after 8.0.0, which should impact your decision. You can see at that link that some of them are already ready to be committed. The catch is that during the RC phase, we aren’t allowed to commit these fixes. We’re basically only allowed to work on criticals and documentation. So there are still some serious issues that might be a problem in some use cases.

The biggest issue (that I know of) is a potential incompatibility between Drupal 8’s new “cache tags” header and some hosting providers. The problem is that Drupal includes some important caching information on the “back of the envelope” of its response to a page request, and it’s possible to run out of envelope! If the cache tags header gets too long for the web host to handle, it can behave unpredictably. You might get white screens of death, or it might just shorten the cache tags header, removing important information. There’s a solution in the works to allow a maximum length setting, but it won’t make it in until 8.0.1 (two weeks after 8.0.0). In the meantime you should avoid D8 if you have any very complex pages with many elements. The examples in that ticket are good ones: a news site with very complex layouts, or a single page site with a lot of “stuff” crammed onto the one, front page.

The other “gotcha” to bear in mind is that it will take some time for Drupal’s contributed modules ecosystem to catch up with the new version. According to Bluespark’s status of the top 100 modules for D8 page, so far only 9 of the top 100 D7 modules have a D8 release marked “stable.” 19 of those top 100 modules are included in D8 core however, so our total count is up to 28. This is enough to give a good foundation for relatively simple sites, especially if you have some PHP skills under your belt. But I wouldn’t go building a complex Intranet on it just yet!

Wait, so it’s still busted?

No! Drupal 8 is a solid platform for most use cases – that’s the point of the RC release! It’s time to go ahead and use it for site builds. Just take it easy and use it for simple sites, first. Give the rest of the community a chance to release stable modules, and hold off on that Facebook-buster behemoth website you’ve got planned until a few months after launch.

What happens after 8.0.0?

After 8.0.0 is released, we will make an enormous, fundamental shift in how Drupal is developed. We will start using semantic versioning with a regular release schedule. Every two weeks we’ll release a new “patch level’ release: 8.0.1, 8.0.2, and so on. Patch level releases will be bug fixes only, and will be backwards-compatible – that means they won’t break anything on your site. Approximately every 6 months, we’ll release a new “minor level” release: 8.1.0, 8.2.0, etc. Minor releases are allowed to contain new features, but they are still guaranteed to be backwards-compatible. So even these releases won’t break anything on your site. We’re still figuring out the exact process for minor releases, but they will include similar phases to what we’ve seen with D8 core: a beta phase, and release candidates until we’re sure there are no more criticals.

What about API changes, and features that would break existing sites? We won’t even start developing on those until well into the D8 life cycle. Those changes will belong in the 9.x branch, and will be kept completely separate from anything that could touch your site.

The key take-away here is that D8 updates should never break your site. They may add features, but they will not interfere with whatever you’ve already built. We’ll continue a regular pace of improving the product in a predictable, scheduled, and backwards-compatible way.

Where are the best Drupal 8 release parties?

The Drupal Association is coordinating promotion for official Drupal 8 launch parties. If you want to host one, just fill out their form and they’ll help you promote it! So far no one has built a site mapping the parties, but keep an eye out in the #drupal hashtag on twitter!

Who do I congratulate? Who do I thank?

Drupal 8 RC 1 is the combined effort of more than 3200 contributors. That is an incredible number. By comparison, Apache, the world’s most popular open source webserver, has 118 contributors. MySQL, the database platform which runs an enormous portion of the Internet, has 1320 contributors. So you can basically walk up to anyone at a Drupalcon and thank him or her!

Most of the contributors to Drupal 8 leaned on the support, training, and hand-holding of mentors at Drupal events all over the world. I know I needed a mentor for my first core contributions, and I got to turn around and mentor other people myself. The mentors are the support network that made this level of mass contribution possible.

But the level of effort is definitely not evenly distributed. Most contributors have made fewer than 20 registered contributions. But some people have really gone above and beyond what anyone would expect. It’s no exaggeration to say that these people have shaped the future of the Internet.

It is easy to concentrate on the number of contributions as the only metric of involvement in the release of D8. But some of the biggest influences on Drupal 8 have been community leaders, whose effort is not counted in commits under their own names. The initiative leads who architected and directed all this contribution: heyrocker, Senpai, jlambert, Crell, dmitrig01, Gábor Hojtsy, Jose Reyero, mitchell, jenlampton, bleen18, jackalope, ericduran, jhood, jacine, shyamala, rupl, JohnAlbin, twom, and sofiya. Without them, we would have had nothing to commit!

Listing all of those names brings to mind the platform that they all use to contribute and coordinate: drupal.org, maintained by the Drupal Association. It also brings to mind the events, like Drupalcon, Drupalcamps, Dev Days, which everyone attends to collaborate, teach, and learn; also maintained by the Drupal Association. Not to mention the Drupal 8 Accelerate program, which raised $250,000 towards developer grants; also created and maintained by the Drupal Association. The people at the Association have worked tirelessly to support this release.

All of this developer time is extremely valuable, and not all of it came out of the developers’ own free time. Huge swaths of Drupal 8 development have been sponsored by the companies that participate in the community. We’ve only been tracking their contributions for a short time, but the information we have is powerful. This release would not have happened without the developer time donated by companies like Acquia, MD Systems, Chapter Three, Tag1, and Druid. A quick glance at Drupal.org’s Drupal Services page shows us that contribution is a normal part of the culture for the biggest Drupal companies. These were the top 5, but almost every major Drupal shop has contributed in some measure. Thank you to these companies for believing in our product and supporting it so generously.

Finally, the people who bear the greatest personal responsibility are definitely the core maintainers. These people don’t just deserve your thanks; they deserve lifetime supplies of free beer sent to their homes. I can’t offer that on a blog; all I can say is THANK YOU.

Alex Bronstein

Dries Buytaert

Angie “webchick” Byron

Nat Catchpole

Jess Myrbo

Alex Pott

To everyone who contributed, but especially the people I’ve listed here: You’ve made a new generation of Internet innovation possible. Thank you.

Oct 08 2015
Oct 08

Post date: 

October 8 2015




drupal, drupal 8, drupal planet

If you're a Drupal developer, there's a good chance that at some point you've done a search for "Programmatically attach files to a node in Drupal 7" or similar. I know I've done the search repeatedly, as while it's a common enough task it involves just a bit too much code to not be retained by my long term memory.

Now that Drupal 8 is upon us adding a file to a node (or any entity) is far easier. I'm not going to do a comparison, however, as I don't want to confuse anyone who stumbles onto this post with the intent of simply copying and pasting the below code snippet, so you'll just have to take my word for it.

So, straight to the point, this is all it takes to programmatically attach a file to a file field on a Node:

  1. use \Drupal\node\Entity\Node;

  2. // Create file object from remote URL.

  3. $data = file_get_contents('https://www.drupal.org/files/druplicon.small_.png');

  4. $file = file_save_data($data, 'public://druplicon.png', FILE_EXISTS_REPLACE);

  5. // Create node object with attached file.

  6. $node = Node::create([

  7. 'type' => 'article',

  8. 'title' => 'Druplicon test',

  9. 'field_image' => [

  10. 'target_id' => $file->id(),

  11. ],

  12. ]);

  13. $node->save();

In the above example we are taking a remote file and saving it locally, which is probably the most commonly used case when programmatically adding a file to a node.

What if the file is already present in your local file system and you want to attach it to an existing node? Here's an example for that too:

  1. use \Drupal\node\Entity\Node;

  2. use \Drupal\file\Entity\File;

  3. // Create file object from a locally copied file.

  4. $uri = file_unmanaged_copy('public://source.jpg', 'public://destination.jpg', FILE_EXISTS_REPLACE);

  5. $file = File::Create([

  6. 'uri' => $uri,

  7. ]);

  8. $file->save();

  9. // Load existing node and attach file.

  10. $node = Node::load(1);

  11. $node->field_image->setValue([

  12. 'target_id' => $file->id(),

  13. ]);

  14. $node->save();

And lastly, what if you want to stick a placeholder file to a node? Thanks to Drupal 8, this is too easy:

  1. use \Drupal\node\Entity\Node;

  2. $node = Node::create([

  3. 'type' => 'article',

  4. 'title' => 'Generated image test',

  5. ]);

  6. $node->field_image->generateSampleItems();

  7. $node->save();

So get to it, programmatically attach files to your nodes and be merry!

Oct 08 2015
Oct 08

Before I say anything… DRUPAL 8 IS RC1!!! Great work to all the contributors that poured themselves into it to get it “done when it’s ready”. It’s looking like a really solid platform to build on down the road. Now..

I spent much of July traveling to Drupalcamps and it was so fun I’m doing it again! ELMS Learning Network will have presentations in the following locations over the next few weeks so if you are looking to learn about ELMSLN or how to optimize your existing Drupal sites and servers they run on, meet up with me at one of these locations!


Baltimore, MD (Oct 9th)

Tuning Drupal out the Wazzooo

We’ll look at how to improve the performance of Drupal by optimizing the stack it runs on. This talk covers all aspects of Drupal optimization including: Tools for identifying issues, Apache, MySQL, PHP, Varnish / Pound, cache bin management, and contributed modules you can get to make D7 fly. While these concepts will be shown within Drupal 7, many of the same techniques can be applied to Drupal 8 (or Drupal 6 for that matter).

We’ll point to multiple purespeed and other optimization posts on this site, as well as the ELMS Learning Network repository where we keep many of these recommended defaults. I’ll then take a bare-bones Virtual Machine that’s juuuuust powerful enough (at a baseline) to run Open Atrium 7.x and apply the techniques and changes I’m recommending so we can see the performance gains in real time. This is effectively the process I undergo when I come across any inherited server and recently used this to save a Drupal site that was effectively dead when it started missing it’s reverse proxy on calls prior to applying these settings.

This talk draws on a lot of documentation both in and out of the Drupal community and consolidates many of the recommendations by mikeytown2 (@mcarper) of advagg, boost and httprl fame.

DrupalCamp Atlanta

Kennesaw, GA (Oct 16th - 17th)

ELMSLN: Rethinking Systems Design

In this talk I’ll quickly outline the technology architecture powering ELMS Learning Network and how you can utilize this concept in the design of systems going forward. ELMSLN uses lots of smaller scoped sites that are all REST capable in order to achieve a unified user experience for end-users, while allowing for continuous and distributed innovation in educational technology. We don’t know what we’ll have to build to match the pedagogical needs of faculty, we just know that we have to.

It is also important to note that I said we; because ELMSLN is now a distributed group of developers and instructional designers at multiple institutions and organizations collaborating to build a better learning ecosystem. There are now multiple full time developers donated to this effort with adopters outside of Penn State now utilizing the platform.

Come learn about ELMSLN’s architecture which you can apply to any project as well as the state of the project and where we’re going next (hint: http://codepen.io/michael-collins/pen/memxpe ).

DrupalCamp Ohio

Columbus, OH (Oct 23rd - 24th)

Tuning Drupal out the Wazzooo

Same talk as Baltimore above though this session submission is more detailed.

Ignite talk: Drupal, a Thesis

This is the story of the secret life btopro lived the last 8 years of my life in pursuit of a Master of Sciences in Information, Sciences & Technology… boiled down into 5 minutes. I recently achieved this degree for my work using Drupal to facilitate social change within an organization. The thesis outlines a concept I’ve coined Information Altruism (the new title of my personal blog on the topic) which states that the donation of effort and work devalue and eliminate market potential in existing spaces. This socio-technical theory can be applied to existing information markets to fundamentally alter the way they operate.

Oct 08 2015
Oct 08

The Buzz is all about PHP 7, and rightly so, it's pretty incredible some of the performance metrics its pulling even relative to Facebook's HHVM. Brad Fisher wrote about a one-line installer to get up and going with PHP 7 if you want to play around with it. But then reality sets in...

It's still a bit too early to run PHP 7 in production and Drupal 7 has some issues ancedotally from testing. Nothing deal breaking, but nothing that we're going to drop everything we're doing today and fix all the potential issues (a few months from now, yeah maybe). So, what can you do today to crank up PHP? Well that's where we pick things up. The following assumes CentOS/RHEL 6.x but similar commands will work for all the others (the locations change)

PHP.ini tuning

The first place to start is the thing that's pretty global to what version of PHP you are running. The settings that I recommend is drawn from reading forums, feedback from modules like apdqc (which makes recommendations) and other sources.

You can find the full file here but the key settings are:
max_execution_time = 90
max_input_time = 60

memory_limit = 256M

upload_max_filesize = 50M
post_max_size = 50M

; Recommendation from @mcarper
realpath_cache_size = 1M
realpath_cache_ttl = 3600

Max execution is useful because you might have a cron hit or drush command that takes a long time to process and you don't want things to timeout. Memory limit I always set really high again, in case there's a cache rebuild that takes a lot of memory. I dont see things get anywhere near this but it never hurts.

Upload and post sizes are useful if you have files that people upload to the site and they go above default which is only like 1 meg. The last 2 settings are recommendations from mcarper via the apdqc module (which we'll cover in a later posting).


If you run PHP 5.3, you'll want to get APC up and going. APC allows for caching the location and content of PHP files in memory. This allows PHP to compile a hell of a lot faster since it doesn't have to load all the files all the time. We also recommend exploring APC's user bin as it can provide a drop dead simple way to make Drupal fly on limited resources. If you're running PHP 5.3...


sudo yum install php-pecl-apc


Apply the following script to sudo vi /etc/php.d/apc.ini

Upgrading off of 5.3

If you can, there's a lot of reasons to upgrade from 5.3 for performance and security reasons. If your currently on 5.3, you can run something like the following to get up to PHP 5.5. The biggest change in upgrade is that APC will stop working (if you have it currently applied) because Zend Opcache is available for it (so basically core)! We'll upgrade using Remi though Brad often recommends Webtatic.

wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
rpm -Uvh remi-release-6*.rpm epel-release-6*.rpm
yes | yum -y --enablerepo=remi,remi-php55 install php-opcache php-pecl-apc php-cli php-pear php-pdo php-mysqlnd php-pgsql php-pecl-mongo php-sqlite php-pecl-memcache php-pecl-memcached php-gd php-mbstring php-mcrypt php-xml

This will set the repo to download from to REMI (a popular compiled source) and then get a lot of the dependencies that you'll want for running Drupal like pear, apc, opcache, mcrypt, mbstring, memcached, gd and others.

Tuning Opcache

Opcache is a big deal as it's basically a better supported and FASTER version of APC. I read a few articles on tuning opcache and while there are different ways to do it, I'm running these in production with success.

Add these settings to /etc/php.d/opcache.ini

# optimize opcodecache for php 5.5

The key settings here are the max_accelerated_files, memory_consumption and the fact that it's enabled :)


Because APC is no longer the prefered opcache module and Zend Opcache doesn't support the user bin side of APC, if you still want that then you'll need a repo for it. The command to upgrade php to 5.5 includes apcu. If you want to add to this file by enabling progressive uploads then you can use this file.

Oct 08 2015
Oct 08

Brad Fisher (@bradallenfisher) started a #purespeed channel in our slack channel a few months back. Since then, we’ve both been doing a lot of work to tune every aspect of drupal page delivery. What will follow is a series of blog posts about tuning every part of the stack. We’ll cover:

In this first post, we’ll look at the patched core that ELMS Learning Network runs as part of its drupal setup.

The core can be found here: ELMSLN Drupal 7 Core.

The patches can all be found here but we’ll walk through each one below:


Second loop in module_implements() being repeated for no reason

This essentially corrects a logical mistake in a big part of core, module_implements that prevents multiple calls to module_implements having to process all the projects involved. module_implements is used a ton of parts of Drupal core and contrib. Optimizing this is a decent gain as can be seen in this comment.


Improve theme registry build performance by 85%

This is pretty insane, infact I couldn’t believe it til I applied it and did some analysis which you can see in the thread. This one patch cut page load times on theme rebuild and clear all caches down about 400ms!

UPDATE: Quicksketch has suggested an alternative patch to this function that goes even further then the one referenced here!


Add static cache to module_load_include()

This is another decent gain by just utilizing static cache correctly and gives significant gains on how long it takes to do full cache clears. This is important because as everyone knows, rebuilding drupal is painful from a performance perspective and this can help make things happier for the unfortunate souls that kick these off or get the first hit after your site has no caches populated. As my findings and others suggest, this took 1.7 seconds off of CC all!!!


Waiting for table metadata lock on cache_field table

Captain of amazing performance optimization, Mike Carper realized that cache tables were locking transactions when there were calls to truncate it. By renaming the table, then truncating and renaming it back, he was able to reduce deadlocks. I don’t understand this one to be totally honest but it works :)

Oct 08 2015
Oct 08

I’m in the middle of several Drupal Camp / Con’s (any event over 1000 people is no longer a “Camp” but that’s for another time) and it’s occured to me: I can no longer learn by going. Now, this is learn in the traditional sense of what I used to go to Camps for (been coming to camps for 8 years now).

It’s not that I’m advanced beyond younger me, it’s that this ecosystem is an endless rabbit hole of buzz words, frameworks, CLIs, VMs, architectural components, issue queues, PRs, and other words that must make most anyone new to anything web immediately freak out and hide. And so, in coming to events I feel I rarely get to learn about implementing BEM or SASS or DrupalConsole or Composer or Dependency Injection because 1 hour or 50 minutes for a talk isn’t close to enough to scratch the surface of these concepts.

What IS important thought at Camp sessions:

  1. Community; hearing from peers and discovering together how much all of us don’t know everything
  2. Learning new buzz words, which is critical because I don’t know what to Google!

For example, I assumed everyone already knew what Drupal Console was only to find out that most people I talk to go “Duh-huh-waaaa?”. And so, to heep some more Buzz words on you all from the Camp circuit and why I’m so excited for them :)


Drush is the original command-line Drupal (you’ll see why I frame it that way soon). It allows you to communicate with your drupal site via commandline, issue commands, routinize boring tasks and do complex scary tasks as single commands. Other modules can supply plugins for this as well as anything you’d like to just use as a plugin without modules.

Drupal Console

Drupal Console is a bit of the new kid on the block. It originally was met with resistance, as it’s another CLI for Drupal, but has since started to find its place in the early D8 CLI communities that are developing. What’s cool about Drupal Console is that it’s starting to find a happy middle ground of coverage for things that Drush kind of was weak at. What else is cool, is that these communities are working together to reduce overlap in capability AND (more importantly) allow for each to call the other natively. This means you’ll be able to start execution threads like `drush drupal-console ….` or `drupal drush en views`.

Console doesn’t have support for running off and grabbing Views. It’s much more of the architecture of building out things that you need to work with your drupal site, but without writing all the code (for example). Think of it more as a utility to help you work with Drupal in the development side of the house. While Drush has plugins for things like module building, code review and entity scaffolding, they were never its strong suit. This is where Drupal Console is focusing its efforts.

Drupal Console also has Symfony based plugins since it’s building against Symfony Console. Drush on the otherhand is your traditional Drupal architecture, supporting multiple versions of Drupal, etc.

Why you should care

Because if this PR / thread in Drush-ops moves forward, it would mean the two could call each other. This will allow for two different ways of developing for CLI devs, pulling in Symfony components, or traditional drupal guts. It also gets you a bigger community working on things at the low level so that stuff at the high level (site building, theming, etc) is easier and more scriptable. With Drush you’ll (still) be able to build make files and get all the dependencies for your site and with Console you’ll be able to write new modules and sub-themes a lot faster because of the templating / file trees that it will allow you to build.

As we get towards a stable D8, Drush and Drupal Console, we’ll have so much raw HP under the hood that you’ll be able to automate all kinds of things. It also means these communities can tackle different sides of the under the hood problem space for getting Drupal going.

For example; I maintain Drush Recipes which allows for tokenized drush chaining. This lets drush call itself and via arguements you get a lot of stuff done without much effort. Jesus Olivas just made me aware that there’s some Command Chaining being worked on for Drupal Console. This way you could string together commands in Console (allowing console to call itself basically) that allows you to get something more functional / end-result then having to manually type the same kinds of commands over and over (he gives an example in the blog post).

The future Drupal Development environment / workflow

Here’s a few projects that if they merge efforts even a little bit in capabilities over the next year or so, you’ll see some insane things start to get automated and working with Drupal will make anything else look painful by comparison (again, looking ahead, right now… yowza!).

What this would give you workflow wise:

  • An Ansible / YML based provisioning of a server, netting all dependencies for D8, Console, Drush, etc
  • You could login and be presented w/ a prompting like Nittany Vagrant provides, asking what kind of site you want to build
  • With even minimal logic to the script (yes I’d like a Drupal site that’s for commerce for example), we could issue a drush recipe that…
  • Runs a make file, si minimal’s itself, grabs dependencies if they weren’t in the make file, set variables and import default configuration from features to make the OOTB “distribution” a rock solid starting point for anyone to build off of.

Then we’d ask other question. Like “What’s the name of this client”. Answering something like “bigbank” would allow..

  • Drush Recipes to tokenize the input of Drush to call Drupal Console
  • Console would then be told “Hey, we need to build a new module called bigbank_custom_paygateway, bigbank_helper, and bigbank_theme” create all the components for the types of custom modules that we all use on every deployment with anyone
  • Then enable these modules in the new site

Eventually we can get into automatic sub-theme creation, asking what kind of theme you want to base off of (zurb, bootstrap, mothership, custom, etc) and automate a lot of the setup in that area too. We could probably get to the point to w/ theming where you can ask Drupal Console for the template files (defaults obviously) that you want so that it generates those too.

The future is going to get so insane (buzz words wize) we’ll need to keep investing in automation just to keep up. We’ll tell each other to just download XYZ and run through the workflow; there will be no more “hey go get all these dependencies and…” no, things will just be, awesome!

Now, create a PuPHPet style interface that builds the YML customizations (Or maybe like this thing), asks the crappy bash questions, and tokenizes everything downstream… stuff that system in a simple Drupal site and hand it to a Project Manager to kick off a new build.. and THEY’VE started building the site. True empowerment and liberation of workflows is upon us. Now let’s all go drink coffee!

Oct 08 2015
Oct 08

It was a nice little saturday in happy valley. Since my son is forcing us to watch the Sponge Bob Square Pants movie over and over, I decided to multi-task. Bryan Ollendyke has been talking about PHP 7 a tad bit lately so I decided to whip up an instance. 

Granted this is not ready for prime-time just yet, however, it is extremely fast and everything that I have tested so far works fine. Turn on authcache and it is REALLY fast!

There is a session_destroy Warning when logging out of drupal but that can be suppressed and probably is being addressed. If you run this check out the status page and you will see green!

Here is the link to the github repo make a pull request if you have any patches. https://github.com/bradallenfisher/php7-centos7-mysql5.6 

I am currently working on a vagrantfile for it, so if you don't have access to a linode or a digital ocean account hang tight.

Here is the one-liner to run on your newly created VM.

yum install git -y;git clone https://github.com/bradallenfisher/php7-centos7-mysql5.6.git; cd php7-centos7-mysql5.6; chmod 700 install.sh; ./install.sh

For some quick stats using this setup, here is what devel is telling me. :)

Executed 54 queries in 12.52 ms. Queries exceeding 5 ms are highlighted. Page execution time was 34.56 ms. Memory used at: devel_boot()=0.56 MB, devel_shutdown()=2.86 MB, PHP peak=2 MB.


This is should only be used for testing the future. 

Oct 08 2015
Oct 08

I was made aware that it’s been close to a year since I actually did a demo of the reason that I contribute so many modules to drupal.?org. For those that don’t know, the reason I exist is a project called ELMS Learning Network. It is a Drupal 7 based deployment methodology that takes the many parts of an LMS and fragments them across a series of drupal distributions.

We then take those distributions and using RestWS, single-sign-on, and a common module and design meta-distro, stitch the experience together. The goal is to create more engaging, customized learning ecosystems by envisioning each educational experience as a snow-flake. The project’s iconography of a snow-flake comes both from the networked nature of the different distributions that make up the system as well as that mindset that we need to treat courses as individual art forms that can be beautiful in their own unique way.

Anyway, below is a video showing everything about the project in its current state. If you have any questions about what modules make it up, they can all be found in the links below along wth the repo.

Up coming camp presentations about ELMSLN:

Oct 08 2015
Oct 08

Yesterday something significant occurred, http://brandywine.psu.edu launched on the new Polaris 2 Drupal platform. And soon the Abington Campus web site will move to the same platform. And perhaps many more.

Ten years ago this would not have been possible. Not because of the technology but because of the landscape and attitude here at Penn State. Words like 'portal' and 'content management system' were perceived as negatives, as things to avoid, as poorly implemented technologies.

That has changed.

One could argue that moving the Penn State home page and new site to Drupal was the significant event, but I was not convinced. That change could have been an anomaly, a lack of other, better options, or just pure luck. Not that a number of people in the Penn State Drupal community did not spend a great deal of time and effort into presenting Drupal as a viable option, but that once that argument was presented and accepted, the process to actually create the site was... let's say byzantine. So in my mind moving www.psu.edu to Drupal, while radical and important, did not 'count'.

So yesterday's launch of the Brandywine web site confirms not only the success of Drupal at Penn State, but also a change in mindset and attitudes at a much higher and broader level at the University.  Additional possibilities for the use of the Polaris 2 platform may be in the works, hopefully we will learn more about those soon.

Perhaps there will also be a Polaris 3....

Oct 08 2015
Oct 08

There’s many dirty little secrets in Drupal 7 core’s API when it comes to inconsistencies and oversights. It’s a big part of why so much care is being placed in D8 and its taking so long, because people realize this is a platform that’s used for the long haul and core decisions today will have lasting impacts a decade from now.

That said, I discovered one a year or so ago and kept putting it off, hoping it would go away on its own. Well, it hasn’t and here comes a potential scenario that I detail in an ELMSLN issue queue thread I like to call Role-mageddon. While this doesn’t just affect distributions and install profiles and features, it is a lot more likely you could run into a problem there with them; and so here we go.

Example Scenario

Site 1 (Profile A)

  • Developer Adds a Feature X that adds 2 roles
  • Then creates Views, Rules, and blocks and associates roles to access / visibility
  • Then they create Feature Y with 1 role and do the same as before

Site 2 (Profile A + the additions above)

  • Developer Enables Feature Y
  • Developer Enables Feature X
  • All access / visibility criteria of Roles / functionality supplied in Y is flipped with X
  • Oh Sh….

So What happened?

Roles in drupal are stored as id, name, weight. id is generated based on the database being incremented, so anonymous is always user rid 1 and authenticated rid is always 2. After that, it’s the wild west of whoever comes first gets the next id.

Well, if Roles 1 and 2 are created then Role 3, they’ll get ids of 3,4,5.

If Role 3 is created then Roles 1 and 2, they’ll get ids of 3,4,5 but all views, rules, blocks, anything associated to the rid identifier is now associated with the wrong role!

Without this knowledge you could have oh, i don’t know, made all your admin blocks visible the ‘bosswhopays’ role on production and not understood why ). This would also happen if your in dev and have a role that doesn’t move up to production that was created prior to the others that are about to. You move the features up, and none of the settings are kept.

So how do we avoid Role-mageddon?

Role Export adds a column called machine_name to the role table, and then uses the machine_name value to generate a md5 hash value which is used to create the rid. Then, so long as machine_names are unique, it effectively gaurentees that rid’s are unique and won’t collide with other roles that you import / migrate.

The import / export order no longer matters because they’ll always map to

Great for the future, but what about my existing site?

Role Export had support for automatically remapping the updated rid so your users roles don’t get lost, as well as the admin role variable and the permissions associated to the role. That’s great, without those this would have been basically worthless for existing sites.

What my patch of infinite lack of sleep provides, is the same exact thing but for Views, Rules, Blocks, Masquerade settings (since that has security implications and is popular) as well as a hook that can be invoked to fix your other variables like IMCE, Piwik, and LTI.

Oct 08 2015
Oct 08

One of the options in Nittany Vagrant is to build a local, development version of an existing Drupal site - copying the files and database, then downloading it to the Vagrant VM.  Its is pretty straightforward, but there is the occasional trouble spot.

Here is a short video of how to do it.

Oct 07 2015
Oct 07

Yoast SEO, known for its powerful features as a must-have Wordpress plugin, has released a Drupal module. This move has surprised many in the industry, but for Drupal users it is wonderful news.

As Softpedia.com observed: "...the Drupal module will be a complete rewrite of the WordPress plugin, molding on the fine edges that make the Drupal CMS so powerful, and will also feature Yoast's Real-time Content Analysis platform."

Here are a few others reasons why this is such good news for Drupal users:

Yoast is Very Good at Simplifying SEO

Yoast earned a reputation for analyzing the tediously complex tasks of SEO and reducing them into simple steps for the website owner. It made life easier for everyone.

The Yoast SEO project page on Drupal.org sums up the new Yoast SEO module this way:

This module checks simple things you're bound to forget. It checks, for instance, whether your posts are long enough, if you've written a meta description and if that meta description contains your focus keyword, if you've used any subheadings within your post, etc. etc.

It ensures you've actually chosen a focus keyword for each article and ensures you're using it.

(Side-note: in the Drupal announcement linked above, it says Yoast makes sure you're "using [your focus keyword] everywhere." That shouldn't mean, however, that you should engage in keyword stuffing. That doesn't work anymore. The new Google algorithm knows when you're trying to stuff keywords and penalizes you for it. Remember, the name of the game is now Search Experience Optimization, not Search Engine Optimization. Write for the experience of the reader, not for the search engine robots. Don't make your posts awkward and hard to read by over-filling them with keywords.)

It's Coming Just in Time for Drupal 8

After the DrupalCon 2015 conference in Barcelona, Spain, the Yoast SEO module became available for Drupal 7.x. Hopefully this means that Yoast is already working on or at least planning its Drupal 8 version. That would be perfect timing for Drupal users: not only would they be getting a new Drupal version soon, but they would have a new world class SEO module to go with it.

It's Also Bringing GoalGorilla Into the Mix

Yoast has found a friend in GoalGorilla, an award-winning Dutch company that uses a variety of powerful design and analytic tools to help you learn more about your users. As their humorous landing page says in its English translation, "you've never been so close to your users." GoalGorilla was a #1 winner at the DIA (Dutch Interactive Awards). Their involvement in Yoast SEO for Drupal is definitely a good thing.

A Few Final Thoughts on the Benefits of Yoast SEO

If Yoast SEO for Drupal turns out as good as its Wordpress version, we can expect it to work similar feats of magic, such as these features:

  • Handles pinging for you by sending up-to-date sitemaps to the search engines. This enables search engines to add your content more quickly.
  • Allows you to write two headlines, one for search engines and one for your visitors, thus ensuring your articles are optimized for the user's search experience while also feeding search engines great keywords in the headline.
  • Reminds you if you need to fix a post url, slug, or other element that's hurting your SEO.
  • Allows you to add page redirects when old posts are getting a ton of traffic but you'd prefer the traffic goes to a newer, updated post.
  • Fixes incorrect links from other sites. If someone mangles the URL for your page, Yoast has a way of fixing it and getting the visitor to clean permalinks.
  • Hopefully the features listed above, and the many other perks of the popular Wordpress plugin, will find its way into Drupal.

Subscribe to our newsletter for more helpful tips about Drupal that can help you achieve your business objectives.

Oct 07 2015
Oct 07

Today, the Drupal community has officially released the first release candidate of Drupal 8, with the final release imminent. This is a historic day for Drupal, the open-source content management system that powers your website as well as millions of other web properties in the world.  This release has been 4+ years in the making, had 3000+ code contributors, and represents a huge opportunity for you. We believe your presence on the web is the single greatest marketing tool that exists within your organization. Even if a major site redesign is not on your short-term horizon, we highly recommend educating yourself on what this release means to your organization. Here are some key items of consideration:

1. There are over 200 significant improvements to Drupal 8. These changes include “mobile first” functionality, extensive multilingual capabilities, built-in web services, a robust configuration management system, and WYSIWIG features that are much more authoring friendly for content administrators or "non-technical" users.

2. Drupal 8 leverages the Symfony2 framework and the most proven and scalable technologies available. If you have an in-house team that helps support your Drupal properties, we have already started on custom training programs that will help further assimilate your organization to Drupal 8. This will be particularly critical for retaining developers that want to learn Drupal 8's cutting-edge technologies.

3. Lead the charge for web accessibility. Statistics show that up to 20% of the global population is affected by some form of visual, hearing, cognitive, or motor disability. Now is the time to make your organization’s web presence accessible to all users. Drupal 8 has adopted standards like HTML5 and the Web Accessibility Initiative’s Accessible Rich Internet Applications Suite (WAI ARIA) that are critical for disabled users to have a positive experience.

4. Be an innovator. Open-source software continues to revolutionize the technology industry. Mediacurrent wants to help you stay ahead of your competition, some of whom are still using outdated, legacy based content management platforms that charge licensing fees. Knowledge is power.

5. The future is now with D8. The international Drupal community only supports the two latest releases of Drupal. This means that if your site is on Drupal 6 (or an earlier version) the modules used to maintain your site will eventually be deprecated.

Our team at Mediacurrent has hundreds of years of collective Drupal experience. We are passionate about supporting our customers. Let’s continue the conversation and assess how Drupal 8 aligns with your strategic planning.

Additional Resources 
The Great Drupal 8 Debate | eBook 
Manhattan Associates Drupal 8 Redesign | Case Study 
Intro to Drupal 8 Vocabulary | Blog Post
Drupal for Marketers Part 1 and Part 2 |Blog Post 

Oct 07 2015
Oct 07

Today, we announce Drupal 8.0.0 RC1, the first Drupal 8 release candidate. It's a very exciting milestone, and one that has taken a lot of hard work, long nights, weekends, and extreme commitment from our community. I appreciate the dedication of everyone involved, and understand what it takes to give up personal time in pursuit of building something greater. So, for that I want to thank you.

In total, Drupal 8 has had more than 3,200 contributors and 15,000 committed patches. The good news is, we've finally reached the day when Drupal 8 has hit zero release-blocking bugs and is ready for takeoff!

Historically, the adoption of Drupal has roughly doubled with each new release. We expect no different from Drupal 8, a release I believe positions Drupal most strongly for the future. We've undergone some big architectural changes to get more people using Drupal, and to prepare ourselves for the future. I can't wait to see what the community does with Drupal 8. It's time to start building!

Drupal rc1
Oct 07 2015
Oct 07

Drupal 8 is now available as a release candidate (RC). An RC is like a sneak preview you can use. It's not a final release—that’s coming soon, and there may be another release candidate before then. But its code and interface should feel stable now. You can install it, start designing for it, create and build with it, and extend and improve it. That means you can start putting Drupal 8's more than 200 new features and improvements to work today.

Get Drupal 8 RC1

A first look at Drupal 8's features

With Drupal 8, the world's best content management framework just got better. Every built-in theme is responsive. Every single component is translatable out of the box. More elements have configurable fields and there are new field types for better content modeling.

It’s built people-first. The authoring experience is better, with features like in-context editing and enhanced previews. It's easier to add people-friendly meaning via native schema.org markup. There's extensive support for accessibility standards.

Drupal 8 also has all the geekery you can Git. All-new configuration management (full exports, easier transitions between environments) means safer, faster site development and maintenance. REST-first native web services enable 3rd-party integrations. And adding Twig is the most complete transformation of Drupal theming in a decade. It allows friendlier syntax, better security, and a separate presentation layer.

Organizations are using Drupal 8 now

There are thousands of Drupal 8 installations already up and running. Goal Gorilla, Amazee Labs, Gravity R&D, and DrupalNorth joined drupal.com as some of the earliest Drupal 8 adopters. France Télévisions, Memorial Sloan Kettering Cancer Center, and CH2M have chosen Drupal 8 too. The list of sites built with Drupal 8 is growing and growing.

Companies and organizations around the world rely on Drupal 8 right now. Your organization could be next. Have questions before getting started? Check out answers to some frequently asked ones, and read the RC’s release notes.

Feedback welcome

Sharing feedback is important. It's part of the open source spirit. It's what pushes the Drupal community forward. And it's what will get Drupal 8 from RC to a full version release. If you find bugs while using this RC, let the community know.

To join the social conversations about this RC, use #drupal8rc. To mention and find conversations about work already made with Drupal 8, use #madewithd8.

A great big thank you

This RC wouldn't have been possible without our community. Its contributions, its diligence, and its patience created something special. To everyone who’s helped and will help, even if you're not in the Drupal 8 hall of fame, thank you.

Drupal 8: make something amazing, for anyone.