YAML is a data serialisation format that is both powerful and easy for us humans to read and understand. In Drupal 8 it's used where Drupal needs a list but doesn’t need to execute PHP. One of the reasons why YAML was chosen for Drupal 8 is because it is already used in Symfony.

In this blog post I will provide an example of a method I use to deploy changes on the projects that I work on my own time. This method is very useful when there is a need to make a lot of manual changes to the site when there is a new release. You could use this method to automate deployment process of your Drupal sites. In fact this method can be used for any other non-Drupal sites too.

For this blog post I am using Drush commands.

Lets start form a very simple example. I will use Acquia's directory structure to descibe where I am storing release scripts.

Before jumping into the release blog post I wanted to repond to the recent Drupal Planet blog posts about the fact that Drupal 8 has so few themes. In my opinion the short answer is: Drupal 8 adoption is very slow.

The slightly longer answer is that Drupal also faces more competition in the lower end of the market, where themes are most often used. WordPress' growth has been great and is now stagnating, but online site builders like Wix, Weebly, and squarespace are growing and their products are maturing. Another factor that I think relates to Drupal 8's slow adoption especially in the lower end of the market is that Drupal 8 will rely more on distributions due to increased complexity of assembling a fully featured site. As someone who manage a Drupal distribution full time I can tell you it's not as easy as it should be.

Glazed 2.5.3 Release

Today we release what is just the start of a new class of Drupal themes. Over the past year our Glazed theme and Carbide Builder combo has stabilized and proven it's capabilities. With our latest Landscaping Theme Demo we are showing that our framework theme is capable of so much more than your average Multipurpose WordPress theme or Bootstrap template. With refined design options and microinteractions we are pushing our Glazed framework theme forward to make way for a future full of beautiful, effective Drupal theme designs. New header options were added, our main menu system got some improvements.. 

TL;DR

• Added pull-down header design
• Improved overlay menu style
• Support for transparent and full-width menus
• New minimalistic form theming
• New design for portfolio pages
• Image Compare 
• Lightbox Gallery for portfolio pages
• Next / Previous node pager
• CHANGELOG Glazed Theme
• CHANGELOG Carbide Builder

Glazed Landscaping Theme

As you can see on our roadmap SooperThemes is currently focussing on designing a large collection of Business niche themes based on our Glazed framework Drupal theme and Carbide Drag and Drop Builder. Our most recent addition is Landscaping and Gardening theme. We are not in the business of designing generic niche themes, we aim to release the best niche themes. We developed additional features for this theme including a unique new header and main menu design, an image comparison widget and a lightbox gallery option for portfolio pages. 

Check out the Landscaping & Gardening live demo to view our latest niche theme!

New Header Options

While designing new niche theme I quickly realised that our generic bootstrap navbar layout was the most important bottleneck preventing us from producing truly great niche business website designs. The Glazed Settings for the header were refactored, optimized and extended with new style options and 11 new color options. These options are now also made available in our Glazed Content Design field collection so that you can customize headers for specific landing pages and match your creative content. 

You can now view all these header in our live demo under the new Headers Dropdown menu!

Image Compare, Lightbox and Portfolio Page Design

For a landscaping business it's important to showcase your best work to potential customers. The portfolio content type was extended with additional layout options. New features include a Next / Previous node pager at the bottom, an advanced lightbox gallery system for viewing portfolio images and last but not least: an image comparison widget. The comparison widget really makes your case studies stand out, providing an effective and fun way to demonstrate the awesome service your business provided to your customer.

The comparison widget is touchscreen compatible and responsive. 

New Form  Design & Theming

The default Bootstrap 3 forms already started looking dated. We replaced it with a minimalistic new design. Forms now blend in perfectly with any design. Form elements are sublty colored only when interacted with. The selectbox now features are custom themed dropdown icon that is themed using the default font that you configured in Glazed Settings. The selectbox also sports are a subtle microinteraction animation when hovered.

The Landscaping contact form uses the webform bootstrap 3 layout module.

Looking Ahead

In the future look forward to more Drupal Niche Business themes, as well as our move into Magazine themes. WordPress magazine themes have seen a surge in sales on themeforest recently and I think there is oppurtunity for Drupal to shine in this growing market. After all, Drupal is naturally best at managing large amounts  of structured content and magazines are just that. Combine that with the capability of our drag and drop builder to easily generate attractive creative content and there you have a basis for best-in-class magazine themes. If you are interested in joining our little theme shop you can join now for just $48.

In many cases, uniting routing with admin path definition makes things easier, but not when it comes to Views because their routes are generated dynamically. The solution I have come up with is to use a RouteSubscriber.

There is a lot of literature about entities and their purpose in Drupal 7 context. Most of it has been adopted in Drupal 8 as well. In this post, I'll highlight the differences between D7 and D8 entities and how to use the entity API in 8.

Entities have their own classes in 8. Also, Drupal 8 introduces the concept of config entities. These are used to store user-created configuration if its more than a piece of text, boolean or integer. They differ from the usual entities in the following ways:

• The are not revisionable
• The don't support entity translation interface(TranslatableInterface), but can still be translated using config's translation API.
• The don't have fields/are not fieldable.

The rule of the thumb is, any information pertaining to the structure and functionality of the site(image style, content types, filters), how content is being served(views, display modes) etc. are config entities.

Secondly, the data storage mechanism moved from being field-centric in 7 to entity centric in 8. This implies that all fields attached to an entity share the same storage backend, making querying a lot easier.

Entity validation is a separate API based on Symfony's validator component. This can be availed when adding entities through other means(ex. programmatically creating an entity instance) than by using user facing forms. Entity validation will be the demonstrated in another future post.

Creating and loading entities

To create a new entity object, use the entity_create. NOTE that this only creates an entity object and does not persist it.

$node = entity_create('node', array(
  'title' => 'New Article',
  'body' => 'Article body',
  'type' => 'article',
));

If you know what the entity class name is, you can use it directly.

$node = Node::create(array(
  'title' => 'New Article',
  'body' => 'Article body',
  'type' => 'article',
));

Entities can be loaded using similar functions, entity_load and <class_name>::load.

$node = entity_load('node', $id);

// same as above
$node  Node::load($id);

Entity save is done by calling the instance's save method.

$node->save();

Save works for both creating and updating an entity. An entity can be checked if it's being created for the first time using the isNew method.

use Drupal\node\Entity\Node;

  $data = file_get_contents('https://www.drupal.org/files/druplicon-small.png');
  $file = file_save_data($data, 'public://druplicon.png', FILE_EXISTS_RENAME);

  $node = Node::create([
    'type'        => 'article',
    'title'       => 'A new article',
    'field_image' => [
      'target_id' => $file->id(),
      'alt' => 'Drupal',
      'title' => 'Drupal logo'
    ],
  ]);
assert($node->isNew(), TRUE);
$node->save();
assert($node->isNew(), FALSE);

entity permissions can be checked using the access method.

$node->access($op);
// where $op is one of "view", "create", "update" or "delete"

Reading and updating entities

Entity properties can be modified using the set method.

$node->set("title", "A newer title");
$node->save();

Reading and updating entity fields follows a similar pattern to Entity Metadata Wrappers in 7, albeit more object oriented. Fields can be read as follows:

use Drupal\node\Entity\Node;

// text field
$node = Node::load(4);
$txt = $node->field_my_text->value;

// entity reference
$node = Node::load(3);
$tags = $node->field_tags->referencedEntities();

// link field
$uri = $node->field_my_link->uri;
$title = $node->field_my_link->title;
$options = $node->field_my_link->options;

The $tags contains all the term objects associated with that field.

Updating a text field is easy.

$node = Node::load(4);
$node->field_my_text = "updated text";
$node->save();

To update a node and add a set of terms,

use Drupal\node\Entity\Node;
use Drupal\taxonomy\Entity\Term;

$node = Node::load(4);
$term1 = Term::load(1);
$term2 = Term::load(2);
$node->field_tags->setValue([$term1, $term2]);
$node->save();

Link fields can be updated as follows,

// specific attributes can be updated.
$node = Node::load(4);
$node->field_my_link->uri = "https://lakshminp.com/writing-custom-authenticator-drupal-8";
$node->save();

// the whole field can also be updated.
$node = Node::load(4);
$node->field_my_link = ["uri" => "https://lakshminp.com/", "title" => "My Blog", "options" => ["target" => "_blank"]];
$node->save();

Entity field query in D8

Entity field query has been essentially rewritten in Drupal 8. It helps fetching entities which match given criteria without writing any SQL queries. Here's a simple query to fetch all published nodes of type article.

$query = \Drupal::entityQuery('node');
 $query->condition('status', 1);
 $query->condition('type', 'article');
 $entity_ids = $query->execute();

The $query query object is chainable, just like entity field query and returns an object of type QueryInterface. It is possible to query fields.

$query = \Drupal::entityQuery('node')
  ->condition('status', 1)
  ->condition('field_tags.entity.name', 'Chennai');
$nids = $query->execute();

We can give different comparison operators too.

$query = \Drupal::entityQuery('node')
  ->condition('status', 1)
  ->condition('field_my_link.uri', 'lakshminp.com', 'CONTAINS');
$nids = $query->execute();

You can specify a field delta value between the field name and column name, as in:

$query = \Drupal::entityQuery('node')
  ->condition('status', 1)
  ->condition('field_tags.1.entity.name', 'Mumbai');
$nids = $query->execute();

will fetch all the nodes whose 2nd tag name is "Mumbai".

It is possible to specify OR conditions and chain them.

$query = \Drupal::entityQuery('node')
  ->condition('status', 1);

$group = $query->orConditionGroup()
  ->condition('field_tags.entity.name', 'Mumbai');

$nids = $query->condition($group)->execute();

fetches all nids which are either published or have "Mumbai" in tags.

These nids can be further processed after fully loading the entity objects using entity_load_multiple.

// ...
$nids = $query->execute();
$nodes = entity_load_multiple('node', $nids);
foeach($nodes as $node) {
  //do something
}

• Drupal
• Drupal 8
• Drupal Planet

It's been a while since I've written a post here (especially, Drupal-related). But today I have something interesting to share.

There's a module called Search API sorts (https://drupal.org/project/search_api_sorts) that provides custom sorts and a global sort block for Search API. The module itself is ok, but ...

Read now

Top 5 Takeaways From Dublin DrupalCon brandt Mon, 10/10/2016 - 20:55 Alex Brandt Oct 11, 2016

Dublin DrupalCon: Community, Sessions, Guinness, and Toast.

In this post we will cover...

• What we learned in Dublin

• Some of our favorite events

• Why we’ll be back next time

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

We’ve settled back into our routines, but we are still left with the warm afterglow of another DrupalCon. Palantir’s Tiffany Farriss, George DeMet, Ken Rickard, and Avi Schwab reflect on their time in Dublin and share their thoughts on what makes DrupalCon so special in our top 5 takeaways.

5.) The Drupal community is bright and ambitious.

• Avi: I’ve been working as a FED on projects lately. This DrupalCon gave me a great opportunity to reinforce and grow my existing Twig knowledge, now that I have some real places to apply the skills. The trio of “Branch out of your comfort zone…”, “Drupal 8 Theming In Depth”, and “21 Things I Learned…” is enough to get anyone from zero to Twig hero in no time.
• George: I was only at DrupalCon for a couple of days, but during that time I had a lot of great conversations with people in the community. I heard a lot of great ideas for how we can help make Drupal contribution more sustainable, and how we can make it easier for more people to engage with the project and the community in different ways.
• Tif: Of late, I’ve been thinking about how Drupal can better communicate its community values and expectations at the organizational level (to and among the business ecosystem). Central to that is the question: what does it mean to be a good Drupal citizen whether you’re an individual, an organization or an end user of Drupal? I had some excellent conversations around that topic and am excited about the possibilities for recognizing all of the wonderful work that already happens within the community as a way to communicate and reinforce our community values.

4.) There’s always something to look forward to.

• Avi: The Drupal Association team always works hard to put on a great event, but I feel like Dublin went more smoothly from a logistical standpoint than any DrupalCon I’ve been to. The venue staff assisted the volunteers at a phenomenal level, the venue itself was amazing, and the food was great.
• Tif: I love reconnecting with old friends and making some new ones, and having thought-provoking conversations (especially with Kristof Van-Tomme, my friend and CEO of Pronovix).
• Ken: DrupalCon is a great combination for me, in that I can always expect to run into old friends, and I am also guaranteed to meet new contributors. That makes it a special event.

3.) Yet, we’re always pleasantly surprised with what’s different.

• George: Now that Drupal 8 has been out for some time and people are building sites with it, this DrupalCon felt more focused on the community. The new Being Human session track in particular had a lot of great content aimed at helping people learn how to contribute in a healthy way while also supporting others.
• Avi: I’ve gone through some personal changes since NOLA, but for me Dublin felt much more like DrupalCons from our pre-D8 days, where developers dug into the hard problems and worked to share their solutions. It’s refreshing to be back in that seat both personally and as a community. D8 is moving along well and now has the confidence of most folks in the community, and we’re really putting it to work.
• Tif: It’s remarkable how much the Drupal community has matured and expanded since my first DrupalCon Europe in Szeged in 2008.

2.) The sessions and events only reinforce how special the Drupal community is.

• George: I very much appreciated Dries’ focus in his keynote on the core values and purpose (http://buytaert.net/drupal-collective-purpose) of the Drupal project and community, which set a really great tone for the event. Being able to see and hear how Drupal has made a positive difference in the lives of people all over the world was particularly inspiring.
• Avi: After a few years of doing more PM work and less development, it was great to come back to Con and be able to absorb so much incredible knowledge from such great people. I also really enjoyed the Tuesday night party on the Cill Airne — too often our socializing is overpowered by loud music and tight spaces, but having a night outside, with a good bar and good folks, but not so much screaming, was greatly appreciated.
• Tif: I always enjoy the Driesnote. Dries’ expanded purpose for the project (that Drupal is as much about people and impact as it is about code) resonates with me and affirms that Drupal continues to be aligned with Palantir’s purpose and values.
• Ken: I went to Tim Millwood's session on the Workflow Initiative. That's the Drupal 8 core project that includes moving Workbench Moderation into core as Content Moderation. In many ways, it's the culmination of work that we started at the end of the Drupal 6 development cycle, so it's very rewarding to see the progress being made today.

1.) It wouldn’t be DrupalCon without a few shenanigans.

• Avi: At the boat party, upon learning that I was a Palantiri, an Irish admirer of his began expounding on Mr. Ken Rickard’s amazing, deep, Hollywood-like voice and how, despite Ken’s contextual configuration talk being incredibly interesting, just listening to the words come from Ken’s mouth made it that much better.
• Tif: I got Angie (webchick) to try Guinness: https://twitter.com/gdemet/status/780865264598523905.
• Ken: We shared an apartment with Avi’s family. Avi's daughter Calliope tried to put buttered toast into everyone's pockets at the breakfast table every single morning. (I guess to save for later.) Which led to the viral quote. "No, you can't put toast in my pockets. I don't have any pockets."

We want to make your project a success.

Let's Chat.

• Community
• Drupal
• Events
• People

I had the opportunity to assist to Drupalcon Dublin 2016. Some insights and highlights on sessions I assisted on this Drupalcon.

Dublin is a lovely city, very international and The Convention Centre Dublin was an excellent location. Dries keynote was less enterprise oriented than others and helps to understand where he wants to take Drupal8. The most interesting thing for me is to see how the new life cycle of D8 roll-out is. There was more about D8 new development cycle on the session "Drupal 8's rapid innovation promises".

A few years ago, we published a very popular post called "How to Create Dropdown Menus in Drupal".

That post covers many of the basic points that have not changed in Drupal 8, including these:

• Many themes don't have dropdown menus built-in. That includes Drupal's core themes, such as Bartik.
• It is best to choose a theme that does already have dropdowns available.
• You need to go to Structure > Block layout and make sure your menu is placed in the correct block region.
• You need to go to Structure > Menus and make sure your menus links are indented.  

Drupal is open source sofware. Thousands of contributors help build it, but of similar importance is the marketing and education wing of the Drupal Community. Drupal Twitter accounts, Drupal podcasts, and today's topic: Drupal Blogs.

There are many, many blogs that are of importance to various aspects of Drupaling. My criteria are really just my own non-authoritative views. Please feel free to Tweet me, Facebook me, or throw in your own ideas in the comments below!

Breeze is a design that we make available as a Joomla template and a WordPress theme. Now, finally, it's available as a Drupal 8 theme!

We use Breeze as an example in many of our video classes and books.

By using the same design, it makes it easy for OSTraining members to see differences and similarities between the various platforms.

Breeze is fully responsive and uses the Bootstrap framework.

Drupalize.Me trainer Amber Matz attended this year's Open Hardware Summit in Portland and reports back on what she took away from the event.

10/10/2016Testing Software - A Quick Overview

Software is an ever changing interweaving of collections of ideas expressed in code to solve various problems. In today's day an age the problems that software is solving is expanding at an ever increasing rate.

Palantir.net's Guide to Digital Governance: Ownership Palantir.net's Guide to Digital Governance brandt Mon, 10/10/2016 - 12:37 Scott DiPerna Oct 10, 2016

This is the third installment of Palantir.net’s Guide to Digital Governance, a comprehensive guide intended to help get you started when developing a governance plan for your institution’s digital communications.

In this post we will cover...

• Why ownership is the cornerstone of good governance
• What ownership entails
• How to manage instances of shared or collaborative ownership 

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

Now that we have defined all of the digital properties and platforms that we will consider for our Governance Plan, we next need to establish who “owns,” or who will ultimately be responsible for the care, maintenance, and accuracy, of these properties.

Ownership is the cornerstone of good governance. In fact, some may think of ownership as being synonymous with governance. From my experience, I believe that good governance of any digital communications platform involves more than simply defining who is responsible for each piece.

In most organizations, many people are using, sharing, and collaborating on the same systems together. The processes and interactions between those users needs to be defined as well, however we have to identify the people before the process. Defining ownership first is the foundation on which we can begin to define the more complex relationships that exist in a shared system.

Ownership is the cornerstone of good governance…. Defining ownership first is the foundation on which we can begin to define the more complex relationships that exist in a shared system.

I should make one other important distinction between maintenance of the system and the maintenance of the presentation of content, as it relates to ownership.

Since this Governance Plan is considering the guidelines for digital communications, it is explicitly NOT considering the roles, policies, and procedures for the maintenance of the infrastructure that supports the properties and platforms we are considering for the plan.

In other words, when we define who has ownership of the public website or the intranet, we are considering only the content and its presentation – not the underlying software and hardware that makes the website or intranet functional.

Perhaps this is obvious, but it is an important distinction to make for those who are less familiar with modern web technology, who may not fully understand where the functions of an IT department end and an Online Marketing or Communications department begin.

With those caveats out of the way, we can now begin to define who is responsible for each of the properties and platforms we listed earlier.

Obviously, I can’t tell you who is or who should be responsible for each piece within your organization – that must be defined by how your work responsibilities are distributed across the institution – but I can describe some general principles for defining ownership that should help.

• Ownership of your organization’s web presences ultimately should reside at the very top, with levels of responsibility being delegated down the hierarchy of the institution.
• The top leadership of an organization should be responsible ultimately for the accuracy and maintenance of the content contained within the parts of the properties they own.
• Every website, subsite, microsite, department site; every section and sub-section; every page, aggregated listing, and piece of content all the way down to each video, photo, paragraph, headline, and caption should fall within the ownership of someone at the top.
• Responsibility for daily oversight and hands-on maintenance of those properties then may be delegated to staff within the owner’s groups, offices, or areas of responsibility.
• Owners should have sufficiently trained staff who have the authority and capacity to make changes, corrections, and updates to the content as needed in a timely manner, such that inaccurate and/or outdated content does not remain on the property for an unreasonable period of time.

In short, ownership has two essential aspects:

1. top-level responsibility for the accuracy and efficacy of the content, and
2. hands-on responsibility for the creation and maintenance of the content.

Both are essential and required for good governance, and very likely may be responsibilities held by one person, split between two, or shared among a group.

Shared Ownership / Responsibility

There may be instances in which shared ownership may be necessary. I generally recommend against doing that as it puts at risk a clear chain of accountability. If two people are responsible, it’s easy for both to think the other person is handling it.

If some form of shared ownership is required, consider having one person be the primary owner, who is supported by a secondary owner when needed; or that a primary owner is a decision-maker, but secondary owner(s) are consulted or informed of issues and pending decisions.

If “equally” shared ownership or responsibility is required, try defining the exact responsibilities that are to be owned and dividing them logically between the two. Perhaps there is a logical separation of pages or sections. Or maybe one person is responsible for copy, while another is responsible for images.

Shared ownership is less-than-ideal, but there can be reasonable ways to make it work, provided you do not create any structural gaps in authority, unwittingly.

Collaboration

There are many instances in digital communications where groups of people collaborate to produce content. This is most common with organizational news and events, publications, blogs, social media, etc.

For example, if there is a single person who can be ultimately responsible for all blog content created by various content creators, great! If blog content is created by subject-matter experts from different fields or different parts of the organization, perhaps it is possible to invest ownership in one person for all of the blog posts within a specific subject for each field.

If you are in a situation similar to what I described above, where you have multiple, subject-specific owners, it will probably make sense for all of the owners to meet regularly to agree on standards and best-practices for all contributors to follow.

In the end, the fundamental concept here is to place responsibility for all content and every part of a digital property with the people who are in the best position to manage it and ensure its quality, accuracy, pertinence, and value.

 

This post is part of a larger series of posts, which make up a Guide to Digital Governance Planning. The sections follow a specific order intended to help you start at a high-level of thinking and then focus on greater and greater levels of detail. The sections of the guide are as follows:

1. Starting at the 10,000ft View – Define the digital ecosystem your governance planning will encompass.
2. Properties and Platforms – Define all the sites, applications and tools that live in your digital ecosystem.
3. Ownership – Consider who ultimately owns and is responsible for each site, application and tool.
4. Intended Use – Establish the fundamental purpose for the use of each site, application and tool.
5. Roles and Permissions – Define who should be able to do what in each system.
6. Content – Understand how ownership and permissions should apply to content.
7. Organization – Establish how the content in your digital properties should be organized and structured.
8. URLs – Define how URL patterns should be structured in your websites.
9. Design – Determine who owns and is responsible for the many aspects design plays in digital communications and properties.
10. Personal Websites – Consider the relationship your organization should have with personal websites of members of your organization.
11. Private Websites, Intranets and Portals – Determine the policies that should govern site which are not available to the public.
12. Web-Based Applications – Consider use and ownership of web-based tools and applications.
13. E-Commerce – Determine the role of e-commerce in your website.
14. Broadcast Email – Establish guidelines for the use of broadcast email to constituents and customers.
15. Social Media – Set standards for the establishment and use of social media tools within the organization.
16. Digital Communications Governance – Keep the guidelines you create updated and relevant.

We want to make your project a success.

Let's Chat.

• Strategy

Drupal Commerce was started without writing any Drupal code. Our libraries set Drupal Commerce off the island before Drupal was able to support using third party library not provided by core.

Drupal now ships without third party libraries committed, fully using Composer for managing outside dependencies. However, that does not mean the community and core developers have everything figured out, quite yet.

YNACP: Yet Another Composer Post. Yes. Because as a co-maintainer of Drupal Commerce we're experiencing quite a lot of issue queue frustration. I also want to make the case of "let's make life eaiser" for working with Drupal. As you read compare the manual sans-Composer process for local development and remote deployment versus the Composer flows.

Before we begin

We're going to be discussing Composer. There's specific terminologies I'll cover first.

• composer.json1: defines metadata about the project and dependencies for the project.
• composer.lock2: metadata file containing computed information about dependencies and expected install state.
• composer install3: downloads and installs dependencies, also builds the class autoloader. If a .lock file is available it will install based off of the metadata. Otherwise it will calculated and resolve the download information for dependencies.
• composer update4: updates defined dependencies and rebuilds the lock file.
• composer require5: adds a new dependency, updates the JSON and .lock file.
• composer remove6: removes a dependency, updates the JSON and .lock file.

All Composer commands need to run in the same directory as your composer.json file.

Installing Drupal

There are multiple ways to install Drupal. This article focuses on working with Composer, for general installation help review the official documentation at https://www.drupal.org/docs/8/install

Install from packaged archive

Drupal.org has a packaging system which provides zip and tar archives. These archives come with all third party dependencies downloaded.

You download the archive, extract the contents and have an installable Drupal instance. The extracted contents will contain the vendor directory and a composer.lock file.

Install via Composer template

A community initiative was started to provide a Composer optimized project installation for Drupal. The Drupal Composer project provided a version of Drupal core which could be installed via Composer and a mirror of Drupal.org projects via a Composer endpoint (This has been deprecated in favor of the Drupal.org endpoint).

To get started you run the create-project7 command. 

composer create-project drupal-composer/drupal-project:8.x-dev some-dir --stability dev --no-interaction

This will create some-dir folder which holds the vendor directory and a web root directory (Drupal.) This will allow you to install Drupal within a subdirectory of the project, which is a common application structure.

This also keeps your third party libraries out of access from your web server.

Review the repository for documentation on how to use the project, including adding and updating core/projects: https://github.com/drupal-composer/drupal-project.

Adding dependencies to Drupal

Without Composer

Modules, themes, and profiles are added to Drupal my placing them in a specific directory. This can be done by visiting Drupal.org, downloading the packaged archive and extracting it to the proper location.

There's a problem with this process: it's manual and does not ensure any of the project's dependencies were downloaded. Luckily Composer is a package and dependency manager!

With Composer

To add a dependency we use the composer require command. This will mark the dependency, download any of its own. 

Note if you did not use project base: Currently there is no out of the box way to add Drupal.org projects to a standard Drupal installation. You will need to run a command to the endpoint.

composer config repositories.drupal composer https://packages.drupal.org/8

Let's use the Panels module as an example. Running the following command would add it to your Drupal project.

composer require drupal/panels

This will install the latest stable version of the Paragraphs version. If you inspect your composer.json file you should see something like the following

"require": {
  "drupal/panels": "3.0-beta4",
}

One of the key components is the version specification. This tells Composer what version it can install, and how it can update.

• 3.0 will be considered a specific version and never update.
• ~3.0 will consider any patch version as a possible installation option, such as new betas, RCs.
• ~3 will allow any minor releases to be considered for install or update.
• ^3.0 will match anything under the major release — allowing any minor or patch release.

You can specify version constraints when adding a dependency as well. This way you can define of you will allow minor or patch updates when updating.

composer require drupal/panels:~3.0

This will allow versions 3.0-beta5,3.0-rc1, 3.0 to be valid update versions.

Know what! The same versioning patterns exist in NPM and other package managers.

Updating dependencies

Without Composer

As stated with installing dependencies, it could be done manually. But this requires knowing if any additional dependencies need to be updated. In fact, this is becoming a common issue in the Drupal.org issue queues.

With Composer

Again, this is where Composer is utilized and simplifies package management.

Going from our previous example, let's say that Paragraphs has a new patch release. We want to update it. We would run

composer update drupal/panels --with-dependencies

This will update our Drupal project and any of its dependencies. Why is this important? What if Paragraphs required the newest version of Entity Reference Revisions for a critical fix? Without a package manager, we would have not known or possibly updated.

Why we need --with-dependencies

When Composer updates a dependency, it does not automatically update its dependencies. Why? No idea, apparently the maintainers do not believe it should.

Updating Drupal core

Without the Composer template

If you installed Drupal through the normal process, via an extracted archive, you have to manually update in the same fashion. You will need to remove all files provided by Drupal core — *including your possibly modified composer.json file*.

Rightly so, you can move your modified .htaccess, composer.json, or robots.txt and move them back. However, you’ll need to make sure your composer.json matches the current Drupal core’s requirements and run composer update.

That’s difficult.

The official documentation: https://www.drupal.org/docs/7/updating-your-drupal-site/update-procedure...

Updating Drupal core via the Composer template

If you have setup Drupal with the Composer template or any Composer based workflow, all you need to do is run the following command (assuming you’ve tagged the drupal/core dependency as ^8.x.x or ~8, ~8.1, ~8.2)

composer update drupal/core --with-dependencies

This will update Drupal core and its files alongside the drupal-composer/drupal-scaffold project.

Using patches with Composer

I have been a fan of using build tools with Drupal, specifically  using Drush and makefiles to manage Drupal platforms. However, when I first used Composer I was concerned on how to use patches or pull requests not yet merged with the project — without maintaining some kind of fork.

Cameron Eagans create the composer-patches  project. This will apply patches to your dependencies. The project’s README fully documents its use, so I’ll cover it quickly here.

Patches are stored in a patches portion of the extra schema of the JSON file.

  "extra": {
    "patches": {
      "drupal/commerce”: {
        "#2805625: Add a new service to manage the product variation rendering": "https://www.drupal.org/files/issues/add_a_new_service_to-2805625-4.patch"
      }
    }
  }

This patches Drupal Commerce with a specific patch. 
   

Using GitHub PRs as a patch

Patches are great, as they let you use uncommitted functionality immediately. A problem can arise when you need code from a GitHub pull request (or so it seems.) For instance, Drupal Commerce is developed on GitHub since DrupalCI doesn’t support Composer and contributed projects yet.

Luckily we can take the PR for the issue used in the example https://github.com/drupalcommerce/commerce/pull/511 and add .patch to it to retrieve a patch file: https://github.com/drupalcommerce/commerce/pull/511.patch

We could then update our composer.json to use the pull request’s patch URL and always have up to date versions o the patch.

  "extra": {
    "patches": {
      "drupal/commerce”: {
        "#2805625: Add a new service to manage the product variation rendering": "https://www.drupal.org/files/issues/add_a_new_service_to-2805625-4.patch"
      }
    }
  }

When working on Drupal 8 theming, it is very helpful to have Twig debug mode on. Debug mode will cause twig to emit a lot of interesting information about which template generated each part of the page. The instructions for enabling debug mode can be found within the comments of the default.services.yml file, among other sources. In short, all you need is the following in your services.yml file:  

In little over a month Drupal 8 will be one year old. To mark this momentous occasion Dries Buytaert, Drupal’s founder, will champion noteworthy web sites and applications powered by Drupal 8.

Have you launched a Drupal 8 web site or application this year? Dries would like to hear from you. We’ve prepared a short web form so you can tell him your Drupal 8 success story.

Please spread the word

To reach the widest potential audience and capture the very best examples I encourage your to share this blog post with colleagues, peers, clients. Please email, share on social media, speak to your clients.

Beyond the Drupal shops developing applications our objective is to attract submissions from end users using Drupal 8. If you represent an organisation, enterprise, SME, startup, manufacturer, government department (and more) using Drupal 8 we want to hear from you.

So tell the world, complete the short form and help us celebrate Drupal 8.

Deadline for submissions is November 11th.

Last week I had the opportunity of visit Paris, France for a week as para of my tour Around the Drupal world in 140+ days.

Sadly for me, I got a #drupalflu in Drupal Con, Dublin; So I wasn't in the best shape to enjoy the city.

I want to say thank you to Sebastien Lissarrague and his family for allowing me to stay with them in their home.

During my visit, I had the opportunity to participate in the local Drupal Meetup of Paris community.

Also, I visited some companies like Koriolis, Sensio Labs and Platform.sh.

At Koriolis I have the opportunity to show the owner and developers the Drupal Console project to accelerate the Drupal 8 adoption in their projects.

During my visit to Sensio Labs I had a session with part the Symfony Core development team, to show them how we have been using the Symfony Console in Drupal Console project.

During my visit at Platform.sh I learn I little bit how they enable to their Drupal 8 user the usage of Drupal Console project. Next week I will write an articule about that.

About the city, I think anything that I could say about Paris will be nothing compare how beautiful it's; I just could recommend you to visit three mandatory places in you visit.

Eiffel Tower

Louvre Museum

/Palace_of_Versailles

Airplane Distance (Kilometers) Dublin , Ireland → Paris, France → San Jose, Costa Rica 9.957 Previously 96,604 Total 106.561 Walking Distance (steps) Dublin 116.133 Previously 1.780.955 Total 1.897.088 Train Distance (Kilometers) Today 0 Previously 528 Total 528 Bus/Car Distance (Kilometers) Today 0 Previously 2.944 Total 2.944

Leapfrog the Drupal Learning Curve & Architect the Perfect Solution in 3 Simple Steps Steve Purkiss Sun, 10/09/2016 - 14:06

"Drupal has a steep learning curve" is something I hear time and again, however I feel this is a misguided perception and something we need to work towards changing - especially now focus is on the adoption journey. Learning how to 'Drupal' is actually incredibly easy - the trick is to understand exactly what Drupal is and how to mould it to your needs - this is what I'm going to show you how to do in three simple steps.

Step 1: Discover what Drupal doesn't know

This is by far the most important step of the process, hence why I go into much further detail than the other two - skim if you so wish but I assure you the story is there for a reason!

We've been here before

As of writing, Drupal has been around for 15 years and has solved many problems associated with building a wide range of web sites and applications, embedding this knowledge in either the core Drupal distribution or one of the 35,000+ modules available on the drupal.org site. Drupal's decision to only provide backwards-compatibility for content and not functionality means this functionality has had the ability to improve over time and make the most of innovation in technology, for example the recent big jump from mostly procedural programming to object-oriented.

A note about the jump from procedural to object orientation

This latest jump was a big one - Drupal was developed before object orientation was available in PHP (the language Drupal is written in), and so developed its own system of 'hooks'. You use hooks to interact with Drupal core to override functionality in order to make Drupal do what you want it to do for you. You can think of hooks like the ones on a coat stand - the trouble here was as different modules and themes overrode hooks, like an overloaded coat stand with many different coats on each hook, it became increasingly harder to work out what hook was changing what and when in the process it was changing it.

There are still hooks in Drupal 8, but these may disappear in future versions of Drupal as the migration to object-orientation continues. An added benefit is more backwards compatibility than before for future versions, so the change between versions 8 and 9 shouldn't be as pronounced as the change from 7 to 8 as we don't have to perform again such a big move as changing the fundamental way the entire code works. I believe there's plans to support backwards compatibility over two major versions from now on, so 9 will be backwards compatible with 8, 10 with 9, but not 10 with 8 - YMMV, etc.!

Knowledge carried throughout generations

Courtesy @sgrame: https://twitter.com/sgrame/status/774232084231680000

The key point to understand here is what Drupal brings along with it as it progresses from version to version. Whilst the underlying code may change in order to improve and make the most of the latest innovation in programming languages, the knowledge, experience, and best practices gained and shared from its deployment to millions of sites is maintained in the API and module layer. It is unlikely what you are trying to build is unknown to Drupal in some way or another, it has dealt with everything from simple brochureware sites which look the same to everyone to sites such as weather.com where everyone who visits sees a personalised version of the site. As I often like to quip, I've never been asked for Rocket Science and even if I was, NASA uses Drupal ;)

This development process is fundamentally different to how other systems on the market work, with many other popular ones focusing on ease of use at the expense of progressive innovation, and is why you see Drupal have a larger share of the market on sites with complex requirements. The adoption of semantic versioning means there are now minor releases which include bug fixes along with both new and experimental functionality, and a new version of Drupal is released every six months. We are already up to version 8.2, and with current focus on 'outside-in' it is becoming easier for people used to systems other than Drupal - or none at all - to use Drupal, however it is not easy to visualise your end goal and know how to get there, or there is a module or modules already out there which could help you along the way to achieve your desired outcome without having to code anew.

To help overcome this out-of-the-box experience there are many ongoing initiatives to provide default content, make module discovery easier, build focused distributions, etc. but they will all take time. There is a way to approach development which means you don't end up going down the wrong path or developing functionality which already exists, it is to discover what exactly it is you want to build Drupal doesn't already know about and focus only on functionality required which is specific to your situation and no other.

What makes you different?

I recently provided the architecture for a high-profile specialist travel site - a six-figure project which unfortunately as with many projects I'm involved in I'm under non-disclosure agreements, doesn't mean I can't talk about the approach I took though, and this is a particularly good example.

As they were merging a number of existing systems I could've just looked at the existing data, however there is nothing to say those systems were designed well and we don't want to fall into the trap which I see many times where people re-create bad systems. Drupal is a very flexible system, many others require you to fit your data into how they work. So by asking the client to explain how their organisation worked and what was different about themselves as opposed to other similar organisations I discovered there were six distinct areas:

1. Activity - their offerings were split into distinct activity types
2. Resorts - they operate their own resorts
3. Accommodation - each resort contains one or more different types of accommodation
4. Region - the organisation had their own definition of a region, some spanning more than one country
5. Departure Gateways - they fly out from a limited number of airports
6. Arrival Gateways - resorts are serviced by one or more local airports

Everything else on the system was something Drupal would have dealt with before in one way or another - number of rooms, features of accommodation and resorts, and so on. These could easily be achieved using fields, taxonomy terms, and everything else Drupal provides out-of-the-box.

Design with the future in mind

I also took the time to observe the operations of the organisation as I walked around their office. I noticed the majority of people were answering calls, so I asked what exactly they had to deal with on the phone - people wanting more information on particular deals, issues with accommodation crop up from time to time - all the usual a travel company would have to deal with but more so here as they owned and operated the resorts. The point here is there's a whole wealth of user requirements contained here which although weren't in the scope of this current phase of development, by having them in mind when designing a system it should make it easier to extend to accommodate their needs as and when budgets and time allow.

If you only design a system for buying via the web you may find when a member of staff is trying to help a customer on the phone the process is unnecessarily complicated, or extending the system to cope with this new use case is particularly hard if you haven't taken this scenario into consideration to start with. Not to say it can't be done, and is easier to adapt now Drupal 8 is more object-oriented, but it's always good to have the future in mind - some of this you will be able to see, some you'll need to extract from key stakeholders, you'll be surprised sometimes with what you find out which you'll then be glad you asked. Here I knew the latest version of Commerce for Drupal 8 has the ability to set up different buying processes so it would be able to cope easily with phone orders if it were ever a requirement.

Design for different rates of change

It is feasible I could've used Drupal's built-in content types to build the system, but this would've limited the system to this particular use-case, making it harder to cope with different buying processes like the one mentioned above. It also did not sound right - an "airport" isn't a content type, it's an entity. It has content - facilities etc. but the thing itself is an entity. So I created six custom entities, and it sounded much better especially when you went to create a view - "list accommodation in resort". By simply teaching Drupal what was different about this particular organisation, we extended Drupal's "knowledge" and leveraged everything else it had to offer to deal with the functionality it does know about, like date ranges, durations, prices, and so on.

Whilst the front-end of a website may go through many enhancements and refreshes, the core business model of an organisation - especially one such as this which is well-established and operated for many years, does not change as much, if at all. In this example they mentioned they may add new activities, and they offered packages which covered more than one activity but their current system couldn't cope with this, which is why activity was treated as a separate entity.

By encoding the core business model of an organisation as high up the chain as you can with Drupal, you end up with a far more flexible system to cope with the faster-moving changes such as views to list out particular promotions, plus ensure longevity by enabling future development of those core parts of the system. I also wanted to make it a little more difficult for them to change any of this as this is critical to the operation of the organisation, so if changes were needed they would have to go through a harder process than changing a view, but there should be a good reason for any changes needed to the core business model so happy with the custom entity approach taken.

Seeing the wood for the trees

It's not only when architecting systems you need to take this approach to Drupal - another small example is when I helped someone out a couple of weeks back who was having problems getting a product listing displaying exactly how he wanted it to using Drupal 7. He had tried a number of different types of views (Drupal's user interface for manipulating database queries) but none of them would do what he wanted, which was to provide a faceted search facility, listing the results grouped by category. You'll see this functionality on most e-commerce sites these days, for example click on Televisions and it'll provide you a list grouped by manufacturer, or perhaps size - the point is it's not Rocket Science, it's been done before, it shouldn't be hard to do, so something else was causing the issue here. Sometimes it's hard to see the wood for the trees, so you need to take a step back and take a logical think about the situation.

We delved into the problem and through a series of questions worked out the thing he wanted to do which was different was he wanted a number of fields to be displayed at the group level - the name of the group, an image, and a description. None of the various combinations of views he had tried provided the ability to display more than one field, and rewriting the field output in the view did not apply to group by fields. Although there are a number of ways to achieve this from different parts of Drupal, I implemented the simplest way I knew which was to output the taxonomy term ID as the field to group by, and overwrite the template in order to load the details of the taxonomy term so we could easily grab the fields we needed.

I can almost hear others screaming at me to use display modes or some other functionality available as I'm sure there's other ways this can be achieved which are 'better', however as I spend most of my time dealing with back-end issues and not front-end and as we only had limited time and budget to solve the issue, this worked as a solution for the situation at hand so we went with it.

The take-away here is to go with what solves the majority of the problem, the thing you see or can imagine seeing other people using, and focus on what is specific to your needs. Faceted searching, listing products, grouping products by category - all standard functionality and should be simple to achieve in Drupal. Outputting multiple fields for a grouping category title? Not so much.

Step 2: Modularise Your Requirements

Drupal is a modular system, so you need to modularise your requirements by breaking them down as much as you can. Yes, what you're wanting to do has more than likely been done before, but maybe not in your exact combination - if it has then cool, you don't have to do anything as there's already a module/distribution/theme/etc. out there for you! Many times there isn't though, and every organisation has their differences, so you need to break your requirements down in order to deal with them successfully.

In our example above where we have a faceted search listing out products grouped by category, by splitting it up into "faceted search", "list products", and "group a view by category" we are going to get much better results when searching for answers than if we search for "faceted search grouped by taxonomy", which is more specific to our use-case than the majority of uses. You're more likely to end up with someone else's specific situation who also has had issues solving it and may forever skip past the actual solutions you are looking for. Be as generic as you can with generic requirements, then be as specific as you can with the ones you identified as particular to your situation, in this example we could've searched for "override view field output" and it would've brought us results for how to override using views templates, which is how we solved the problem there.

Once you align your vocabulary more closely with Drupal's generic, modular functionality, you'll enjoy much more success with your searches - it takes a little logical thought and remembering it's not Rocket Science! Far too many times I've seen sites where little or no research has been done as to what's already out there and people have essentially forked Drupal, creating their own monster significantly increasing the amount of work it takes to maintain and extend the site when it's not necessary.

Every line of code you produce is technical debt - even if you decide not to use the module you find which does what you need or part of what you need, you can study the tried-and-tested code, copy it into your module and use as a base for your work. A good example is detailed in my previous blog post about creating a Drupal Console command where I found code which did some of what I wanted so I based my work on it because I knew what had already been written worked and there was no point in me writing it again.

Step 3: Only Develop Specifics, Share Where Possible & Grow Drupal!

If you find you have to develop specific functionality for your site, have a think about if it would be of use to anyone else, or whether you're going to be the only person in the world doing this specific thing. As mentioned above, every line of code you write is something you or your client is going to need to support your/themselves. If you publish a module to the drupal.org module repository you not only have the possibility of others sharing the maintenance of the code but they may also provide enhancements, and stable module releases are covered by the security advisory policy which doesn't mean they secure your module, but if an exploit is found and reported the 40+ strong Drupal Security Team are there to help. Even if you just create a sandbox project you may discover others find the code useful and provide feedback.

If you're working for a client and they are worried about sharing code, or you're the end client and worry about losing competitive advantage, remember software is easy to copy and it's the rest of what you do which sets you apart from your competition. In our travel example above, it's the resorts they own which provide the value to the customer, not the software code which enables people to book a stay in them.

Currently there is a lack of sharing code on the implementation side - there's a lot of factors for this including competition between suppliers, infrastructure ease of use or lack thereof, and a general lack of co-operation in some industries. The result is many people end up writing similar code when they could be starting at a higher level, collaborating with industry peers, sharing development and maintenance costs, and going towards pushing the Drupal project forward. The more we can do out-of-the-box, the better it gets for all concerned as projects cost less, launch quicker, and we can focus on code which isn't out there already which is specific to the organisation itself, so spending the development budget on genuinely useful code instead of code which could be freely available to us in the first instance. Remembering how much we started with for free may be of help creating impetus to share any code we develop.

Although my site here doesn't do much functionally I haven't had to write a single line of code to be able to use the web to communicate my message to you, something I believe is amazeballs! Drupal can and does provide code for generic websites, however it's up to industries to collaborate and build their modules and distributions, and/or some enterprising people to build code and distributions for them, as we see in some areas such as e-learning and government.

I'm honestly shocked when I hear projects haven't contributed any code back, especially larger projects lasting longer than a year - I worry about how much technical debt they've incurred and feel sorry they haven't helped Drupal to grow, it's only by contributing code the Drupal product itself has reached this amazing level of innovation. I understand there are reasons, however I never see it as "contribution", more akin to riding a bicycle - I can stare at it as long as I like but until I push my feet down on the pedal it's not going to take me anywhere, I don't call it "contribution", just how the bike works!

I hope this post has been of help, do feel free to comment below, or get in touch with me if I can be of help with anything specific.

Happy Drupaling!

Main Drupal 8 Learning Curve image courtesy @sgrame. Other images attributed inline, the rest are public domain, found on pixabay.

Category Tutorials

Tags

• Drupal Planet
• Drupal Architecture
• Data modeling
• drupal

Add new comment

Let's imagine a scenario where you need to display some data from a remote service to the user. Instagram, for example. You want to grab the 6 most recent posts, pass them through some theming, then output them into a block. How would you go about doing that? In Drupal 7, one possible approach might look like this.