Author

Apr 30 2017
Apr 30

In his keynote at DrupalCon Baltimore 2017, Dries talked for some time about how Drupal is now for Ambitious Digital Experiences. There has been a lot of talk over the last few years, especially since Drupal 8 was release, that Drupal is now an enterprise CMS. With this keynote it seems as though Dries is, in a way, acknowledging this. Ambitious Digital Experiences reads as, something more complex than a blog, a brochure site, or sites for SMEs.

With this in mind, and recent discussions about the Future of Drupal, maybe it's time to put together a sort overview of where we are and what we have in Drupal.

Drupal 8 took nearly 5 years to develop and had over 4,000 people contribute code to it. There are now 11 core committers for Drupal 8, with a further 3 committers tasked with Drupal 7. Listed in MAINTAINERS.txt are over 60 subsystem maintainers who oversee the development of parts of Drupal known as "subsystems".

When downloading Drupal 8 the majority of the code sites within the core directory, and from there is split into a number of distinct parts. There are 22 Drupal components, which are independent libraries and don't depend on anything else within Drupal, there are all available via github. On top of are over 70 base subsystems, these may depend on components or other base subsystems, but don't depend on any modules. Finally there's over 70 modules, 5 themes, and 2 profiles, these may depend on any other parts of Drupal core. From these modules there are 12 that are (or were) experimental, experimental modules are here to add new functionality into core for testing purposes, but not yet fully supported.

The documentation for Drupal core is pretty awesome, and well worth a read for those looking for more information on the governance, "gate", or development workflow.

Apr 29 2017
Apr 29

Direct .mp3 file download.

Join Chris Weber, Ted Bowman, Kelley Curry and Mike Anello discuss the goings-on at Day 2 of DrupalCon Baltimore. Music: We'll Get the Hard Part Done Tonight (Hamilton Parody)

Apr 29 2017
Apr 29

Direct .mp3 file download.

Join Kelley Curry, Ryan Price, Liz Lipinski, Dan Schiavone, Kevin Lannahan, Lakia Newkirk and Mike Anello discuss the goings-on at Day 1 of DrupalCon Baltimore. Music: Drupalcon Baltimore (to the tune of Good Morning Baltimore) from the Prenote.

Apr 28 2017
Apr 28

Add Rules action Assign Contact to Group
Add Rules action Remove Contact from Group
Add Integration for IM entity
Add Integration for Website entity
Add integration for Contribution Recur
Add rules event for CiviCRM Price Set Field 'After Successful CC Transaction'
CiviCRM Price Set Field , improved support for price fields with multiple checkboxes
Fix issues with CiviCRM Core Contribution Recur Views integration
Enable CiviCRM Entity Reference field on parent entity 'add', Inline Entity Form Single widget, for Contacts
Expose civicrm_world_region table to Views

Views Relationships:

  • Membership -> Membership Payment
  • Participant -> Participant Payment
  • Participant Payment -> Participant
  • Explicit Relationship from Address -> Country
  • Country -> World Region

Overhaul of CiviCRM Entity Inline, inline entity form widget FAPI generation and handling
Minor but fixes for CiviCRM Entity, CiviCRM Price Set Field, CiviCRM Entity Discount, CiviCRM Entity Reference Field

Apr 28 2017
Apr 28

As part of the Drupal Workflow Initiative we have critical issue relating to Content Moderation and translations. This is not actually a Content Moderation issue, but is just surfaced by Content Moderation because it allows you to create forward revisions. The video here should explain the issue:

[embedded content]

Forward revisions + translation UI can result in forked draft revisions and Only having one default revision per entity forces translations to be kept in sync are the related core issues.

Apr 28 2017
Apr 28

Entities have been introduced late in Drupal 7. Drupal entity is an instance of a particular instance type. For example, the entity type for taxonomy terms is named taxonomy_term and the class name Term. We include the class like  Drupal\taxonomy\Entity\Term. Here taxonomy is a core module name, and Term is the class name of Entity.

A. How to create an user programmatically.

The fields to be created are as follows:

  1.  Username
  2.  Email address
  3.  Password
  4.  Status
  5.  Roles
  6.  Picture
  7.  Timezone

If you want to create a Drupal user programmatically we can create it the way as given below:

a) This is the first method

  The output is shown below:user create

The use of Drupal\user\Entity\User; is to  include the class User.

User::create()is used to create an user where it takes the details about the user.

Here name is the username whose account is to be created.

Here mail is the email id of the user and pass is the password for the user.

The status tells you if the user account is active or blocked. If it is 1 then the user account is active and if it is 0 then the account is blocked.

The roles mention which roles is given to the user. To give the user more than one role simply pass an array of roles.

The timezone mentions a timezone set for the user.

The user_picture accepts the image’s file id to get the user image. To get the file id we have passed a static image here in $file_image='/var/www/html/drupal/sites/default/files/2017-04/images.jpeg'; The file_get_contents() reads a file into a string. $directory is the name of the folder where you want to save the uploaded image. file_prepare_directory($directory, FILE_CREATE_DIRECTORY); The above line creates the folder if it doesn't exist. The file_save_data saves the files details. The first parameter takes the file content, the second parameter takes the name of the folder you want to save your image and the name of the file, the third parameter tells you to replace the file if it already exists.

b) This is the second way to create user  

The first parameter of entity_create accepts the entity type that we want to create and the second parameter accepts an array of values to be used to create that entity. The user created is saved to finally create the user.

B. How to create a node programmatically

If you want to create a drupal node programmatically we can create the way as given below:

a) This is the first way to do this:

node create

 This will be the output.

Here the use \Drupal\node\Entity\Node; is used to insert the class Node.

Node::create() is used to create a node.

Inside Node::create() the node details is passed.

The type tells you the content type whose node is to be created.

The title is the node title, body is the body part of a node.

The field_mail is the email id to be entered if you have a field for email.

The field_link allows you to add a link if you have any link field and field_date holds the value of date field.


 

b) This is the second way to create the node   

  The entity create function takes two parameter where the first parameter tells you which entity to create and the second parameter should be an array of the node details. 

 

C. How to create a taxonomy term programmatically

If you want to create taxonomy term programmatically we can create the way as given below:

a) This is the first way to create term

  The output is shown below:

term create

   In above code use Drupal\taxonomy\Entity\Term; is used to insert the class Term

  Term::create has been used to create the term where Term is the class name.

  Here name and vid are machine names where name represents the name of the new term you want to create, and vid is the name of the taxonomy term whose term you want to create.

b) This is the second way to create a term 

The entity create function takes two parameter where the first parameter tells you which entity to create and the second parameter should be an array of the term details.

 It should contain term name and the taxonomy name whose term you want to create. You can add the term description but it’s optional.

D. How to create a custom menu

Create a form inside the Form folder as given in the code below.In Drupal 8 modules we write a form inside a Form folder.

Create a routing file which is module_name.routing.yml  Here menu.route is the routing name and _form is the path of the form. 

In module_name.links.menu.yml file write the code for the menu as shown below:

  links.admin is the name of the menu.

The title will appear as the menu name.

The parent tells you the place where the menu will be created like system.admin will create the menu in the main navigation. If the parent is not mentioned then the menu will be created in the tools.

  The route name is the name of the routing file of whose menu you want to create.

The output is as follows.

menu

  Here TechX is the menu created.

E. How to create a custom permission

 Taking the example of the module above, create a file and name it as module_name.permissions.yml

  Write the following code into it:

 Here 'Menu permission': is the name of the permission that we mention in the routing file ,

 The title gives you the name displayed in the drupal's permissions page. In routing file under _permission we mention this permission name. So whichever role has this permission can view the form.

This is how drupal permissions are given to a particular page when you don’t want to show the page for every user or role.

So here we have learnt how to create entities in drupal 8 programmatically. In drupal 8 you can create node, user, taxonomy without code, but sometimes due to various project requirements and we need to create these programmatically.

Apr 28 2017
Apr 28

Every few years at DrupalCon, a new theme sweeps through the community. It’s a conceptual theme—a motif, a forward-looking glimpse into the future (not the kind with a .info file). The topic tends to dominate conversations and fill sessions. People have varying ideas of how to best approach the new frontier.

When I first began attending DrupalCons in 2011, I remember the hype about responsive websites: the difference between responsive and adaptive layouts, which grid system to use, and how to best add and target classes to efficiently apply media queries.

In 2014, there was a natural and communal shift in interest to Drupal 8’s frontend. Twig was the new kid on the block and everyone wanted a taste. Developers aimed to learn the new syntax and eagerly compared the new D8 techniques to their tried and true D7 counterparts.

This year at DrupalCon Baltimore, the hot topic has been headless Drupal. Decoupling Drupal’s frontend has been buzzed about for years, but in the past it seemed to be just that—a buzz word—a conceptual, potentially problematic, but exciting idea. Today, on the last day of DrupalCon, it’s clear developers are not just buzzing anymore, they’re building headless Drupal sites and loving it. Amazee Labs is building headless Drupal sites and loving it.

Amazee’s history with headless Drupal is a complicated one. In fact, our own Michael Schmid pointed out during his and Brandon’s React, GraphQL and Drupal session, how Amazee Labs was both skeptical and dismissive of the decoupled/headless vision when the idea initially emerged. In the last quarter of 2016 however, Amazee’s stance on headless changed. I’d encourage you to review Michael and Brandon’s Wednesday session for a deeper explanation as to the reasons behind that shift. 

Technology is a rapidly changing thing and always will be. As developers, it’s natural to feel more or less acceptance towards some changes than others. As a frontend developer who’s grown to master and enjoy working in Drupal’s theme layer, the shift to headless is a tough pill to swallow. I’d equate the sensation to experiencing some kind of loss—there’s a kind of mourning for all the hard, long hours put into building expertise in a complex, yet rewarding theme system. I’ve grown to love Twig, transforming Drupal’s notoriously bad markup into something simple and semantic, and creating truly beautiful Drupal experiences “the old fashioned way.”

Dries published an article Tuesday during the conference, Drupal is API-first, not API-only. In the post, he discusses the benefits of preserving the coupling between Drupal’s front- and back- ends, at least in part. His summary on headless CMSs has validated many of the thoughts I have regarding a fully decoupled Drupal. There are reasons to remain coupled, reasons to go headless, and reasons for a middle-of-the-road approach.

We are certainly future-looking at Amazee Labs. As a company, we are committed to enhancing our team’s skills and providing clients cutting-edge solutions. My takeaway from DrupalCon Baltimore is to embrace and learn new skills required to build innovative headless frontends while simultaneously working to improve and educate others on Drupal 8’s theme layer. The best of both worlds. Let me hear from you, fellow frontend Drupal devs—what’s your take?

Apr 28 2017
Apr 28

Don’t panic! If you don’t use Content Moderation- and Layout Plugin-based components (like Display Suite, Panels, Panelizer and Contexts) then you’ll be fine upgrading to Drupal 8.3. If you do, there are just a few things you need to know first.

“It looks insanely complicated, and this is one of the reasons why the snug plastic cover it fitted into has the words Don’t Panic printed on it in large friendly letters.” – The Hitchhiker’s Guide to the Galaxy

One of our Drupal 8 projects relies on the core experimental module Content Moderation. The module has been partially re-written with Drupal 8.3, becoming dependent on the new core experimental module Workflows, so we decided to put some effort into updating to this latest minor version and studying all the changes.

An initial upgrade path workflow

We’ve been aware of Content Moderation changes for a while, thanks to the change record “Experimental Workflows module added to core”, circulating since the beginning of the year. The section on “Important upgrade information” was as scary as it was useful: “you will need to uninstall it before updating the codebase and re-install after”. And of course, “as this is an ALPHA experimental module data upgrade paths are not supported”.

We decided to experiment with what the best upgrade path would have been for our scenario, and came up with a pretty strong workflow:

  • Put website in maintenance mode.
  • Approve/Reject all the content waiting for approval. The only allowed states are Published or Draft/Unpublished. This is because after uninstalling Content Moderation, Published and Unpublished are the only states Drupal will recognise.
  • Delete content_moderation_state entities (/admin/modules/uninstall/entity/content_moderation_state).
  • Uninstall Content Moderation and dependencies, if any.
  • Upgrade Drupal codebase to 8.3 latest version.
  • Run database updates.
  • Re-install Content Moderation and dependents, if any.
  • Re-create the moderation States and Transitions from the new Workflow based UI. If you use the same name machines, you probably don’t need to update any of your custom code or views.
  • Restore the website, disabling Maintenance Mode.

After doing this, you check some random pages… and you notice something is wrong.

What’s the problem?

Visiting one of your content types’ custom display modes, made with Display Suite, may show you some fields have been disabled (they’ve either been moved to the Disabled region, or they’re missing altogether)!

Or you may notice your custom Layout theme suggestions are not loaded for your Panels.
Shame on you. You haven’t read the other 8.3 Change Records, nor the full 8.3.0 release notes.

Layouts, layouts everywhere…

The Layout Plugin contrib modules, used by modules like Display Suite and Panels, has been dropped. Instead, we have the Layout subsystem and a new experimental module, Layout Discovery, in core.

The reason for this is to unify the way contrib and custom modules (and themes) can define their own layouts, and enable them to reuse layouts created with all the modules implementing the Layout API. Putting it in core is an incentive for doing it once and doing it well.

Both Display Suite and Panels suggest using brand new branches with Drupal 8.3 (as now they both make use of the new Layout subsystem). Though apparently, you could still use your original versions, with a bit of custom effort/code. It doesn’t work for me no matter what I do, as most of the fields are still missing on my display modes which are managed through a Display Suite layout.

Let’s update those modules

Display Suite needs to be updated to version 3.0 or higher, Panels and Page Manager to 4.0 or higher. Running database updates will uninstall Layout Plugin contrib and install the Layout Discovery core module replacement, enabling the new Layout subsystem.

The Display Suite issues queue is full of people experiencing problems at this point of the process. Missing Fields, Fields in the wrong regions or Disabled, Fields settings reverted to default values. The guys are doing a wonderful job of trying to fix the bugs, and explain the best solutions for a full recovery.

DS 3.0-beta3 contains most of these fixes, and restored most of my fields and settings.

You’ll still need to review ALL your form and view display modes, because here or there, there could still be glitches.

In my scenario, I have six content types and around four custom display modes for each, so it took me around an hour to re-configure all the fields in the right way. For this reason, I do suggest going through this review process in a staging environment, before exporting the configuration and re-importing it in Production. Much quicker and safer.

Dude, where’s my layout?

You may notice that something still looks weird on a Panel or when viewing content. You think it might be related to the template, and then you remember that that specific node type or page uses a custom template, through a template suggestion.

The file is there, twig debug tells you the suggestion is on the list and so should be considered, but the file is not loaded. This is a bug (and there is already an issue for it).

Layouts used in Display Suite displays should not be affected by this bug as long as, when you define the layout on your mytheme.layouts.yml, you set the class property to ‘\Drupal\ds\Plugin\DsLayout’.

i.e.

custom_1col_hero:
  label: Custom one column layout with hero (fixed)
  category: Custom
  template: templates/layouts/custom-1col-hero
  class: '\Drupal\ds\Plugin\DsLayout'
  regions:
    hero:
      label: Hero
    main:
      label: Main
    footer:
      label: Footer

This is a workaround made for and by Display Suite. For websites using any other Layout-based contrib modules like Panels, there’s currently no solution, other than patching the core codebase.

Conclusion

The big lesson here is about contrib modules: updating core to the new version is a requirement for developers and site-builders. But forcing websites to use the unstable branches or experimental modules is as problematic as it is dangerous. Unstable code is, by definition, unstable, possibly unsecure and isn’t easy to update.

Implementing new features and surfing the new trends is essential for staying relevant. But to do that, site owners should really be given the option of choosing between stable and experimental modules.

Here are some useful links to more info:

Apr 27 2017
Apr 27

I presented Just Keep Swimming! Or, how not to drown in your open source project at DrupalCon Baltimore 2017, as part of the Being Human track. Below is a text summary of the presentation (along with the associated slides).

(I will also add a link to the video of the presentation once it's finished uploading.)

Just Keep Swimming - Slide 2

Hi, I'm Jeff Geerling, known most places around the Internet as geerlingguy. I've been involved with the Drupal community for almost nine years, and the Ansible community for four. I work for a company named Acquia, one of the largest Drupal service providers, and I write a lot (mostly about open source software), and automate a lot of things (mostly using Ansible).

Just Keep Swimming - Slide 3

I do a lot of open source work. I maintain over 160 independent open source projects on GitHub, and help with a few others. Some of these projects are pretty tiny, but there are a number with hundreds or thousands of stars, and thousands of issues, commits, and pull requests.

My biggest claim to fame is that I'm the highest ranked open source contributor in St. Louis. That's gotta count for something, right?

Just Keep Swimming - Slide 4

But my open source work is just one small part of my life. I'm also a husband and father of three kids—a four year old, a two year old, and a six month old. In this picture, you can witness one of the common rituals in the Geerling household (those of you who don't have kids might be wondering what I'm holding): the changing of the diaper pail. Between dealing with toddler meltdowns, activity time, changing diapers, and family game nights, family is an important part of my life. A lot of the reason I do the work I do is for my family: I want to make sure my children have the tools and time to do more than I could imagine to make the world a better place. Family is extremely important, and other things in my life often take a backseat to family matters.

Just Keep Swimming - Slide 5

I also spend as much time as I can taking pictures and exploring photography. Before I decided to work in software development full-time, I was splitting my time between development and photojournalism, and I still take on a few paid gigs every year. This year, in fact, I'm taking pictures in a semi-official role as a volunteer photographer at DrupalCon (you may have seen me sneaking around with this massive camera!).

Just Keep Swimming - Slide 6

I also enjoy DIY projects: in this picture, contrary to what you may be thinking, I am not building a meth lab. I was building the home office in which I've been working for Acquia. I work on projects around the house, I help neighbors with their own projects, and I even enjoy light gardening—even though almost all my perennials seem to die every year.

Just Keep Swimming - Slide 7

Finally, something that impacts me on almost a daily basis is my Crohn's disease. It's a chronic, but not fatal, disease, and I've been dealing with it since 2003. This picture is from about six months ago, when I had major surgery to remove part of my gut. Even then, I was thinking about Drupal, ha!

I'm doing pretty well today (thanks for your concern!), and having to deal with the ups and downs of Crohn's disease has really made me feel thankful for the times when I can be productive (in work, in family time, and in open source), and more importantly it is a constant reminder that you never know what someone else is going through, so I know it's important to always treat others with compassion and assume the best intent.

Just Keep Swimming - Slide 8

The point is, I'm a human. I have human needs and desires. And the same for all of you. All open source maintainers, contributors, and users come together and bring their own relationships, experiences, and struggles to the table.

Often, when someone is struggling in life, open source work (often being one of the less important aspects) is the first thing to go. That's a major reason why all open source maintainers have a constant battle with burnout. Once open source work becomes a struggle and a burden, it no longer rewards maintainers with doses of optimism and euphoria that sustain their involvement!

Just Keep Swimming - Slide 9

This chart shows the time I spend doing various things through the day. It's not a ranking of importance, just the amount of time spent, on average, doing each thing. I spend almost all my day either working (that's the W-2 section), sleeping, or being present to my family. Then there are some things like eating and reading (or, let's be honest, binging on Netflix or Reddit!). Then there's the last slice, accounting for about 1.5 hours a day, that I choose to devote to Open Source work.

Most open source maintainers are in the same boat. Most of us aren't paid to work on our open source projects during work hours (though sometimes we're fortunate enough to be able to devote some time to them), and most of us have only a small amount of time to devote to open source work. So it's important that we use that time well, and focus on tasks that don't drag us down and make us dread the work. We have plenty of W-2 work during the day like that!

Just Keep Swimming - Slide 10

So I'm going to show you what that small slice of open source work looks like, on an average day.

Just Keep Swimming - Slide 11

I often start my time glancing at my 'open source' email folder.

Just Keep Swimming - Slide 12

YIKES, that's overwhelming! Well, maybe I'll change gears and just focus on my GitHub issues.

Just Keep Swimming - Slide 13

Hmm...

Just Keep Swimming - Slide 14

This constant barrage of notifications can be really jarring. It's probably best to ignore the common notifications, and find a way to filter out issues that are not as important or wouldn't be a good use of your time.

Let's jump into an issue queue and find a pull request or patch to review.

Just Keep Swimming - Slide 15

Nice! It looks like I stumbled upon a rare breed of GitHub pull requests: this PR has the four hallmarks of a pull request likely to be merged:

  1. There is a thorough description of the why behind the PR, how it works, and even a link to find further information! This makes it so I don't have to spend my hour researching the code changes—the contributor already did it for me.
  2. This PR doesn't change everything under the sun. It's only adding a few lines of code, which means I will likely be able to review it quickly (certainly in less than 1 hour).
  3. The commit history looks clean. There's one commit with a short message describing the changes.
  4. The PR passes all the project's automated tests (so I know at minimum it doesn't break my project's existing functionality).

Just Keep Swimming - Slide 16

What a great way to kick off my open source time! If all the issues are like this one, I'll probably get through at least five or ten issues today!

Just Keep Swimming - Slide 17

... But then reality hits us. Very few issues, patches, and pull requests are so easy to resolve.

Just Keep Swimming - Slide 18

These examples highlight one of the most prolific issue types that will clog up your queues. Weeks go by with no response from the person who opened the issue, and you have no recourse but to close the issue with no definitive resolution.

Well, let me introduce you to some common issues and some characters you may run into:

Just Keep Swimming - Slide 19

These are Ghost Writer issues. A Ghost Writer is when the OP (Original Poster) disappears off the face of the planet, never to be heard from again. These clog up every major project's issue queues, and take a lot of time away while maintainers prune these dead issues out of their issue queues.

Just Keep Swimming - Slide 20

The next kind of issue I see more often than I'd like is by someone who apparently doesn't see the documentation, known as the See No Docs issues. When the OP asks a question that's answered in the first section of the project's documentation! And alongside are the Read No Docs issues (when the maintainer links to documentation but it's obvious the user didn't read them before replying again), and the Fix No Docs issues (when the issue mentions a small bug or improvement in the docs, but nobody ever files a patch).

Just Keep Swimming - Slide 21

Then there's the Iceberg issues. These are issues that look like they'll require only minimal effort to resolve, but once you get into them, you realize you just burned up a week's worth of your time trying to resolve the issue! There's a lot more to the issue hidden under the water.

Just Keep Swimming - Slide 22

Next up, you know that person who prods you to merge an old patch that passes automated tests but you haven't merged for some reason or another?

Just Keep Swimming - Slide 23

That's a 'For Shame'er. These comments are often unintentionally insidious; they usually have a slightly passive-agressive tone, and if you're not careful as a maintainer, these can really tear down your confidence. Most of us suffer from the Imposter Syndrome already, and when we see these comments, it makes us feel potentially more inadequate as a maintainer!

I'm not saying that bumping or +1'ing an issue is necessarily wrong. Rather, if you want to add your 2¢, please either stick to a "+1" comment, or make sure your statement doesn't have any passive-agressive undertones!

Just Keep Swimming - Slide 24

And then there's the Dung Heap. These issues are pretty easy to identify, and if you're like me and you're ruthless in cleaning up your issue queue, they don't stay long. Dung Heap issues are those that contain little or no description, hundreds or thousands of lines of changed code, don't follow your project's coding style, and often fails to pass automated tests.

There's no way you should consider merging these; just close them quickly and move on.

Just Keep Swimming - Slide 25

Closely related is the Diamond in the Rough: it's mostly a Dung Heap, but there is one change in the patch or pull request which is actually really good. Enough so that you don't want to close the issue, and you give the OP feedback asking to remove all the unrelated changes and resubmit.

But it seems these issues are often combined with a Ghost Writer (the OP never responds), and then after a month or two, you start getting a few 'For Shame'ers asking why this obviously brilliant change hasn't been merged yet.

Just Keep Swimming - Slide 26

There's also the Imposter. These issues are ones that have no real relation to your project. Instead, it's a poor lost soul who knows you've helped them in the past, so they post an issue only tangentially related to your project, hoping you'll answer their question out of the kindness of your heart.

Just Keep Swimming - Slide 27

And finally, the Black Hole. These issues start off unassumingly, with a simple premise and maybe a straightforward path to completion. But then someone suggests changing a variable name. Then, three hundred comments later, after the variable name is back to the original one, it seems there is no end in sight. Black Holes most often devolve into a Bikeshed, where people are arguing more over a variable name or a code comment than the actual change itself!

Just Keep Swimming - Slide 28

Whether or not you have kids, there's a chance you've heard of Dory, a Disney/Pixar character who has issues with short-term memory, but is a faithful companion and optimist. Dory offers us this simple advice: when your issue queue gets you down, you need to just keep swimming!

Just Keep Swimming - Slide 29

Let's not drown in our issue queues. Instead, I'm going to talk about some of the things that I do when managing all my projects. I hope you'll find some of these things helpful!

Just Keep Swimming - Slide 30

One thing that is often overlooked, but in some ways fairly important in increasing uptake and continued usage is to inject some personality in your project. If your project has some amount of personality, it can make both you and your users like and remember it better.

One example is the 'Raspberry Pi Dramble' logo (the one with the six Druplicons in the shape of a raspberry). After making the logo and sticking it on the Pi Dramble website, I started to approach the project differently. I tried to simplify some things and make the videos and documentation for it more approachable. It's a subtle change, but I think it's important. (Case in point, the venerable Druplicon.)

Another example is Drupal VM: I first created it as "A Drupal Development VM", but that name didn't really roll off the tongue well, was really long, and didn't endear users to the project. Once it got more popular, I took some time to:

  1. Rename the project to, simply, "Drupal VM" — no "The". This made Drupal VM a proper noun, and also affected the language around the project.
  2. Create a wordmark and use it consistently.

It's very hard to relate to projects that have no personality, and especially when things are rough, it's a lot easier to abandon something if it has no personality, no branding, no identifying marks.

This isn't to say branding is everything—but it definitely helps guide people's perception, and your own too!

Just Keep Swimming - Slide 31

Next up: Work in the open. I actually had a great example of this at a BoF yesterday—I was talking about a problem I encountered with Drupal but didn't know if an issue had been filed about it. Someone mentioned that an issue was in the Core issue queue, and when I opened it up and scrolled down, I had the most recent comment on the issue, from two months ago!

There are a number of benefits that come from documenting things as you go, and from blogging—or at a minimum, storing your thoughts somewhere public:

  1. You can use Google to search your own brain!
  2. If you start working on something but get stuck, or need to switch gears, someone else can pick up where you left off and push the issue through to completion.
  3. Other people get their own problems resolved by seeing what you wrote. If it stays in your head or in a private journal, chances are nobody (including yourself) will benefit from the work beyond the immediate fix or feature you completed.

Just Keep Swimming - Slide 32

This slide I added just because I'm a Tesla nut.

No, I kid; the real reason is because of something Elon Musk said:

Tesla focuses heavily on designing the machine that makes the machine - turning the factory itself into a product.

Tesla is currently the largest automotive manufacturer in the US (by market capitalization)—even though they produce far fewer vehicles than Ford, GM, Chrysler, and other manufacturers. The reason for this is that people value Tesla's philosophy: automating things and increasing efficiency.

Most open source projects have a very sparse commodity: development time. And wasting development time on mundane, mind-numbing tasks like manual testing, code linting, etc. will quickly discourage potential contributors.

At a minimum, you should have a goal of automating:

  • Code style / linting
  • Functional tests (at least one 'happy path' test to verify things aren't horribly broken
  • First-time setup (how long does it take a new contributor to be able to get a clean environment running your code? Docker can help here!)
  • Notifications and email (e.g. route all OSS email into a specific folder, and don't let those emails show in your 'unread' count)

Additionally, if you find yourself asking for the same extra information every time someone posts a new issue, you can add an ISSUE_TEMPLATE if you use GitHub, and put required information and suggestions inside to ensure people posting issues provide all the right information.

Just Keep Swimming - Slide 33

As your project starts to grow, you'll start interacting with more people: users, potential users, and even (if you're lucky) contributors!

If you want to keep your project maintainable, there are some things you should do to foster your community and distribute responsibility:

  1. Connect with fans: Often there are a few people who are willing to help or at least promote your project. Communicate with them, ask them to help, allow them to take on responsibilities if they seem aligned with your project's goals, structure, etc.
  2. Give karma: Thank contributors in release notes, on Twitter, at events, etc. Open source is a volunteer-driven effort; if money is not available, gratitude is the currency of open source, so give generously and you'll have some passionate users and contributors!
  3. Avoid drama: If you find some controversy brewing in your issue queue or elsewhere, take a step back and see if it quickly resolves itself. If you have to intervene, don't make a knee-jerk reaction, and make sure you're aware of the entire situation. If you don't have a direct role in the drama, my advice is avoid it. And always ask yourself the question: Is what you add going to be helpful?

Just Keep Swimming - Slide 34

I've spoken about a few of the things I find most important in being a happy and sane open source maintainer, but there's a wealth of information on the web on this topic. Almost every maintainer has to wrestle with the problem of staying afloat, and many maintainers put their thoughts into writing.

I'd like to call out GitHub's Open Source Guides especially: these guides are great primers for so many different areas of open source contribution—for maintainers, for contributors, for users, and for businesses.

But what it all comes down to for all of us, is how we use our time. And what I'd ask you to remember is:

Just Keep Swimming - Slide 35

Thank you.

Apr 27 2017
Apr 27

DrupalVM is a tool created by Jeff Geerling that “makes building local Drupal development environments quick and easy” for Drupal. It is built using Vagrant and provisioned with Ansible. Since it uses Ansible, it also provides a means to support a production environment deployment. This allows for a repeatable and determinable environment when developing and deploying to remote servers.

In fact, I currently use DrupalVM to power a Drupal Commerce 2 environment that I run locally and in production. The production environment is updated using continuous deployment via CircleCI. The wonderful roles created by Jeff Geerling and his playbook in DrupalVM handle my production deployment.

Want the tl;dr, skip to bottom for the example.

Setting up DrupalVM within your project

First things first, you’ll need to use DrupalVM. In this example we will add DrupalVM as a project dependency, using Composer. This is important. It ensures that any developer using this project, the CI/CD environment, and the final destination all have the same version of files. It also makes it easier to manage and receive upstream fixes.

For my project I followed Jeff’s blog post Soup to Nuts to configure DrupalVM and setup my DigitalOcean droplet to be my production target. You might want to read that over if you have yet to see how DrupalVM can go to production. I won’t copy those steps here, I’ll show how you can get CircleCI to deploy your DrupalVM configuration to a remote host.

See the article for full details, or my example linked later. For now I’ll do a quick review of some basic config.

The inventory file:

[drupalvm]
192.168.1.12 ansible_ssh_user=drupalvm

The config.yml file:

drupal_domain: "example.com"
vagrant_hostname: "{{ drupal_domain }}"

apache_vhosts:
  - servername: "{{ drupal_domain }}"
    documentroot: "{{ drupal_core_path }}"
    extra_parameters: "{{ apache_vhost_php_fpm_parameters }}"


The vagrant.config.yml file:

# Note, {{ drupal_domain }} overridden for Vagrant to use local.* prefix.
drupal_domain: "local.example.com"
The prod.config.yml file:

drupal_deploy: true
drupal_deploy_repo: "[email protected]:organization/repo.git"
drupal_deploy_dir: "/var/www/drupal"

Those are the only tidbits in my production configuration. I treat the config.yml as primary with specific non-production overrides in vagrant.config.yml.

Adding Circle CI

NOTE! You’ll need to be able to deploy from CircleCI to a remote server, which means adding SSH permissions. With CircleCI you must create a key on your server and give the private key to project configuration.

Okay! So DrupalVM is running, you have accessed your site. Now, let’s run this sucker with CircleCI to do testing and deployment. Create a circle.yml file and let us walk through writing it.

First, we need to specify what language we’re using. In this case, I am using a PHP 7.0 image.

machine:
  php:
    version: 7.0.7

Defining dependencies

Next we want to set up our dependencies. Dependencies are things that we will need to actually run our tests, and they can be cached to speed up future runs. I’ll annotate specific steps using comments within the YAML.

dependencies:
  # Cache the caches for Composer and PIP, because package download is always a PITA and time eater.
  cache_directories:
    - ~/.composer/cache
    - ~/.cache/pip
  pre:
    # Install Ansible
    - pip install ansible
    - pip install --upgrade setuptools
    - echo $ANSIBLE_VAULT_PASSWORD > ~/.vault.txt
    # Disable xdebug (performance) and set timezzone.
    - echo "date.timezone = 'America/Chicago'"  > /opt/circleci/php/7.0.7/etc/conf.d/xdebug.ini
  override:
    # I save a GitHub personal OAuth token for when Composer beats down GitHub's API limits
    - git config --global github.accesstoken $GITHUB_OAUTH_TOKEN
    - composer config -g github-oauth.github.com $GITHUB_OAUTH_TOKEN
    - composer install --prefer-dist --no-interaction

Running tests

Before deploying anything to production or staging, we should make sure it does not deploy broken code.

test:
  pre:
    # Containers come with PhantomJS, so let's use it for JavaScript testing.
    # We specify it to run in background so that Circle CI saves output as build artifacts for later review.
    - phantomjs --webdriver=4444:
        background: true
    # Sometimes the test script can get cranky when this directory is missing, so make it.
    - mkdir web/sites/simpletest
    # User the PHP built-in webserver for tests, also run in background for log artifacts.
    - php -S localhost:8080 -t web:
        background: true
  override:
    # Run some tests
    - ./bin/phpunit --testsuite unit --group commerce
    - ./bin/phpunit --testsuite kernel --group commerce
    - ./bin/behat -f junit -o $CIRCLE_TEST_REPORTS -f pretty -o std

Saving artifacts

In the event that our tests do fail, it would be great to see additional artifacts. Any process that had background: true defined will have its logs available. Adding the following lines will let us access HTML output from the PHPUnit Functional tests and any Behat tests.

general:
  # Expose test output folders as artifacts so we can review when failures happen.
  artifacts:
    # Folder where Functional/FunctionalJavascript dump HTML output
    - "web/sites/simpletest/browser_output"
    # Folder where Behat generates HTML/PNG output for step failures
    - "tests/failures"

Setting up deployment

Now, it is time to tell CircleCI about our deployment process. Nothing too magical here. We are simplify defining that when the master branch passes to run a specific command. This command will load our production config and run the DrupalVM provisioning playbook on our production server. We specify the drupal tags to limit the scope of deployment.

deployment:
  prod:
    branch: master
    commands:
    # Specify DrupalVM environment and fire off provisioning.
    # DRUPALVM_ENV specifies which *.config.yml to load.
    - DRUPALVM_ENV=prod ansible-playbook \
      -i vm/inventory \ 
      vendor/geerlingguy/drupal-vm/provisioning/playbook.yml \
      # Points to directory containing your config.yml files.
      -e "config_dir=$(pwd)/vm" \
      --sudo
      --tags=drupal
      # I exported my Ansible user sudo password to environment variables to make provisioning work.
      --extra-vars "ansible_become_pass=${ANSIBLE_VAULT_PASSWORD}"

If your tests fail then the deployment will not run.

Example

Want to see an example of the full config? See my

Apr 27 2017
Apr 27

DrupalVM is a tool created by Jeff Geerling that “makes building local Drupal development environments quick and easy” for Drupal. It is built using Vagrant and provisioned with Ansible. Since it uses Ansible, it also provides a means to support a production environment deployment. This allows for a repeatable and determinable environment when developing and deploying to remote servers.

In fact, I currently use DrupalVM to power a Drupal Commerce 2 environment that I run locally and in production. The production environment is updated using continuous deployment via CircleCI. The wonderful roles created by Jeff Geerling and his playbook in DrupalVM handle my production deployment.

Want the tl;dr, skip to bottom for the example.

Setting up DrupalVM within your project

First things first, you’ll need to use DrupalVM. In this example we will add DrupalVM as a project dependency, using Composer. This is important. It ensures that any developer using this project, the CI/CD environment, and the final destination all have the same version of files. It also makes it easier to manage and receive upstream fixes.

For my project I followed Jeff’s blog post Soup to Nuts to configure DrupalVM and setup my DigitalOcean droplet to be my production target. You might want to read that over if you have yet to see how DrupalVM can go to production. I won’t copy those steps here, I’ll show how you can get CircleCI to deploy your DrupalVM configuration to a remote host.

See the article for full details, or my example linked later. For now I’ll do a quick review of some basic config.

The inventory file:

[drupalvm]
192.168.1.12 ansible_ssh_user=drupalvm

The config.yml file:

drupal_domain: "example.com"
vagrant_hostname: "{{ drupal_domain }}"

apache_vhosts:
  - servername: "{{ drupal_domain }}"
    documentroot: "{{ drupal_core_path }}"
    extra_parameters: "{{ apache_vhost_php_fpm_parameters }}"


The vagrant.config.yml file:

# Note, {{ drupal_domain }} overridden for Vagrant to use local.* prefix.
drupal_domain: "local.example.com"
The prod.config.yml file:

drupal_deploy: true
drupal_deploy_repo: "[email protected]:organization/repo.git"
drupal_deploy_dir: "/var/www/drupal"

Those are the only tidbits in my production configuration. I treat the config.yml as primary with specific non-production overrides in vagrant.config.yml.

Adding CircleCI

NOTE! You’ll need to be able to deploy from CircleCI to a remote server, which means adding SSH permissions. With CircleCI you must create a key on your server and give the private key to project configuration.

Okay! So DrupalVM is running, you have accessed your site. Now, let’s run this sucker with CircleCI to do testing and deployment. Create a circle.yml file and let us walk through writing it.

First, we need to specify what language we’re using. In this case, I am using a PHP 7.0 image.

machine:
  php:
    version: 7.0.7

Defining dependencies

Next we want to set up our dependencies. Dependencies are things that we will need to actually run our tests, and they can be cached to speed up future runs. I’ll annotate specific steps using comments within the YAML.

dependencies:
  # Cache the caches for Composer and PIP, because package download is always a PITA and time eater.
  cache_directories:
    - ~/.composer/cache
    - ~/.cache/pip
  pre:
    # Install Ansible
    - pip install ansible
    - pip install --upgrade setuptools
    - echo $ANSIBLE_VAULT_PASSWORD > ~/.vault.txt
    # Disable xdebug (performance) and set timezzone.
    - echo "date.timezone = 'America/Chicago'"  > /opt/circleci/php/7.0.7/etc/conf.d/xdebug.ini
  override:
    # I save a GitHub personal OAuth token for when Composer beats down GitHub's API limits
    - git config --global github.accesstoken $GITHUB_OAUTH_TOKEN
    - composer config -g github-oauth.github.com $GITHUB_OAUTH_TOKEN
    - composer install --prefer-dist --no-interaction

Running tests

Before deploying anything to production or staging, we should make sure it does not deploy broken code.

test:
  pre:
    # Containers come with PhantomJS, so let's use it for JavaScript testing.
    # We specify it to run in background so that CircleCI saves output as build artifacts for later review.
    - phantomjs --webdriver=4444:
        background: true
    # Sometimes the test script can get cranky when this directory is missing, so make it.
    - mkdir web/sites/simpletest
    # User the PHP built-in webserver for tests, also run in background for log artifacts.
    - php -S localhost:8080 -t web:
        background: true
  override:
    # Run some tests
    - ./bin/phpunit --testsuite unit --group commerce
    - ./bin/phpunit --testsuite kernel --group commerce
    - ./bin/behat -f junit -o $CIRCLE_TEST_REPORTS -f pretty -o std

Saving artifacts

In the event that our tests do fail, it would be great to see additional artifacts. Any process that had background: true defined will have its logs available. Adding the following lines will let us access HTML output from the PHPUnit Functional tests and any Behat tests.

general:
  # Expose test output folders as artifacts so we can review when failures happen.
  artifacts:
    # Folder where Functional/FunctionalJavascript dump HTML output
    - "web/sites/simpletest/browser_output"
    # Folder where Behat generates HTML/PNG output for step failures
    - "tests/failures"

Setting up deployment

Now, it is time to tell CircleCI about our deployment process. Nothing too magical here. We are simplify defining that when the master branch passes to run a specific command. This command will load our production config and run the DrupalVM provisioning playbook on our production server. We specify the drupal tags to limit the scope of deployment.

deployment:
  prod:
    branch: master
    commands:
    # Specify DrupalVM environment and fire off provisioning.
    # DRUPALVM_ENV specifies which *.config.yml to load.
    - DRUPALVM_ENV=prod ansible-playbook \
      -i vm/inventory \ 
      vendor/geerlingguy/drupal-vm/provisioning/playbook.yml \
      # Points to directory containing your config.yml files.
      -e "config_dir=$(pwd)/vm" \
      --sudo
      --tags=drupal
      # I exported my Ansible user sudo password to environment variables to make provisioning work.
      --extra-vars "ansible_become_pass=${ANSIBLE_VAULT_PASSWORD}"

If your tests fail then the deployment will not run.

Example

Want to see an example of the full config? See my

Apr 27 2017
Apr 27

I have been working with Turner for the past twelve months as part of the Draco team (Drupal Application Core), who maintains Drupal 8 modules used by TV channels such as NBA, PGA, or TBS. Once brands started to use our modules, it was mandatory for us to improve testing coverage and monitoring. By that time, we had unit tests, but there was still a long way to go to get to a point where we could feel safe to merge a given pull request by looking at the code and the test results in Jenkins. This article explains our journey, including both the frustrations and successes implementing testing coverage in Drupal 8.

General structure of a test

A test tests something. Yes, it may sound trivial, but I want to use this triviality to explain why there are different types of tests in Drupal 8 and how they achieve this goal. Every test has a first step where you prepare the context and then a second step where you run assertions against that context. Here are some examples:

Context Tests I am an editor who has created a page node. When I open the full display view, I should see the title, the body, and an image I am visiting the homepage. There should be a menu with links to navigate to the different sections of the site, plus a few blocks promoting the main sections. I am an authenticated user who has opened the contact form. Some of the fields such as the name and email should be automatically set. Form submission should pass validation. A confirmation message is shown on success.

The assertions in the Tests column verify that the code that you have written works as expected under a given Context. To me, the end goals of tests are:

  • They save me from having to test things manually when I am peer reviewing code.
  • They prove that a new feature or bug fix works as expected.
  • They check that the new code does not cause regressions in other areas.

Having said that, let’s dive into how we can accomplish the above in Drupal 8.

Types of tests available

Depending on what you want to test, there are a few options available in Drupal 8:

  • If you want to test class methods, then you can write Unit tests.
  • If you want to test module APIs, then your best option is to write Kernel tests.
  • If you want to test web interfaces (I call these UI tests), then you have a few options:

In the following sections we will see how to write and run each of the above, plus a few things to take into account in order to avoid frustration.

Unit tests

Unit tests in Drupal 8 are awesome. They use the well known PHPUnit testing framework and they run blazingly fast. Here is a clip where we show one of our unit tests and then we run the module’s unit test suite:

Videos require iframe browser support.

The downside of Unit tests is that if the class has many dependencies, then there is a lot that you need to mock in order to prepare the context for your test to work, which complicates understanding and maintaining the test logic. Here is what I do to overcome that: whenever I see that I am spending too much time writing the code to set up the context of a Unit test, I end up converting the test to a Kernel test, which we explore in the next section.

Kernel tests

Kernel tests are Unit tests on steroids. They are great when you want to test your module’s APIs. In a Kernel test, Drupal is installed with a limited set of features so you specify what you need in order to prepare the context of your test. These tests are written in PHPUnit, so you also have all the goodness of this framework such as mocking and data providers.

Here is a Kernel test in action. Notice that it is very similar to the clip above about Unit tests:

Videos require iframe browser support.

Kernel tests fetch the database information from core/phpunit.xml where you need to set the database connection details. You may have noticed that these tests are slightly slower than Unit tests—they need to install Drupal—yet they are extremely powerful. There are many good examples of Kernel tests in Drupal core and contributed modules like Token.

UI tests

I am grouping together Browser tests, JavaScript tests, and Behat tests as UI tests because they all test the user interface through different methods. I want to save you the hassle of going through each of them by suggesting that if you need to test the user interface, then install and use Drupal Behat Extension. Here is why:

Browser tests don’t support JavaScript. Unless you are testing an administration form, chances are that you will need JavaScript to run on a page. They are solid, but I don’t see a reason to write a Browser test when I could write a Behat one.

JavaScript tests only support PhantomJS as the browser. PhantomJS is headless, meaning that there is no visual interface. It is tedious and at times frustrating to write tests using PhantomJS because you need to type and execute commands on a debugger in order to figure out what the test “sees” at a given point, while with Behat you can use full-featured Chrome or Firefox (I laugh at myself every time I call this a "bodymore" browser) so debugging becomes way more fun. Moreover, these kind of tests get randomly stuck both in my local development environment and in Jenkins.

Discovering Behat tests

Andrew Berry and myself spent a lot of time trying to get JavaScript tests working locally and in Jenkins without luck, which is why we decided to give Behat tests a go. It felt like salvation because:

  • The setup process of the Drupal Behat Extension module is straightforward.
  • We found no bugs in the module while writing tests.
  • We can use Chrome or Firefox locally, while Jenkins uses PhantomJS and does not get stuck like it did with JavaScript tests.

Here is a sample test run:

Videos require iframe browser support.

On top of the above, I discovered the usefulness of feature files. A feature file contains human readable steps to test something. As a developer, I thought that I did not need this, but then I discovered how easy it was for the whole team to read the feature file of a module to understand what is tested, and then dive into the step implementations of that feature file to extend them.

Here is a sample feature file:

Behat feature file

Each of the above steps matches with a class method that implements its logic. For example, here is the step implementation of the step “When I create a Runsheet”:

Feature step implementation

Behat tests can access Drupal’s APIs so, if needed, you can prepare the context of a test programmatically. All that Behat needs in its "behat.yml" file is the URL of your site and the Drupal’s root path:

Feature step implementation

Now look at your project

Does your project or module have any tests? Does it need them? If so, which type of tests? I hope that now you have the answers to some of these questions thanks to this article. Go ahead and make your project more robust by writing tests.

If you are willing to improve how testing works in Drupal 8 core, here are a few interesting open issues:

In the next article, I will share with you how do we run Unit, Kernel, and Behat tests automatically when a developer creates a pull request and report their results.

Acknowledgements

I want to thank the following folks for their help while writing this article:

  • Matt Oliveira, for proofreading.
  • Marcos Cano, for his tips and his time spent doing research on this topic.
  • Seth Brown, for helping me to become a better writer.
  • The Draco team at Turner, for giving me the chance to experiment and implement testing as part of our development workflow.
Apr 27 2017
Apr 27

For DrupalCon Baltimore I was volunteered to help with the lounge for Amazee Labs. This was my first year helping to set up a booth for any conference event and I learned a lot in the process. Fortunately, we have seasoned boothers which made the whole process look easy, but I realized there must be a lot of learned knowledge locked away. In the spirit of open source, I asked six of the vendors here to answer a few questions about their experiences and all were happy to contribute.

The following interviews have been edited heavily (due to my poor journalistic skills). Any and all mistakes are mine.

myDropWizard booth

How long have you been setting up booths?
This is our second DrupalCon booth, but we've also had a presence at Drupal camps.

Do you develop it in-house or work with a third party?
The concept, design and setup was all us, but we used third parties to help us create videos and print signs.

How long did it take you, from concept to completion?
It's hard to say, we've re-used some materials and ordered others new this year. Overall we've been planning for the last two months.

Any general tips you'd like to share, or things you'd do differently?
This is DrupalCon, it's a big deal for us. Work hard to get it right, start as early as possible. Try to avoid ordering things last minute, maybe even try to setup as practice before the event. I wish we would have taped out a ten by ten square in our office to better experiment with the booth size. I didn't realize how many things were required to be bought from the official convention center vendor, so look into that as well.

Thank you David!

new valley media booth

How long have you been setting up booths?
This is our second Drupalcon.

Do you develop it in-house or work with a third party?
We do all our designs and builds in-house.

How long did it take you, from concept to completion?
At least four weeks.

Any general tips you'd like to share, or things you'd do differently?
Make sure things are lightweight because you'll be carrying them. Start planning early, at least six months out. Try to stick out from the crowd. We did recon at previous DrupalCons to develop something unique.

Thank you Christina!

ey booth

How long have you been setting up booths?
At EY we've been doing them for two years, but we have five years of previous DrupalCon experience.

Do you develop it in-house or work with a third party?
We work with local talent for each Drupalcon to build our booth. We also source beer and swag from local suppliers. At the end of DrupalCon we'll work with local charities to donate anything of value.

How long did it take you, from concept to completion?
It took 2-3 months from concept to design, source the local talent, and build the final booth.

Any general tips you'd like to share, or things you'd do differently?
Get here early so you'll have time if anything goes wrong. Plan for the worst, hope for the best.

Thank you Liz!

third and grove booth

How long have you been setting up booths?
This is our first Drupalcon.

Do you develop it in-house or work with a third party?
All in-house.

How long did it take you, from concept to completion?
About 25 hours in total, but we started two months out.

Any general tips you'd like to share, or things you'd do differently?
Ask the conference vendors about options early. We wish we had a bigger backdrop and carpet for our booth. We decided to spend more on giveaways than atmosphere. I'm happy to see there are more design focused companies here, and hope to talk and learn from them.

Thank you Dan!

lingotek booth

How long have you been setting up booths?
Six years.

Do you develop it in-house or work with a third party?
In-house.

How long did it take you, from concept to completion?
We put some extra time into our booth because we use it throughout the year. We probably spent 80 hours over the course of many months. We also start planning early, at least a year in advance.

Any general tips you'd like to share, or things you'd do differently?
Be flexible and able to accept mistakes, adapt. We had a problem with our stickers, for example, which means I had to overnight a whole batch, so they aren't available on day one. Take every problem with a grain of salt, it's not the end of the world.

Thank you Calvin!

amazee labs lounge

How long have you been setting up booths?
Four years.

Do you develop it in-house or work with a third party?
We do everything in-house.

How long did it take you, from concept to completion?
About 20 hours, over the course of two months.

Any general tips you'd like to share, or things you'd do differently?
Cool swag is the easiest way to make an impression. You want people to come by and say, "I heard you have (fill in the blank), how do I get one?" Then just make sure you have enough supply for the demand.

Thank you Andrew!

Apr 27 2017
Apr 27

Thanks to all who took the time to take the poll. The participation was great! Over 350 respondents, which is a number in excess of 10% of the DrupalCon attendance. There were couple comments that I'd like to address:

A few felt that the questions were biased, or that the choices given were biased. I strove to make each of the questions a current topic, without having any imply a leaning in either direction. For example: "How do you feel about Drupal's Leadership" is meant to present a current topic in the community, but is designed to not imply a positive or negative spin. As for the options, it will never be possible in a poll with static response choices to cover all nuances, unless you just give three: positive, negative or neutral. I did try to ensure that each question had a fully positive response, a clearly negative response, and some options in between. I suppose it could have been set up to be a 1-10 scale, but I defy you to qualify the difference between 6 and 7 on such a scale. I also offered to account for comments that included a question number and a custom response when presenting the results, and have done that on questions 1 and 6, for which custom answers were given. 

There was also a concern that question 6 only offered negative or neutral options, and the suggestion was that the question should be removed from the poll as a result. I disagree, feeling that the first option, "The matter was handled properly" is certainly an option that indicates an opinion that is neither negative nor on the fence.

Should I do another poll? Let me know. 

And now, the results:

 The Future of Drupal

 Dries Conflicts

 Drupal Leadership

 Drupal Leadership Structure

 Drupal's Direction

 On the Matter of Crell

 Time Spent with Drupal Hedging your Bet

 Where you work

 What you do

The average time in Drupal for all respondents was 7.1 years.

Apr 27 2017
Apr 27

My blog post from last week was very well received and sparked a conversation in the Drupal community about the future of Drupal. That conversation has continued this week at DrupalCon Baltimore.

Yesterday during the opening keynote, Dries touched on some of the issues raised in my blog post. Later in the day we held an unofficial BoF. The turn out was smaller than I expected, but we had a great discussion.

Drupal moving from a hobbyist and business tool to being an enterprise CMS for creating "ambitious digital experiences" was raised in the Driesnote and in other conversations including the BoF. We need to acknowledge that this has happened and consider it an achievement. Some people have been left behind as Drupal has grown up. There is probably more we can do to help these people. Do we need more resources to help them skill up? Should we direct them towards WordPress, backdrop, squarespace, wix etc? Is it is possible to build smaller sites that eventually grow into larger sites?

In my original blog post I talked about "peak Drupal" and used metrics that supported this assertion. One metric missing from that post is dollars spent on Drupal. It is clear that the picture is very different when measuring success using budgets. There is a general sense that a lot of money is being spent on high end Drupal sites. This has resulted in less sites doing more with Drupal 8.

As often happens when trying to solve problems with Drupal during the BoF descended into talking technical solutions. Technical solutions and implementation detail have a place. I think it is important for the community to move beyond this and start talking about Drupal as a product.

In my mind Drupal core should be a content management framework and content hub service for building compelling digital experiences. For the record, I am not arguing Drupal should become API only. Larger users will take this and build their digital stack on top of this platform. This same platform should support an ecosystem of Drupal "distros". These product focused projects target specific use cases. Great examples of such distros include Lightning, Thunder, Open Social, aGov and Drupal Commerce. For smaller agencies and sites a distro can provide a great starting point for building new Drupal 8 sites.

The biggest challenge I see is continuing this conversation as a community. The majority of the community toolkit is focused on facilitating technical discussions and implementations. These tools will be valuable as we move from talking to doing, but right now we need tools and processes for engaging in silver discussions so we can build platinum level products.

Bookmark/Search this post with

Apr 27 2017
Apr 27
Array
(
    [add_payment_method] => Array
        (
            [payment_details] => Array
                (
                    [type] => 
                    [number] => some number here
                    [expiration] => Array
                        (
                            [month] => some month
                            [year] => some year
                        )
                    [security_code] => some code
                    [stripe_token] => tok_1AAAAAAAAAAAAAAAAAA
                )
            [billing_information] => Array
                (
                    [address] => Array
                        (
                            [0] => Array
                                (
                                    [address] => Array
                                        (
                                            [country_code] => HR
                                            [langcode] => 
                                            [organization] => test company
                                            [given_name] => John
                                            [family_name] => Doe
                                            [address_line1] => Some street name 2
                                            [address_line2] => 
                                            [postal_code] => Some postal code
                                            [locality] => Some City
                                            [sorting_code] => 1234
                                        )
                                )
                        )
                )
        )
)
Apr 27 2017
Apr 27
Add Parallax Styled Blocks to Your Drupal 8 Theme

In this tutorial, I will explain how to use custom block types to create a Parallax effect in a Drupal 8 subtheme.

It would be preferable but not required for you to have a good understanding of Drupal 8 theming. You can click here to take the Drupal 8 Theming Class.

To be able to follow this tutorial, you need to install Bootstrap and create a subtheme from the CDN folder. You can follow our guide here in our earlier post.

Parallax effects are usually full width so you need to turn on Fluid container option from the theme menu.

  • Go to /admin/appearance Install and set the theme as default 
  • Enter settings and select the Container drop-down and tick the box and select save configuration.

01

  • Now you need to make some custom blocks for the display. By using custom blocks you can theme the blocks specifically.
  • Go to admin/structure/block/block-content/types and create a new block type called Parallax 

02

  • Label the custom block Parallax:

03

  • Now go to 'Add custom block' and create two blocks, one for each of the images you are using Parallax 1 and Parallax 2:

04

  • Set the region to content and save the blocks.

Now you need to use the custom basic blocks to display content between the images on the block layout page. Also, remove any blocks you have placed in the sidebars as this will prevent the width being 100%.

05

  • Now turn on debugging if you don't already have it enabled.
  • Go to sites/default and copy and rename default.services.yml to services.yml on line 58 change debug to true:

000

  • Now, to be able to see the theme suggestions, add this code to your subtheme.theme file:
/**
 * Implements hook_theme_suggestions_HOOK_alter() for form templates.
 * @param array $suggestions
 * I found this code on drupal.org https://www.drupal.org/node/2724333
 * @param array $variables
 */
function subtheme_theme_suggestions_block_alter(array &$suggestions, array $variables) {
    // Block suggestions for custom block bundles.
    if (isset($variables['elements']['content']['#block_content'])) {
        array_splice($suggestions, 1, 0, 'block__bundle__' . $variables['elements']['content']['#block_content']->bundle());
    }
}
  • The function name needs to match your theme name. Adding this to your theme file allows you to theme custom blocks.
  • Flush all caches and if you inspect the site now you should see theme suggestions.
  • In Google Chrome, right click on the region and select Inspect to access the inspector tool:

06

  • Add the template suggestion for parallax block in your templates theme folder subtheme/templates/block--bundle--parallax.html.twig
  • Add this code to the template file:
<div class="parallax parallax--{{ elements['#id'] }}">
    <div class="parallax__bg"></div>
    <div class="parallax__content">
        <h2{{ title_attributes }}>{{ label }}</h2>
        {{ content['body']['0']['#text'] | raw}}
    </div>
</div>

  • This code will style the parallax custom block you created. If you need to debug this you can use kint from the devel module.
  • Now you need to add the CSS to style the blocks. To do this, open your /css/style.css and add this code: 
.main-container,
.page-header {
   padding: 0px;
}

.block-block-content2b3d7746-776f-484c-8686-c0e00a3978b6 {
   text-align: center;
   padding: 10em;
   font-size: 20px;
   background-color: #204d74;
   color: #fff;
}

.parallax {
   text-align: center;
   position: relative;
   overflow: hidden;
   height: 500px;
}

.parallax__bg {
   position: absolute;
   width: 100%;
   height: 140%;
}

.parallax--parallax1 .parallax__bg {
   background: url('../images/yourimage');
}

.parallax--parallax2 .parallax__bg  {
   background: url('../images/yourimage');
}

.parallax__content {
   position: relative;
   top: 50%;
   -webkit-transform: translateY(-50%);
   -ms-transform: translateY(-50%);
   transform: translateY(-50%);
   color: #fff;
   h2 {
     margin: 0px;
     font-size: 30px;
   }
   p {
     font-size: 20px;
   }
}

You will need to update  .block-block-content2b3d7746-776f-484c-8686-c0e00a3978b6 to match your block: 

007

This is the class assigned to your custom block.

  • And if you named your Parallax block differently, you will have to update .parallax--parallax1 and .parallax--parallax2. 
  • Now go to your theme and create a folder called images. This is where you will save the images for the parallax.
  • Add some Javascript to make the images move slightly. For this, you will use ScrollMagic. Download and extract the files from GitHub:

008

  • Now go to your theme and create a folder called js and move these files into the folder
    • animation.gsap.min.js
    • ScrollMagic.min.js
    • TweenMax.min.js
  • Now you need to add our custom js add parallax.js
  • You now need to tell the theme to load the js libraries. To do that, open ubtheme/subtheme.libraries.yml:
global-styling:
  css:
    theme:
      css/style.css: {}

  js:
    js/ScrollMagic.min.js: {}
    js/animation.gsap.min.js: {}
    js/TweenMax.min.js: {}
    js/parallax.js: {}
  dependencies:
    - core/drupal
    - core/jquery

  • And finally, add this code to your parallax.js file:
(function ($) {
    'use strict';
    Drupal.behaviors.myBehavior = {
        attach: function (context, settings) {

            var controller = new ScrollMagic.Controller();

            var blocks = [".parallax--parallax1", ".parallax--parallax2"];

            blocks.forEach(function (block, index) {

                var $bg = $(block).find('.parallax__bg');
                var $content = $(block).find('.parallax__content');

                var tl = new TimelineMax();
                tl
                    .from($bg, 2, {y: '-40%', ease: Power0.easeNone}, 0)
                    .from($content, 1, {autoAlpha: 0, ease: Power0.easeNone}, 0.4)
                ;

                var scene = new ScrollMagic.Scene({
                    triggerElement: block,
                    triggerHook: 1,
                    duration: "100%"
                })
                .setTween(tl)
                .addTo(controller);
            });
        }
    }
}(jQuery));
  • Make sure the images you are using are big enough for the max width you want to display. 
  • And now you should have a nice scrolling effect that you have applied only to our custom blocks:

Add Parallax Styled Blocks to Your Drupal 8 Theme

Congratulations now you know how to do the following in Drupal 8

  • How to add JS to your theme
  • Working with custom blocks
  • Applying CSS to your blocks

Finally, if you did use debugging you should disable it when the site goes live.


About the author

Daniel is a web designer from UK, who's a friendly and helpful part of the support team here at OSTraining.

View the discussion thread.

Apr 27 2017
Apr 27
Create a Drupal 8 Bootstrap subtheme using CDN

Using the Bootstrap CDN allows you to quickly add custom code that overrides the Bootstrap defaults. By doing so you can quickly make your own Drupal theme based on Bootstrap.

In this tutorial, we will demonstrate how to create a Drupal 8, Bootstrap subtheme that uses the "Bootstrap CDN".

  • Firstly, you will need to download, install and enable Bootstrap.
  • Now open the Bootstrap folder, enter the starterkits folder and copy the CDN folder and place it in the themes folder next to bootstrap:

001

  • Now rename the folder with the name you want to give your theme. For this tutorial, I will simply call it subtheme.
  • Now we need to replace THEMENAME with subtheme in the following files:
    • /config/install/THEMENAME.settings.yml
    • /config/schema/THEMENAME.schema.yml
    • /THEMENAME.libraries.yml
    • /THEMENAME.theme
  • The starterkit file is slightly different and needs to be renamed from /THEMENAME.starterkit.yml to /subtheme.info.yml
  • Now open subtheme/subtheme.info.yml in your editor of choice. I recommend Atom.
  • Again update the 'THEMETITLE' and description with the details of your theme.

002

  • Now open the schema file inside config and update the label

003

  • Now go back to Appearance and scroll down to the uninstalled themes section and we should see the theme subtheme.

004

Install and set as the default theme and you are ready to start customising your own theme.


About the author

Daniel is a web designer from UK, who's a friendly and helpful part of the support team here at OSTraining.

View the discussion thread.

Apr 27 2017
Apr 27

This weekend (29th-30th April 2017) the Drupal, Joomla, and WordPress communities will get together in London for two days of sprints that enable anyone working with Open Source to get involved with the communities that create it, and take part in improving it.

A gathering of three of the biggest Open Source CMS projects is a great opportunity to find out about different approaches to common problems, and a chance to cross pollinate new ideas and technologies across our communities.

We highly recommend sprinting as a great way to learn from your peers, raise the skill levels of everyone who takes part, and help the thousands of people who benefit from your contribution.

You're welcome to join us on the Saturday, the Sunday, or both days, for face to face collaboration on improving code, design, and documentation.

Lunch, and tea and coffee will be provided, as well as an ice cream break in the afternoon.

At 5 p.m. we will move to a nearby pub to socialise for the evening.

Robert Castelo is one of the organisers of the event, and Code Positive is proud to be a sponsor, along with Rochen, SiteGround, and Happy Computers.

If you’re free this weekend please do register and come along.

See you there!

Apr 27 2017
Apr 27

We are heading towards the end of our "Druplicon marathon". Besides this post, we have only one left for you. It will be hard for us not to search for any Druplicons. But until then, let’s enjoy them a little bit more. After Humans and Superhumans, Fruits and Vegetables, Animals, Outdoor activities, National Identities, Emotions, Human Professions and Hats, it’s time for Drupal Logos covered with Art.

Aztec Druplicon (Drupal Camp Mexico 2013)

Drupal Logo aztec

China art Druplicon (Drupal Camp China 2015)

Druplicon china art

Druplicon in Mesquerade costum (Drupal Camp New Orleans 2015)

Drupal Logo masquerade costum

Indian art Druplicon (DrupalCamp Chennai)

Drupal Logo Indian Art

Maya Druplicon (DrupalCamp Guatemala 2013)

Druplicon maya

Czech art Druplicon (Drupal Camp Prague 2013)

Drupal Logo Czech

We were disappointed in the past that there were areas that you did not find any of the missing Druplicons. Therefore, we were very happy that your feedback is back with Gevorg Mkrtchyan, who fund Cossack from Drupal Camp Krassnodar 2016 (shown beyond), for the blog post about Humans or Hats. We encourage you to do the same. Find any of the missing Drupal Logos in any of the areas we have covered so far, post them on our twitter account and you will be mentioned in our last blog post about Druplicons.

Drupal Logo cossack
Apr 27 2017
Apr 27

This is a story of why we have migrated from Phing to Make.

Lets preface this by saying that Phing is a great tool, we just weren't using it in the right way.

After using Phing for 2 years, it’s now easy to see that Phing is competing with projects like:

All the above tools being native (PHP) command line applications that have the ability to bootstrap Drupal and do interesting things. We never took this approach because we already had these tools and we were just wrapping them in Phing.

To make (pun intended) matters worse, we were also starting to reinvent the wheel with Robo and wrapped our scripts in Object Oriented PHP. While this gave us test coverage for our steps, our build steps aren’t anything more than declarations of the CLI steps a developer should use to build the project. The logic should be reside in simple first class CLI applications.

Here are some of the reasons we finally decided to migrate over to a Makefile workflow.

Composer workflow

Phing was not ideal when it came time for us to adopt a composer based workflow.

Phing was always our entry point into a project, and now with "composer install" handling a lot of our application dependencies, we found the lines blurring.

Multiple languages

We have also adopted additional languages as part of our projects:

  • Application Developers = PHP
  • Frontend developers = Nodejs
  • Operations = Golang

There are no benefits to wrapping a Nodejs or Golang package with Phing (unless your really really love Phing).

So we simply rely on each project being able to be built via the command:

make

Simple definition files

I mentioned above that we were using Phing wrong, here is an example of how we were doing that.

We wrapped every exec call in this (ouch!):

<target name="cache-clear"

        description="Clear Drupal cache.">

  <exec command="${drush.cmd} cc all"

        logoutput="true" />

</target>

Instead of using native Phing objects (PHP code) to bootstrap the application and clear the cache, we were writing glorified bash scripts wrapped by XML! This made our build steps overly verbose, and very hard to read, modify and share.

After migrating to a Makefile we have found ourselves with cleaner definition files:

This is just a small portion of our Makfiles.

#!/usr/bin/make -f

PHPCS_STANDARD=vendor/drupal/coder/coder_sniffer/Drupal/ruleset.xml
PHPCS_EXTENSIONS='php,module,inc,install,test,profile,theme'
PHPCS_INGORE='*/libraries*/,*/contrib/*,*/*.features.*,*/*.field_group.inc,*/*.layout.*,*/*.pages_default.*,*/*.panels_default.*,*/*strongarm.inc,*/*.views_default.inc'
PHPCS_DIRS=app/sites/all/modules/custom app/sites/all/themes/custom

build: deps lint

deps:
        composer install --prefer-dist --no-progress
        npm install

lint:
        bin/phpcs --report=full \
                  --standard=$(PHPCS_STANDARD) \
                  --extensions=$(PHPCS_EXTENSIONS) \
                  --ignore=$(PHPCS_IGNORE) \
                  $(PHPCS_DIRS)

Don't get me wrong, you can write very messy Makefiles, but the Makefile has given put us in the right direction.

More contribution

Internally we have a "scaffold" project which we use for bootstrapping new Drupal projects, this comes preloaded with a generic workflow (Makefile) and dependency graph (composer.json and packages.json).

Since migrating to a Makefile approach we have seen a huge growth in collaboration on the Makefile in this "scaffold" project, something I haven't seen during our Phing build system approach.

Conclusion

This is a great example of where "old and boring" technology really shines. The Makefile has given us a sturdy base for future projects regardless of the language or how we wish to build them.

We aren’t the only ones from the PHP community who think this is a great approach, see the latest blog post from Fabien Potencier http://fabien.potencier.org/symfony4-best-practices.html.

Are you using make or any other build tools? Let me know in the comments.

Drupal Make Build tools
Apr 26 2017
Apr 26

Thanks to you, the Drupal Community, our Periodic Table of Drupal 8 Modules is a smash hit! So much so that the 100 prints we brought to Baltimore are gone. By popular demand, however, we're providing the PDF for download—perfect for a desktop or a print of your very own.

Apr 26 2017
Apr 26

This weekend (29th-30th April 2017) the Drupal, Joomla, and WordPress communities will get together in London for two days of sprints that enable anyone working with Open Source to get involved with the communities that create it, and take part in improving it.

A gathering of three of the biggest Open Source CMS projects is a great opportunity to find out about different approaches to common problems, and a chance to cross pollinate new ideas and technologies across our communities.

We highly recommend sprinting as a great way to learn from your peers, raise the skill levels of everyone who takes part, and help the thousands of people who benefit from your contribution.

You're welcome to join us on the Saturday, the Sunday, or both days, for face to face collaboration on improving code, design, and documentation.

Lunch, and tea and coffee will be provided, as well as an ice cream break in the afternoon.

At 5 p.m. we will move to a nearby pub to socialise for the evening.

Robert Castelo is one of the organisers of the event, and Code Positive is proud to be a sponsor, along with Rochen, SiteGround, and Happy Computers.

If you’re free this weekend please do register and come along.

See you there!

Apr 26 2017
Apr 26

Drupal and the Drupal community are driven by volunteer contributions. There are many great ways to contribute that don't involve writing a single line of code. You could report a bug, edit a documentation page, test a new Drupal 8 feature, help a beginner on a forum, or help organize a meetup. Despite this, many Drupalers are shy about diving in.

After some reflection, the Evolving Web team realized that there's one way to contribute to the community that's really simple: thanking someone who has helped you. Someone who built a module you used, helped you in the issue queue, or has done a presentation you liked. It doesn't matter if you do it privately, publicly on Twitter, or whether you're Dries or a total beginner. 

As part of Evolving Web's "Drupal Love" sponsorship at DrupalCon Baltimore, we're hoping to encourage spontaneous expressions of gratitude by handing out 1,000 flowers, with a simple request: Give this flower to someone at DrupalCon Baltimore who helped you in some way. Spread #DrupalThanks.

#DrupalThanks Campaign

It will make both you and them feel great, encourage contributions, prevent burnout, and maybe even start a virtuous cycle. Thanking somebody costs nothing, yet can mean so much.

Evolving Web will be handing out several prizes to both givers and receivers of public thanks, which include a day of free Drupal Training, a subsidized trip to attend DrupalCamp Montréal this June 15-18, and flower bouquets delivered to your home or office.

To participate, just thank someone publicly on Twitter, like this:

Mike Cannon taking a photo at Evolving Web's training at Drupalcon Baltimore

or like this:

Tweet of #DrupalThanks

or like this:

Tweet of #DrupalThanks

Or if you'd prefer to do it offline, come by our Evolving Web's booth and tell us who you are thanking.

Alex Dergachev hugging big walking Druplicon at Drupalcon Paris

Apr 26 2017
Apr 26

Content is always one of the most important parts of a website. After all, the internet was designed for information sharing. As a result, upgrading to a new CMS implies the migration of content in some form or another. Taking this into account in the early stages is crucial when considering and preparing a CMS upgrade.
The Drupal community is very aware of content migration as a key success factor. Therefore, Drupal’s latest version (D8) has the migrate module included in its core. This key functionality allows you to upgrade from an older Drupal version to Drupal 8, using a few simple configuration steps. Below, I will explain how this works and put forward a few alternatives for custom migrations.

Why should you migrate to Drupal 8?

Site speed is not only important for SEO; it also affects your visitors’ browsing time and exit rate. Drupal 8 comes with an improved caching system that makes Drupal fly - all while taking into account content modification. There are no more endless waits for caches to invalidate, thanks to the real-time cache invalidation using cache tags.
Another reason for migration is the Drupal community. Plenty of features are available to integrate in your own site for free, which in turn enables you to spend time and money on other things. The community also keeps an eye on continuous improvements to the existing code. Drupal 8 is a great example of this, with its foundations in the Symfony2 framework. Everything in D8 has been standardised in such a way that maintenance is a lot easier and time-effective.
Let there be no doubt that migrating to Drupal 8 is an excellent long-term move!

How exactly should I migrate to Drupal 8?

You can use the Drupal migrate module that is included in core to upgrade from an older Drupal version to Drupal 8. Make sure to install and enable required modules first.
An example: if your site uses special field types, those modules should also be installed in your new Drupal 8 website. When you’re done configuring your site, you just need to enable the following modules:

  • Migrate
  • Migrate Drupal
  • Migrate Drupal UI

This last module will direct you to a configuration page, where you can start the actual migration. Simply enter the database information from your existing Drupal site and let Drupal review the upgrade.

The review will give you a list of available upgrade paths, next to a list of modules that are currently missing. If you’re happy about the review, you can choose to start the upgrade. Drupal will start importing content, users and taxonomies into your Drupal 8 website. Be aware that a rollback mechanism through the UI of Drupal is not available at this time. Since the Drupal core migrate is built to support a certain number of cases, it is possible that your site is too complicated to import correctly with the Migrate Drupal module. Sometimes, writing a customised migration is a better approach.
 

How to write a customized migration?

In most cases, the Migrate Drupal module will result in a reinstall of your Drupal website because some parts have been imported in the wrong way. You can opt to play things safe and write the migration yourself.
Writing a migration in Drupal 8 is done with the Migrate Plus module. This module allows you to create a new Migration entity. Those entities are created in YAML.

# Migration configuration for News content.
id: news_node
label: News Content Type
migration_group: demo_news
source:
 plugin: news_node
destination:
 plugin: entity:node
process:
 type:
   plugin: default_value
   default_value: news
 langcode:
   plugin: default_value
   source: language_code
   default_value: nl
 title: post_title
 field_title: post_title
 path: path
field_tags:
 plugin: migration
 migration:
   - news_terms
 source: tags_terms

migration_dependencies:
 required:
   - news_terms

Example of a Migration entity: migrate_plus.migration.news_node.yml

Each migration entity can belong to a Migration Group entity and is defined in YAML with the key ‘migrate_group’. A whole group of migrations can be imported or rolled back at once with drush by installing the Migrate Tools module.

  • drush mi --group=”demo_news” Import all migration in group demo_news
  • drush mr --group=”demo_news” Rollback all migrations in group demo_news

The main key of a migration is a Drupal 8 plugin that tells the migration where the source information comes from. There are plenty of base source plugins available for Drupal 8.

  • SqlBase - in Drupal Core: lets you migrate from an SQL source.
  • URL - in Migrate Plus: lets you migrate from a URL which can return JSON, XML, SOAP.
  • CSV - in Migrate Source CSV: lets you migrate from a CSV source file.
  • Spreadsheet - in Migrate Spreadsheet: lets you migrate from a csv, xls or xlsx source file.

If this does not suffice, you can start from your own source that extends from the SourcePluginBase class.

We extended the SqlBase source for our news_node source plugin.

public function query() {
 $query = $this->select('post', 'p');
 $query->fields('p', [
   'ID',
   'post_title',
   'post_name',
   'post_date',
 ]);
 $query->condition('p.type', 'news');
 return $query;
}

Query function in news_node source.

The query function returns a Select object with the information needed during the migration. This object will be the source for our migration.
Next we need to tell the migration which fields we want to map to the migration. This is done with the fields method.

public function fields() {
 $fields = [
   'post_title' => $this->t('The Post Node title'),
   'post_date' => $this->t('The Post creation time'),

   // ...
 ];

 return $fields;
}

In Drupal 7 we used prepareRow to provide field information that couldn’t be selected with a single query. In Drupal 8 this can be done with the prepareRow method. In our example we fetch a teaser image and then add the file ID and file alt to the migration source.

public function prepareRow(Row $row) {
// Find related teaser attachment image.
$file = $this->getTeaserImage($content_id);

// Set a new property file_id.
$row->setSourceProperty('file_id', $file['id']);
$row->setSourceProperty('file_alt', $file['alt']);
return parent::prepareRow($row);
}

Add extra information to the migration in preparerow.

When we go back to the YAML confirmation of our migration entity, we see that there is also a destination key configured. In most cases this will be an entity:entity_type destination plugin. Migrate will then automatically create entities of the configured type. In our example, new nodes will be created. If needed, you can also simply create a new destination plugin, which performs extra actions during the import function.

The progress key in our configuration defines the field value mapping. It contains a mapping of keys and values where the key is the Drupal field name and the value is the source field name. In some cases, like ‘type’ or ‘language’, we use a default_value plugin which allows us to set the value of the field to a fixed value. In our example, we are creating new nodes of type news in Dutch.

In some cases, the source value comes from another migration. In our example the value of ‘field_tags’ comes from another migration, this is defined by using the ‘migration’ plugin and then specify the migration(s) in which the value is migrated. Whenever such migration dependent fields are presents an extra key ‘migration dependencies’ is necessary. This is an array of migrations which needs to run first.


I hope this post has helped you to provide some insight in migrating your website from D7 to D8! As always, you can reach out to me and the rest of the team via our website.

Apr 25 2017
Apr 25

Tomorrow (Wednesday, April 25), I'm leading a Birds of a Feather (BoF) at DrupalCon Baltimore titled Managing Drupal sites with Composer (3:45 - 4:45 p.m. in room 305).

Composer for PHP - Logo

I've built four Drupal 8 websites now, and for each site, I have battle scars from working with Composer (read my Tips for Managing Drupal 8 projects with Composer). Even some of the tools that I use alongside composer—for project scaffolding, managing dependencies, patching things, etc.—have changed quite a bit over the past year.

As more and more Drupal developers adopt a Composer workflow for Drupal, we are solving some of the most painful problems.

For example:

  • Should I use the composer.json that's included with Drupal core? If so, why is there also a .lock file included? (See issue: Improve instructions for updating composer.json and /vendor).
  • I just installed Webform and now it's yelling at me about front-end libraries. How do I install front-end libraries with Composer, especially if they're not on Packagist?
  • What's the best way (or ways) to set up your Drupal project using Composer? (See discussions about this on Drupal.org: 1, 2, 3).
  • Is it a best practice to commit the vendor directory or not? Why?
  • Sometimes I see tildes (~), other times ^, and sometimes Composer yells at me when I try to add a module that has a beta release. Why is this stuff so confusing? I just want to add a module!
  • I download tarballs or zip files of modules and drag them into my codebase. What's the best way to install modules like Search API Solr or Address, when they require Composer?

Some of these questions have answers. Some are still being debated on a daily basis!

I'd love to see you come to the BoF tomorrow if you're at DrupalCon, and you want to talk about Composer and Drupal. I'll try to take notes and post them on my blog as well.

Apr 25 2017
Apr 25

Adding JS adds dynamic presentation effects to a theme for a better user experience.

In One of the project when i had been asked to display a custom error message to the User login page, when user tried with 3 or more failed attempt. On the other hand we can handle the error using form_set_error or drupal_set_message. What if we want to include that error message to be displayed on specific position.there comes add_js into picture. I have created a hook_form_alter inside that called a custom form validation. Under that custom form validation by checking the user login count, calling an js to the user page. Sleek and simple way to do the JS

When we work with theming or module development we required to add  custom js / css to our theme or module and Adding own CSS/JS to the Drupal page is easy and multiple approach is available in drupal to do this. But the best approach to do is to get the exact requirement and understand what is best way to handle css/ js for that period of time.

Below are the list of approach

  • drupal_add_css(), drupal_add_js()
  • including in .info file
  • [‘#attached’] attribute
  • drupal_add_library()
  • hook_css_alter(&$css), hook_js_alter(&$js)
  • drupal_add_html_head()
     

Including as html in .tpl.php
 

1. drupal_add_css(), drupal_add_js()

In Drupal, drupal_add_js() & drupal_add_css() are functions to add JS/CSS to the module or theme layer. This method is used by most of the developer. Which is easy to use and can be inserted wherever you want, can be inserted online, can be added file as cache easy to find documentation. On the other hand it can be found anywhere in the codebase where it is difficult to search sometimes and you are not expecting to be there. Adding multiple file can lead to a big mess. And also require proper naming convention if you make change in js or css file. You need to add the same name to everywhere in  the code where you have used drupal_add_js() & drupal_add_css().

drupal_add_js(drupal_get_path(‘module’, ‘example’) . ‘/example.js’);

drupal_add_js('jQuery(document).ready(function () { alert("Hello!"); });', 'inline');

drupal_add_css(drupal_get_path('module', 'example') . '/example.css');

drupal_add_library('example', 'drag-and-drop');

 

2. including in .info file

Custom Javascript file can be added to module/theme under info file. It ‘s always a better way to let the other Developer know how many more  file you are going to attached with your module or theme. Once it is has been declared & added to module/ theme file. It automatically get added to all the page. No need to declare in any of the preprocessor. Most of the themer use this approach for theming. On the other hand unusual css /js get added to un required pages.  No control over addition of css/ js to specific page. Can not be removed or set weight in .info file.

name = My theme

description = Theme developed by me.

core = 7.x

engine = phptemplate

scripts[] = mytheme.js

3. Form API [‘#attached’] Property

On of the best way to make sure which files you are going to add. Works great with CSS, JS, library. Easy to include in any of the drupal form and we have ability to add multiple files. It can be used any kind of attached data. A keyed array of type => value pairs, where the type (most often 'css', 'js', and 'library') determines the loading technique, and the value provides the options presented to the loader function.

$form['#attached']['css'] = array(
  drupal_get_path('module', 'ajax_example') . '/ajax_example.css',
);

$form['#attached']['js'] = array(  

    drupal_get_path('module', 'ajax_example') . '/ajax_example.js',

);

4. drupal_add_library()

Adding a multiple JavaScript or CSS files at the same time.

The library defines collection of JavaScript and/or CSS files, optionally uses settings, and optionally requiring another library. For example, a library can be a jQuery plugin, a JavaScript framework, or a CSS framework. This function allows modules to load a library defined/shipped by itself or a depending module, without having to add all files of the library separately. Each library is only loaded once. It allow you to reuse styles/scripts on different pages, Path and file names are stored in one function, easy to include in multiple files. On elibrary can use other library too. On the other side a Bit more code to write. And include all the files in library.

Parameters

$module: The name of the module that registered the library.
$name: The name of the library to add.
$every_page: Set to TRUE if this library is added to every page on the site. Only items with the every_page flag set to TRUE can participate in aggregation.

Return value

TRUE if the library was successfully added; FALSE if the library or one of its dependencies could not be added.


5. hook_css_alter(&$css), hook_js_alter(&$js)

hook_css_alter() is designed to act on .css file before they are being included on the page .  using this hook you can easily stop a .css file or group of files from being added to the page.


function demo_css_alter(&$css) {

  $path = drupal_get_path('module', 'node') . '/node.css';

  unset($css[$path]);

}

The $path variable you see above stores the path to the node.css file found in the Node module folder and is used in the unset() function to identify which array element we want to unset.

Parameters:

$css: An array of all CSS items (files and inline CSS) being requested on the page.

hook_js_alter() Perform necessary alterations to the JavaScript before it is presented on the page.


function hook_js_alter(&$javascript) {

  // Swap out jQuery to use an updated version of the library.

  $javascript['misc/jquery.js']['data'] = drupal_get_path('module', 'jquery_update') . '/jquery.js';

}

Parameters:

$javascript: An array of all JavaScript being presented on the page.


These above two hooks help you to rearrange elements by weight. we can delete files you don’t need before aggregation. Easy to replace path to a specified file. And Possible to re configure the aggregation. On the other hand Adding files here is possible but a bad choice and you end up by  messing up with files here.


6. drupal_add_html_head()

This is not the  recommended way to adding your custom css/js to the page as Using this functionality we adds output to the HEAD tag of the HTML page.This function can be called as long as the headers aren't sent. Pass no arguments (or NULL for both) to retrieve the currently stored elements. It’s is very difficult for understand where the code is included.


/**

 * [THEME] Preprocess function for the html theme hook.

 */

function themename_preprocess_html(&$variables) {

  $front_page = drupal_is_front_page();

  if ($front_page) {

    $variables['head_title'] = 'Jesús Heredia | Web Developer';

    // Add the description meta tag to the header

    $meta_description = array(

      '#type' => 'html_tag',

      '#tag' => 'meta',

      '#attributes' => array(

        'name' => 'description',

        'content' => "Jesús Heredia's personal website. Web Development on HTML5, CSS3, JavaScript, PHP, and Drupal.",

      )

    );

    drupal_add_html_head($meta_description, 'meta_description');

  }

}

Syntax: drupal_add_html_head($data = NULL, $key = NULL)


Parameters

$data: A renderable array. If the '#type' key is not set then 'html_tag' will be added as the default '#type'.

$key: A unique string key to allow implementations of hook_html_head_alter() to identify the element in $data. Required if $data is not NULL.
 

7. Including as html in .tpl.php
Yes we can add as html file in .tpl.php or printing it. Hope those methods come in handy for you. Make sure to use them in dependence of conditions you meet.

Conclusion: I personally feel to use drupal_add_library and [‘#attached’]. The form attached is really awesome and it’s very easy to understand what’s going on without scrolling through all the code.If you have any other idea just share across us over comment. want to find out more.

Apr 25 2017
Apr 25

The concept of experimental modules is a key part of the new upgrade model. Experimental modules are provided with Drupal core for testing purposes, but are not yet fully supported. As Dries pointed out in his DrupalCon Baltimore Driesnote, experimental modules should not be used in production.

Drupal security releases are provided only for the latest minor release, and older minor releases are considered end-of-life. This is a really strong incentive to upgrade to the latest minor version as soon as possible, as you really want to have security coverage for your production site.

Drupal 8.3.0 was released on 6 April 2017. Drupal 8.3.1 and 8.2.8, containing a critical security fix, had to be released less than two weeks later, on 19 April 2017. The reason for publishing a security release for an end-of-life minor release was that there is a minimum ”grace period” of 1 month between the release of a new minor version and public disclosure of security issues that affect the old minor version. This grace period allows for contrib modules to be updated for the new minor version in case of possible disruptive changes in internal APIs and experimental modules.

Drupal 8.3 added Layout Discovery, a new experimental module that is intended to replace Layout Plugin (9th most popular Drupal 8 contrib module), which is required by Display Suite (22nd) and Panels (31st).

The Display Suite, Panels, Page Manager and Panelizer projects all released new branches compatible with Drupal 8.3 and the experimental Layout Discovery module. The old branches of these modules and the Layout Plugin module itself are NOT compatible with Drupal 8.3. The issue queues of these modules are now full of issues describing upgrade problems resulting in completely broken sites.

So one lesson learned here is that minor upgrades are not always painless to do, at least immediately after a new minor version has been released. In this example case production sites can stick to 8.2.8 and hope all the problems with Layout Discovery and the contrib modules that require it are sorted out soon enough. But 8.2 is officially end-of-life: what happens if a new critical bug is discovered in the meantime?

Even when all the issues related to upgrading to 8.3 and using Layout Discovery are resolved, Layout Discovery is still an experimental module, not recommended for production use. (Admittedly Layout Plugin too is an alpha release, so it or modules requiring it should not be used on a production site. But this is just an example case.)

What should one do to have both a stable and a secure site?

One solution is for contrib modules to offer two versions: one that has experimental modules as dependencies and another that does not. But that is a lot to ask, as even the main branches of so many Drupal 8 modules are still in alpha or beta. Also, in this example case Page Manager depends on Panels which in turn depends on Layout Discovery. With many layers of dependencies even with just one main branch in each module it can sometimes take a lot of time and work just to find out where the root cause of a problem is.

I don’t have a better solution in mind, as I’m not even sure if what I have described here really is a serious problem. If it indeed is a genuine problem I hope it will be resolved sooner rather than later.

Apr 25 2017
Apr 25

CiviCRM Entity is a contributed module for tightly integrating and extending CiviCRM with Drupal. This module exposes CiviCRM API entities as proper Drupal entity types. This is HUGE as it allows you to make CiviCRM data available within your favorite Drupal tools such as Rules, Views, and EntityReference. I’d like to present another advantage of Drupal entity types, and that is Drupal fields.

By enabling CiviCRM Entity, you can add Drupal fields and associate with CiviCRM entity types such as Contacts and Events. In fact, any of the hundreds of Drupal field types can be used with CiviCRM Entity.  You may be asking yourself, “Shouldn’t I use a CiviCRM custom field? Why would you want to use Drupal fields?” The correct answer is, you should choose the right tool for the job.

CiviCRM is great at having the business logic and infrastructure to support event registrations. CiviCRM has price sets, price fields, and custom fields for collecting information from users when they register for events, as well as the logic and structure that goes with payment processing and financial accounting. You would want to use a CiviCRM custom field to collect data for a specific user. This will be helpful because they data can be accessed via Reports.

Drupal, on the other hand, is much better at organizing and presenting content than CiviCRM. There are tons of modules that can be leveraged to give you the functionality you desire. Need a mobile responsive slideshow? Add a Drupal Image field, configure it to work with Flexslider slideshow. Images are perfect example of picking the right tool for the job. The images in the slideshow for an event is not related to any data that someone may need for reporting, so there is no point to make it a custom field in CiviCRM, so let Drupal do what it does well, store and present this kind of data.

What do I get out of the box?

When you install CiviCRM Entity, you get Drupal based view page and edit forms for all exposed entities. We will limit our examples to Events in this article, but the same applies for all entity types. You can create, update, and display CiviCRM Events, and never leave Drupal. The view page has the path “<site_root>/civicrm-event/[id]” where [id] is the event id, and <site_root> is the base url of your Drupal website. The edit form is “/civicrm-event/[id]/edit” and new events can be created at “/civicrm-event/add”.

This view page and edit form are “standard Drupal”, meaning that all fields and properties that are displayed can be managed in typical Drupal fashion.  We highly recommend installing the Display Suite (DS) module, and its submodule Display Suite Forms to take full advantage of the possibilities, as you can configure field groups, layouts, and use the provided Display Suite field formatters for many of CiviCRM’s properties. With DS Forms you can also choose to hide properties from the edit form, although you will be forced to include any API required properties.

For more information on how to add and manage fields and managing the Display with CiviCRM Entity, please continue read the full article on Skvare.com.

Download CiviCRM Entity

Apr 25 2017
Apr 25

More and more developers are choosing content-as-a-service solutions known as headless CMSes — content repositories which offer no-frills editorial interfaces and expose content APIs for consumption by an expanding array of applications. Headless CMSes share a few common traits: they lack end-user front ends, provide few to no editorial tools for display and layout, and as such leave presentational concerns almost entirely up to the front-end developer. Headless CMSes have gained popularity because:

  • A desire to separate concerns of structure and presentation so that front-end teams and back-end teams can work independently from each other.
  • Editors and marketers are looking for solutions that can serve content to a growing list of channels, including websites, back-end systems, single-page applications, native applications, and even emerging devices such as wearables, conversational interfaces, and IoT devices.

Due to this trend among developers, many are rightfully asking whether headless CMSes are challenging the market for traditional CMSes. I'm not convinced that headless CMSes as they stand today are where the CMS world in general is headed. In fact, I believe a nuanced view is needed.

In this blog post, I'll explain why Drupal has one crucial advantage that propels it beyond the emerging headless competitors: it can be an exceptional CMS for editors who need control over the presentation of their content and a rich headless CMS for developers building out large content ecosystems in a single package.

As Drupal continues to power the websites that have long been its bread and butter, it is also used more and more to serve content to other back-end systems, single-page applications, native applications, and even conversational interfaces — all at the same time.

Headless CMSes are leaving editors behind

This diagram illustrates the differences between a traditional Drupal website and a headless CMS with various front ends receiving content.

Some claim that headless CMSes will replace traditional CMSes like Drupal and WordPress when it comes to content editors and marketers. I'm not so sure.

Where headless CMSes fall flat is in the areas of in-context administration and in-place editing of content. Our outside-in efforts, in contrast, aim to allow an editor to administer content and page structure in an interface alongside a live preview rather than in an interface that is completely separate from the end user experience. Some examples of this paradigm include dragging blocks directly into regions or reordering menu items and then seeing both of these changes apply live.

By their nature, headless CMSes lack full-fledged editorial experience integrated into the front ends to which they serve content. Unless they expose a content editing interface tied to each front end, in-context administration and in-place editing are impossible. In other words, to provide an editorial experience on the front end, that front end must be aware of that content editing interface — hence the necessity of coupling.

Display and layout manipulation is another area that is key to making marketers successful. One of Drupal's key features is the ability to control where content appears in a layout structure. Headless CMSes are unopinionated about display and layout settings. But just like in-place editing and in-context administration, editorial tools that enable this need to be integrated into the front end that faces the end user in order to be useful.

In addition, editors and marketers are particularly concerned about how content will look once it's published. Access to an easy end-to-end preview system, especially for unpublished content, is essential to many editors' workflows. In the headless CMS paradigm, developers have to jump through fairly significant hoops to enable seamless preview, including setting up a new API endpoint or staging environment and deploying a separate version of their application that issues requests against new paths. As a result, I believe seamless preview — without having to tap on a developer's shoulder — is still necessary.

Features like in-place editing, in-context administration, layout manipulation, and seamless but faithful preview are essential building blocks for an optimal editorial experience for content creators and marketers. For some use cases, these drawbacks are totally manageable, especially where an application needs little editorial interaction and is more developer-focused. But for content editors, headless CMSes simply don't offer the toolkits they have come to expect; they fall short where Drupal shines.

Drupal empowers both editors and application developers

This diagram illustrates the differences between a coupled — but headless-enabled — Drupal website and a headless CMS with various front ends receiving content.

All of this isn't to say that headless isn't important. Headless is important, but supporting both headless and traditional approaches is one of the biggest advantages of Drupal. After all, content management systems need to serve content beyond editor-focused websites to single-page applications, native applications, and even emerging devices such as wearables, conversational interfaces, and IoT devices.

Fortunately, the ongoing API-first initiative is actively working to advance existing and new web services efforts that make using Drupal as a content service much easier and more optimal for developers. We're working on making developers of these applications more productive, whether through web services that provide a great developer experience like JSON API and GraphQL or through tooling that accelerates headless application development like the Waterwheel ecosystem.

For me, the key takeaway of this discussion is: Drupal is great for both editors and developers. But there are some caveats. For web experiences that need significant focus on the editor or assembler experience, you should use a coupled Drupal front end which gives you the ability to edit and manipulate the front end without involving a developer. For web experiences where you don't need editors to be involved, Drupal is still ideal. In an API-first approach, Drupal provides for other digital experiences that it can't explicitly support (those that aren't web-based). This keeps both options open to you.

Drupal for your site, headless Drupal for your apps

This diagram illustrates the ideal architecture for Drupal, which should be leveraged as both a front end in and of itself as well as a content service for other front ends.

In this day and age, having all channels served by a single source of truth for content is important. But what architecture is optimal for this approach? While reading this you might have also experienced some déjà-vu from a blog post I wrote last year about how you should decouple Drupal, which is still solid advice nearly a year after I first posted it.

Ultimately, I recommend an architecture where Drupal is simultaneously coupled and decoupled; in short, Drupal shines when it's positioned both for editors and for application developers, because Drupal is great at both roles. In other words, your content repository should also be your public-facing website — a contiguous site with full editorial capabilities. At the same time, it should be the centerpiece for your collection of applications, which don't necessitate editorial tools but do offer your developers the experience they want. Keeping Drupal as a coupled website, while concurrently adding decoupled applications, isn't a limitation; it's an enhancement.

Conclusion

Today's goal isn't to make Drupal API-only, but rather API-first. It doesn't limit you to a coupled approach like CMSes without APIs, and it doesn't limit you to an API-only approach like Contentful and other headless CMSes. To me, that is the most important conclusion to draw from this: Drupal supports an entire spectrum of possibilities. This allows you to make the proper trade-off between optimizing for your editors and marketers, or for your developers, and to shift elsewhere on that spectrum as your needs change.

It's a spectrum that encompasses both extremes of the scenarios that a coupled approach and headless approach represent. You can use Drupal to power a single website as we have for many years. At the same time, you can use Drupal to power a long list of applications beyond a traditional website. In doing so, Drupal can be adjusted up and down along this spectrum according to the requirements of your developers and editors.

In other words, Drupal is API-first, not API-only, and rather than leave editors and marketers behind in favor of developers, it gives everyone what they need in one single package.

Special thanks to Preston So for contributions to this blog post and to Wim Leers, Ted Bowman, Chris Hamper and Matt Grill for their feedback during the writing process.

Apr 25 2017
Apr 25

We continue to describe the functional capabilities of “the big eight” as Drupal 8 has many improvements over its previous versions. Take a look at the innovations in Drupal 8.3.0, which is its latest minor release that came out this month. If you have decided to build a website in Drupal 8, we have some effective tips for devs describing how to create different useful things for D8 site. One of the first things to do, though, before you start creating your site is content modeling. This is what we’ll focus on today.

First of all, let’s recap what a content model is

A content model is a representation of all the types of content that you will need for your future web project, laid out in a structured manner. It includes the interconnections between content types as well as the distinctive elements of each type. The 8th version of Drupal allows you to model a site’s content through the convenient web-based interface instead of a standard database table. This model is a fundamental first step to the Drupal 8 site building process itself.

What is the main purpose of modeling your content?

Building a content model means everything from building out the structure to meet requirements to filling the site and to support functionality. This structure is designed to become your editor interface and HTML output. If it is well thought-out, it will become the groundwork of a harmonic Drupal 8 site where all elements are systematic, well-ordered and are functioning in conformity without contradicting each other.

What does a content model give to people working on web project?

Content managers whose job consist of producing unique content will learn about the contents optimal volume and other requirements they will have to meet. Also, the content model can provide authors with guidelines on how to upload texts, pictures, audio and video files using Drupal. Those people are expected to work with the CMF every day, so, the more conveniently the model is set up, the less work they will have to do. So keep your model consistent and intuitive.

Web designers can check whether their page designs fit well to different content types mapped out in the content model. If there are any fields with captions or with sortable data that are able to be sorted by the calendar date, alphabet etc. — in short, not just text — then all this should be taken into consideration when creating layouts.

Web developers will get a clear understanding of all the specifications for filling the site. A content model will allow them to configure the content management system in an appropriate way in order to make the editing and publishing process smooth and easy.

To sum up, content models are needed to support a site’s content produced by content managers, the site’s layouts designed by web designers and the site’s functionality developed by web developers.

Should the complexity be decreased?

Drupal 8 has a rich collection of built in entities, such as nodes, taxonomies, comments, users, files, configurables etc. You may be tempted to use them all. But the rule “the more, the better” doesn’t always work. Overloading your content model with all possible content types isn’t a good idea. An immensely complex model is inconvenient to handle. It will cause more time to be spent creating and then maintaining your site. Besides, the more web pages you’ll have to edit, the more mistakes you risk making. This is why you should try to keep your list of content types as short as possible.

How many content types is an optimal option?

The majority of Drupal 8 sites had proved that they don’t require more than 5 content types. If that does not seem to be enough for you, you may seek ways to reuse your existing types instead of adding new ones. For example, you can add extra fields and apply extra layouts to those fields. Additionally, the Form Mode Control and Form Mode Manager Drupal 8 modules allow you create different editing experiences for the same type of content.

So, now you’ve got some basics on content modeling and can start creating your own site on Drupal 8. Our Drupal developers are ready to make your ideas come true, just ask them.

Apr 25 2017
Apr 25

We continue to describe the functional capabilities of “the big eight” as Drupal 8 has many improvements over its previous versions. Take a look at the innovations in Drupal 8.3.0, which is its latest minor release that came out this month. If you have decided to build a website in Drupal 8, we have some effective tips for devs describing how to create different useful things for D8 site. One of the first things to do, though, before you start creating your site is content modeling. This is what we’ll focus on today.

First of all, let’s recap what a content model is

A content model is a representation of all the types of content that you will need for your future web project, laid out in a structured manner. It includes the interconnections between content types as well as the distinctive elements of each type. The 8th version of Drupal allows you to model a site’s content through the convenient web-based interface instead of a standard database table. This model is a fundamental first step to the Drupal 8 site building process itself.

What is the main purpose of modeling your content?

Building a content model means everything from building out the structure to meet requirements to filling the site and to support functionality. This structure is designed to become your editor interface and HTML output. If it is well thought-out, it will become the groundwork of a harmonic Drupal 8 site where all elements are systematic, well-ordered and are functioning in conformity without contradicting each other.

What does a content model give to people working on web project?

Content managers whose job consist of producing unique content will learn about the contents optimal volume and other requirements they will have to meet. Also, the content model can provide authors with guidelines on how to upload texts, pictures, audio and video files using Drupal. Those people are expected to work with the CMF every day, so, the more conveniently the model is set up, the less work they will have to do. So keep your model consistent and intuitive.

Web designers can check whether their page designs fit well to different content types mapped out in the content model. If there are any fields with captions or with sortable data that are able to be sorted by the calendar date, alphabet etc. — in short, not just text — then all this should be taken into consideration when creating layouts.

Web developers will get a clear understanding of all the specifications for filling the site. A content model will allow them to configure the content management system in an appropriate way in order to make the editing and publishing process smooth and easy.

To sum up, content models are needed to support a site’s content produced by content managers, the site’s layouts designed by web designers and the site’s functionality developed by web developers.

So, now you’ve got some basics on content modeling and can start creating your own site on Drupal 8. Our Drupal developers are ready to make your ideas come true, just ask them.

Apr 25 2017
Apr 25

Key points from our configuration management sessions.

Unfortunately none of us from Nuvole are attending DrupalCon Baltimore and can’t, therefore, attend the “hallway track” and join discussions in person. We have held presentations about advanced configuration management in Drupal 8 at all Drupal events we attended in the last year including the last DrupalCon in Dublin. So I’ll try to cover some concepts here that could help the discussion about how the configuration management can be improved.

To me there are at least two important dimensions to configuration management in Drupal 8 and different contrib project have sprouted to address:

Vertical: transfer configuration between different environments of the same site.
Horizontal: transfer configuration between different sites.

Following are a few contrib solutions and core issues that address the different itches. This is not meant to be an exhaustive or definitive list but highlight the different problem spaces. Many more contrib solutions address some issues in this space to accommodate various different workflows.

Vertical

Drupal 8 core only addresses this use case, however, there are some important cases not covered (yet). The management of configuration between the different environments is best taken care of by importing and exporting the whole sites configuration together.

Installing from existing configuration:

Contrib solution: Config installer
Core issues: Allow a site to be installed from existing configuration, Allow a profile to be installed from existing config

Environment specific configuration (ie devel only on develop)

Contrib solution: Config Split
Core issues: Allow exported configuration to be environment-specific, Allow development modules to opt out of config-export

Configuration with Content

Contrib solution: Default Content, Deploy

Horizontal

Due to the fact that the same tools can be used for both dimensions and the fact that in Drupal 7 features was abused for doing the vertical configuration management as well this concept may not be so clear. Ideally configuration between sites is shared from the development environment of one site to the development environment of another, and the vertical tools with drupal core are used for deployment. Moving configuration between different sites is done by moving a subset of configuration between environments.

Re-using a set of configuration in another site

Contrib Solution: Features
There are many more modules designed to deal with distributions and dealing with the paradigm that sites now own the configuration.

Inheriting installation profiles

Core issue: Allow profiles to provide a base/parent profile

Multisite with large portion of shared configuration

Contrib Solution: Config Split
While this is not the original problem it tries to solve, it is reported to be used for it..

Conclusion

I may have an obvious bias towards config split since we maintain that module but it is just one of many config related modules. I hope there is a fruitful discussion in Baltimore about configuration management in Drupal 8. BoF

Related blog posts:

Apr 25 2017
Apr 25

About five years ago I was made tech lead on a Drupal 7 project. The organisation I worked for had an extremely restrictive corporate IT policy, but I was sufficiently curious to install Drupal on my own laptop and play around with it. I also went to DrupalCamp London over a weekend in March. This impressed the senior managers enough to give me a fancy-sounding job title (though in truth it involved rather a lot more meetings than it did actually writing code). I’ve gone on from there through a variety of senior Drupal developer positions, but my dirty secret is, I’ve never really contributed back to Drupal. Until the last few weeks, that is. So, I thought I’d take the time to write about why that is, and what’s changed.

Rookie mistakes

While I was learning to use Drupal, I also started learning to use StackExchange. Naively, I asked a couple of questions and got the kind of terse responses noobs who haven’t really read the contribution guidelines often get. My interior monologue said, “Well, screw those guys. I tried my best to ask constructive questions and this is what I get?”

In reality, I think I’d asked a not-particularly constructive question that at least one person had asked before, but hey, why let details get in the way of a self-righteous sense of grievance?

Fast-forward to… DrupalCon

My company sent me to DrupalCon, I think probably because I’d had the nouse to go to DrupalCamp. Amongst other things, I went to a session on the Media Module. The guy presenting said something to the effect of, we know large organisations use this, but we don’t really know how any of them use it. I put my hand up and said, well I’m the Drupal lead at a large organisation, and I’d be happy to work on some use cases for you. Someone else in the audience (I felt slightly witheringly) said, “well, yeah, but if we just do it for one organisation we’ll lose half the developers who are contributing.”

“But… but… that wasn’t even what I was suggesting,” my interior monologue wailed. “And besides, it wasn’t even me that suggested it. I was just trying to help. Screw those guys.”

Fast forward to… Drupal Global Sprint Weekend

Manifesto ran a sprint weekend a few months ago. Despite my previous experiences, I decided I’d go. I looked around for issues for a while until I found one. It was a test, so I ran it. It looked good, so I moved it into ‘Reviewed and Tested’. Almost straight away, someone moved it back.

“Well what was the point of that?” my interior monologue fulminated. “If you’re not going to trust other people to review things then why even bother?”

Actually, looking back through the issue, I realise it was perfectly reasonable to push it back to ‘Needs Work’. The issue was far from simple and the subsequent discussion covered lots of things I’d not even really thought about.

That afternoon I found another, slightly fiddly issue that needed a test. It’d been open for months, so I tested it and put it into ‘Reviewed and Tested by the Community’. I left feeling fairly negative about the whole experience. I’d spent a day mostly just looking at bug lists and the one thing I’d managed to do just got nixed straight away. “I cost £1000 a day,” said my interior monologue (actually I have no idea what my day rate is, but facts, schmacts, right?) “I donate a day of my time and this is what I get for it?”

I think we can all agree my interior monologue is sometimes kind of a dick.

Fast forward to… DrupalCamp (again)

We had DrupalCamp London a few weeks later. I went along. Amongst other things I went along to a session by @rachel_norfolk on mentoring and contribution. She talked about false starts, and even the great big unmentionable – that sometimes, especially early on, contributing might not be particularly rewarding. But she also talked about the responsibility to contribute. And about how all these people – all these organisations – are making whole careers off the back of this amazing, free thing. And if they’re not making the time to help build and maintain that thing, well, that’s pretty bad.

My inner monologue sulked a bit. “She’s right”, it said, grudgingly. “But still. Screw those guys. Let’s get a beer.”

Fast forward to… my first contribution

The following Monday morning, I logged into my Drupal.org account. And I saw that one of my issues from the Sprint day had a comment. “Chof,” said my interior monologue. “Probably just someone telling you you’ve done it wrong”. But it wasn’t. It was @xjm, closing an issue that I’d worked on and thanking me, specifically, for taking the time to document my test steps. It might not look like a whole lot, but it really felt like a big deal to me. And it made me decide to try to contribute again.

That evening when I got home, I decided to pick up another one of the issues I’d looked at at the sprint day. To be honest, I still didn’t really understand what it was about. But I tried my best to put my questions into a constructive form, and added them to the ticket.

Not long after, @wim-leers replied with answers to my questions. It moved me on just enough, and I resolved to carry on working on the ticket. Then, you know, life stuff happened and we went through a busy spell at work and I didn’t really have any time to do anything for a while. @vaplas jumped in and finished off a chunk of the work. Initially I was a bit annoyed – I’d been hoping that, having taken the time to understand what the issue was about, I’d get to complete the solution. My interior monologue was just getting ready to say something dickish when I spotted that @alexpott had credited me on the patch, and written a message saying that although I’d not written any code, I’d helped to clarify the issue.

And again, it felt pretty amazing. So I picked up another one of the tickets in the same group. Again, I didn’t have time to do as much as I would have liked, and @vaplas wrote a large chunk of the patch. But there were some bits missing, and I helped to fill them in, and @vaplas really helped me to understand what I was doing. All of a sudden, I was submitting a patch for review! Plus, I’d learned how functional tests work in Drupal 8!

And that, readers, is how I got to contributing my first core patch.

Conclusion

I guess I learned the following things:

There’s a fine line between being a help vampire and asking constructive questions

But if you try to show your working, it might help someone else, and that’s really what it’s all about. You’re also, I think, allowed to ask for help when you’re contributing in a way that maybe you’re not when you’re just looking for a solution to your own problem. In fact, I’ve learned recently it’s not unusual to upload incomplete patches, or patches that you know will fail, so that they can be discussed.

Even a small amount of acknowledgement really means a lot

Say thank you. It’s totally worth it, and it makes everyone involved feel good about themselves, and about contributing. The help and encouragement I got from Wim, Vaplas and XJM has been completely instrumental in getting me to come back and to keep on trying, and I’m very grateful to all of them.

The community’s focus on collaboration over competition isn’t just a handy, alliterative slogan

They really mean it. If you help even a little bit there’s a good chance you might get credited, and people are genuinely respectful of the effort you’re making, even if you’re just making the effort to understand.

Persistence is important

Don’t get downhearted if someone pushes an issue you’ve updated back down to its previous status. They’ve probably got a good reason for it. Don’t worry if you get too busy at work or in your life. Your ticket might move along, or it might get finished, but there will still be ways for you to help. And they’re always worth it, no matter how small they might seem.

You start to get into a rhythm

You think you won’t have time to contribute, but once you’ve found an issue or group of issues to work on, it’s quite easy to do half an hour here and there.

And lastly, if your interior monologue is anything like mine, you should probably learn to ignore it.

Apr 25 2017
Apr 25

AMP is a new technology from Google that's designed to make browsing on a mobile feel as responsive as using any other app.

AMP achieves incredibly fast loading of web pages by prioritising content and pre-calculating layouts, giving images more time to load without the pain of changing the page layout once everything has finished loading.

That means visitors are able to start reading your content instantly without having to worry about their screen suddenly skipping back to the top of the page due to the images loading in late.

To find out more about what exactly AMP is then take a look at my article AMP for Drupal 8.

Technical details

To get AMP working on Drupal 8 the first step is to install the AMP module along with the AMP theme.

Once you have installed the module and enabled the theme, you will need to copy the ExAMPle Subtheme to create a new theme and rename it 'amp' or whatever is relevant to you.

The main AMP theme should be used as a base theme which you are extending with the new 'amp' sub theme, the reason for setting it up in this way is that you want to be able to update the main AMP theme at anytime without the complications of having to removing your updates from it.

So its best to keep your updates in a sub theme.

Now before you start any theming work you'll first need to configure the AMP module, your content types and any blocks that use views.

Configure AMP module

Path: /admin/config/content/amp

theme

Make sure to select your 'amp' sub theme as your AMP theme.

Your settings should be similar to ours, you may want to change a few but the most important one is the Power User: Run the whole HTML page through the AMP library. This will make sure to convert any images or other html elements that have been attached to a page by CKeditor into the relevant AMP HTML version of that element.

check list

Configure AMP display mode for content types

As I mentioned in AMP for Drupal 8 you can apply AMP to any/all content types, however you may wish to prioritise the content type/s you share most frequently on social media.

To add the AMP display mode to your content types you can either edit the content type directly or do it through the main configuration page (/admin/config/content/amp) under the AMP Status by Content Type settings - simply click enable followed by configure.

I prefer to edit the content type directly and add the display mode how I would normally, you will then need to prioritise what fields should appear on the AMP display mode. The most important step is to make sure you change the format to the relevant AMP version. The following example is for a text field:

format

Configure AMP version of view blocks

Now that you have configured your fields correctly you will need to duplicate any Views blocks and again make sure they are using the correct format. I recommend first looking at what content the Views block is adding to the page and deciding if it is relevant for the AMP version of that page.

Once you have done this simply duplicate the View and change the fields to use the relevant format, just as we did for the content types display mode.

One key thing to remember to do when going through this process is to change the way links are added to the fields in the view. We don't want visitors to be using AMP versions of our pages and to then click a link which will direct them to non-AMP pages on your site. To do this simply add the path as a hidden field on the View so that we can use it as a token when we rewrite results to output the field as a custom link.

At Code Positive we use the query ?amp to convert any of our pages to their AMP version. So we use the path token and simply add the query to the end. This means any links followed will still produce the AMP version.

link

Configure AMP block layout

Once you have created your new View blocks, you can now add them to the block structure for the 'amp' sub theme. Your path should be /admin/structure/block/list/'amp'. Simply add the blocks and sort the order you wish for them to appear in.

Add your CSS to your sub theme

Now that all your content has been finalised on your AMP pages you can go ahead and style the page.

Configure AMP metadata

Path: /admin/config/content/amp/metadata

Last step before you go live is to make sure that you add the relevant metadata to your AMP page. Here's ours as a reference:

meta

Testing your AMP configuration:

For testing while you are configuring AMP this development testing tool is what you need to make sure pages validate.

For testing once you have pushed your changes to the production site then this live testing tool lets you check that your pages pass Google's validation and will be added to the Google AMP Cache.

Troubleshooting:

New Relic

The New Relic monitoring service can invalidate AMP pages because it adds it's own JavaScript into pages.

To dissable New Relic on AMP pages add this code to the file /sites/default/settings.php

/** 
* Customise New Relic. 
*/
if (extension_loaded('newrelic')) { 
  // Add AMP page identifying logic here that would, for example,  
  // set variable $amp to TRUE or FALSE. If $amp is true, disable new relic.  
  $amp = isset($_GET['amp']);   
  
  if ($amp) {
    newrelic_disable_autorum (FALSE);  
    newrelic_ignore_transaction(); 
  }
}

Inline Images

In order to get Power User: Run the whole HTML page through the AMP library to work you may need to do the following steps:

Add missing file to Git

Depending on how you added the AMP module you may run into issues with some dependency files not being deployable.

To fix that remove .gitignore files from the Vendor/Saberworm directory and commit this file to Git:

vendor/sabberworm/php-css-parser/lib/Sabberworm/CSS/Settings.php

Correct path to images

If your site is hosted on Pantheon you may need to adjust the path to files.

Add this code to sites/default/settings.php

$_SERVER['SERVER_NAME'] = $_SERVER['HTTP_HOST'];
unset($_SERVER['SERVER_PORT']);

Google Analytics

The order in which Javascript is added to AMP pages is important.

Copy:

themes/amptheme/templates/layout/html.html.twig

To:

themes/amp/templates/layout/html.html.twig (assuming 'amp' is name of the AMP subtheme)

In the html.html.twig file you just copied remove this line:

<script async src="https://cdn.ampproject.org/v0.js"></script>

If you're having trouble or would like some help getting started contact us and we'd be happy to help.

Apr 25 2017
Apr 25

What is AMP?

People have come to expect mobile apps to be quick and responsive, but are often frustrated when it comes to browsing the web on their mobile.

AMP is a new technology from Google that's designed to make browsing on a mobile feel as responsive as using any other app.

"The AMP Project is an open-source initiative aiming to make the web better for all. The project enables the creation of websites and ads that are consistently fast, beautiful and high-performing across devices and distribution platforms." - AMP Project

AMP achieves incredibly fast loading of web pages by prioritising content and pre-calculating layouts, giving images more time to load without the pain of changing the page layout once everything has finished loading.

That means visitors are able to start reading your content instantly without having to worry about their screen suddenly skipping back to the top of the page due to the images loading in late.

Where can I see AMP pages?

Google will start to provide AMP pages as links in its organic search roughly 9 days after you deploy your AMP pages, but only if there are no errors with your AMP HTML so be sure to validate your pages before making them live.

Do also remember that AMP stands for Accelerated Mobile Pages so in order to find your AMP pages in a Google search you'll need to use your phone.

How does AMP work?

At the centre of AMP is a Javascript library which provides various optimisations to speed up the rendering of web pages.

AMP pages are written in AMP HTML, which is  the same as standard HTML but with a few restrictions, and the addition of a few custom elements that improve reliability and performance.

To make pages load even quicker they are always served from the Google AMP Cache, a super fast content delivery network that validates all pages before including them.

What type of content should use AMP?

There are no limits to which types of content you should have optimised in AMP.

You could optimise your whole mobile site to use AMP if you wanted to, but if that's not feasible then start off with your most important content.

Benefits:

So to summarise here's why AMP is so amazing:

  • Loading seems instant even on image rich pages
  • Layout is set so there's no sudden movement when an element loads in late
  • Fast content → Faster reading → More consumption (everybody wins)
  • Your sites SEO will improve! Although AMP is not currently a ranking factor. AMP does affect clicks, impressions, and user experience, which in turn affects SEO.

What's next?

Once you have implemented AMP then all that's left is to create some great content and get sharing!

Take a look at how quickly this article loads, its pretty much instant once cached. Remember AMP was designed for mobile so it may not look pretty on bigger screens AMP article.

If you're having trouble or would like some help getting started, then take a look at our more technical article on how to configure AMP for Drupal 8 or contact us and we'd be happy to help.

Apr 25 2017
Apr 25

It's back! You did not really think that our Druplicon marathon was finished, did you? Well, it's not. We still have some areas to explore. After Humans and Superhumans, Fruits and Vegetables, Animals, Outdoor activities, National Identities, Emotions and Human Professions, we have seen that not all Druplicons with hats were covered. So, here are Drupal Logos with hats.

Druplicon with Santa hat

Drupal Logo with santa hat

Druplicon with snow hats

Druplicon with snow hatDruplicon with snow hat 2Druplicon snow hat 3

Druplicon with ascot hat (Drupal day Bilbao 2014)

Drupal Logo ascot hat

Druplicon with fedora (Drupal Camp Buenos Aires 2009)

Drupal Logo with fedora

Druplicon with swimming hat (DrupalCamp Colorado)

Druplicon swimming hat

Druplicon with something very similar to sombrero hat (Drupal Camp Bratislava 2010)

Druplicon bratislava

Druplicon with crown (Drupal Camp Tirgu Mures 2013)

Drupal Logo king

Druplicon with turban

Druplicon wit turban

Druplicon with fishing hat (Drupal Camp Australia 2008)

Drupal Logo with fishing hat

You may have forgotten the rules after so much time. Nevertheless, find a Drupal Logo with a hat that we did not cover here, post it on our twitter account and you will be mentioned in our next blog post about Druplicons. Yes, it's as simple as that. But be careful! Drupal Logos that we have already used in other areas of our Druplicon marathon don't count. Like, the one with a baseball hat or with the one with professor’s hat, for example.

Apr 25 2017
Apr 25
Drupal 8 Field Layout Alternative to the Display Suite

In Drupal 7 to create custom displays, you would probably use Display Suite.

Drupal 8 just added a potential alternative to the Display Suite in the core experimental modules. The Field Layout and Layout Discovery modules will allow you to assign a layout to specific content types.

In this tutorial you will learn how to customise the display of content on a content type level with the Field Layout and Layout Discovery modules.

  • Enable the module Field Layout, in this tutorial I use Drupal core 8.3.1

01

  • Install
  • You will be warned that layout discovery is also required and that experimental modules should only be used for testing at this time. 
  • Continue
  • Now we need to assign a layout to our content. For this example, will use the article content type that comes with Drupal core.
  • Structure
  • Content Type
  • Operations > Manage Display
  • Below the normal options, you will now see that 'layout settings' is available.
  • Select your preferred layout, I have chosen the 3 column option.

02

  • Save
  • You will now notice that under Field you see titles for the regions available from this layout as shown below.

03

  • To change the display, simply drag and drop the item to the location you wish to use and save the layout. Normally images load on the left for this demonstration I will move them to the right.

04

  • Save
  • Now if we view an article you should see that the changes.

05

This is a very fast and easy way to customise the display of content on a content type level. You can even add to it by making your own layouts.

It also works with the Paragraphs module allowing you to assign content to regions within the various paragraph types, once officially a part of core this will be a very powerful and fast way to apply layout changes to your Drupal content.


About the author

Daniel is a web designer from UK, who's a friendly and helpful part of the support team here at OSTraining.

View the discussion thread.

Apr 24 2017
Apr 24

Ha sido un placer trabajar con el equipo de La Drupalera, también desde Reino Unido y en remoto. Se aseguraron en todo momento de que la distancia y el idioma no fuera un problema, manteniéndonos al día del progreso del proyecto y resolviendo todas las dudas y retos durante el proceso de desarrollo con Drupal hasta su lanzamiento.

Apr 24 2017
Apr 24
The word "community" comes from the Latin communis, which means "what is common and shared by many individuals." From the Drupal perspective, the community is nothing more than a group of people looking for the mutual exchange of knowledge about the technology (the detailed definition can be found here).

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web