Author

Apr 21 2017
Apr 21

PHP is a server-side scripting language, mainly used for web development but also used as a general-purpose programming language. Object-Oriented Programming (PHP OOP),  is a type of programming language principle added to php5, that helps in building complex, reusable web applications.

In this blog, we will be explaining some of Object-Oriented Programming concepts in PHP with  some examples.

The  Object Oriented concepts in PHP are :

  • Class 
  • Objects
  • Inheritance
  • Interface
  • Abstraction
  • Magic Methods

Class  & Object:

  • Class is a programmer-defined data type, which includes local methods and local variables.
  • Class is a collection of objects. Object has properties and behaviour.
  • First we have to define a php class, where classname should be same as filename.

Example for simple class:

 

Output:
Drupal book
900 Rs/-

In the basics of object oriented, let see how to define a class and create an object:

Creating Objects in PHP
When class is created, we can create any number of objects to that class. Object is created with the help of new keyword.

Calling Member Function
When the object is created we can access the variables and method function of the class with the help of operator ‘->, accesing the method is done to get the information of that method. Also look into how we can access object properties via variables

Output for the above code 

Samsung S8
Iphone S7
MI4
90000
65000
15000

Inheritance

When the properties and the methods  of the parent class is accessed by the child class , we call the concept has inheritance. The child class can inherit the parent method and give own method implementation , this property is called overridden method. When the same method of the parent class is inherited we call as inherited method. Now let us see types of inheritance supported in Object Oriented Programming and corresponding Php inheritance examples.

Types Of Inheritance

  1. Single Level Inheritance
  2. Multilevel Inheritance

Single Level Inheritance:  In Single Level Inheritance the Parent class methods will be extended by the child class. All the methods can be inherited.


Single Level Inheritance

Single Level Inheritance

Example for Single Level Inheritance
 

Output
Hi : Pavan
I am from valuebound
Hi: savan
I am from ABC

MultiLevel Inheritance :  In MultiLevel Inheritance the parent class method will be inherited by child class and again subclass will inherit the child class method. 

MultiLevelInheritance

Output

Class A is 80
Class B is 50 
Class C 20

INTERFACES:

  • An interface is a description of the actions that an object can do.
  • Interface is written in the same way as the class the declaration with interface keyword.

Rules of Interfaces:

  • All methods declared in an interface must be public; this is the nature of an interface.
  • All methods in the interface must be implemented within a class; failure to do so will result in a fatal error.
  • The class implementing the interface must use the exact same method signatures as are defined in the interface
  • Interfaces can be extended like classes using the extends operator.

Example for the interface class

Output:
Describing Mango tree

2) Interface can be extended with another interface using extends keyword

 

Output:
division of 10/2 is 5
multiplication of 2*3 is 6

Note on Interfaces:-

  • We cannot create objects to interface, but the class implementing the interface can have objects
  • We cannot define variable in interface.
  • If we extend interface all the methods of the interface must be implemented in child class.

Abstract Classes:

  • An abstract class is a class that contains at least one abstract method. Abstract method is function declaration without anybody and it has only name of the method and its parameters.
  • There can be any number of methods in the class and we have to declare the class as abstract only when there is an abstract method

Example for Abstract class


Output for the above code is:
Maruthi Suzuki
720000
Hyundai
300000

Notes on Abstract classes:

  • Objects cannot be created for the abstract classes.
  • If a class has only one method as abstract, then that class must be an abstract class.
  • The  child class which extends an abstract class must define all the methods of the abstract class.
  • If the abstract method is defined as protected in the parent class, the function implementation must be defined as either protected or public, but not private.
  • The signatures of the methods must match, optional parameter given in the child class will not be accepted and error will be shown.
  • Abstract classes that declare all their methods as abstract are not interfaces with different names. One can implement multiple interfaces, but not extend multiple classes (or abstract classes).

Now Let us see the difference between abstract class and interface.

Abstract class Inheritance

It can have constants, members, method stubs (methods without a body), methods

It can only have constants and methods stubs.

Methods and members can have public or protected  visibility

Methods of interface should only be public not any other visibility

Concept of multiple inheritance not supported.

An interface can extend or a class can implement multiple other interfaces.
 

Child class must implement all the  abstract method of parent class when extend keyword is used.

No need of implementing methods from parent interface when interface  is extending another interfac

In the end , now we are able to create a class, define objects for the class and create methods. We also learnt on different topics of object oriented like inheritance, interface, abstraction. The basic concepts of OOP is explained in this blog. 

In the next article we shall discuss about Magic methods in php.

Apr 21 2017
Apr 21

Over the past month there has been a lot of focus on Drupal, the community. More recently it seems people are back to thinking about the software. Dave Hall and David Hernandez both posted eye opening posts with thoughts and ideas of what needs doing and how we can more forward.

A one line summary of those posts would be "We should slim down core, make it more modular, and have many distros".

To a degree this makes sense, however it could cause divergence. Core is not great at all following the same pattern, but contrib is even worse. As part of the Workflow Initiative specifically there is a lot of work going on to try and get the Entity API aligned, get many more entity types revisionable and publishable, using common base classes, traits, and interfaces. If we maintained Node, Block Content, Taxonomy, Comment, etc all as separate projects then there's a chance less of this would happen. Also by doing this we are laying out foundations and setting examples to be followed.

One solution to this may be to follow Symfony (yet again), they have a monolithic project but then split this up into the various components, which are "read only" repos. It's be pretty awesome if we could do this with Drupal. From there we could make Drupal downloadable without many of the core modules. People with the right skills can create a composer.json file to pull in exactly what parts of Drupal are needed, others could use a form on d.o to select which parts are wanted, which downloads a compiled zip.

What would be more awesome is if we could abstract more of Drupal out of Drupal. Imagine if the Entity API was a PHP generic library. Imagine if you could create a Laravel or Symfony app with Nodes. This would be really tricky, especially since Dries announced the plans to make Drupal upgrades easy forever, but possible.

Currently most Drupal sites are still on 7, and here we're talking about what would be Drupal 9? Maybe we need to take step back and look at why sites aren't being upgraded. Dave mentions "A factor in this slow uptake is that from a developer's perspective, Drupal 8 is a new application. The upgrade path from Drupal 7 to 8 is another factor." Although another reason is also why would a company spend the tens of thousands upgrading to Drupal 8? It looks at works (from a users point of view) the same as Drupal 7. Drupal is a CMS, a Content Management System, and the management of content is more or less the same. Yes, with initiatives like Workflow and Media this is changing, but even then similar functionality can be achieved in Drupal 7 with contrib modules. Will Drupal 8 be the version to skip? go straight from 7 to 9?

As Drupal is now pretty firmly an enterprise platform we need to look at this from a marketing point of view. What is going to sell Drupal 9? Why are people going to upgrade? What do they really want? Is a slimmed down core and more modular application really the selling feature that's wanted?

Drupal is a CMS, quoting Dave again "do one thing and do it well". We need to focus on making the authoring experience awesome, and the workflows that go along with it awesome too. This should all be done in a consolidated way to make managing Node content, Block content, etc just as intuitive as each other. If during this process we can also make things more modular, and less Drupally, that'd be awesome!

Apr 21 2017
Apr 21

The first week of April I was among the attendees at the year’s largest US Angular conference, ngconf, in Salt Lake City, Utah. As one of the keynote speakers last year, I was excited at the opportunity to attend again, and curious about how different the atmosphere would be this time around. Last year the community was anxiously awaiting the release of Angular 2.0, and this year 4.0 was released just before the conference. Sidestepping the understandable confusion about the updated release cycles, it was the atmosphere in the community and the maturity of both the core framework and surrounding tooling that I was most interested in exploring.

This year’s day 1 keynote was delivered by Stephen Fluin and Igor Minar from the core team at Google, and much of it was focused on updates in the wider ecosystem: Angular Material, the CLI, IDE support, and Ionic were specifically highlighted. Each of these was in a fledgling or non-existent state during last year’s conference, but significant progress has been made on them since.

Especially exciting for the Drupal world, though, was the keynote case study presented by Brian Martin of NBA.com, which involved a progressively decoupled Drupal site built with Angular. Brian spoke of the shared programming principles between the two, the simplicity of integrating Angular with Drupal blocks, and more. NBA.com is a fascinating example of a large scale architecture built along lines with which we at Mediacurrent are very familiar, and it was great to see Drupal featured so prominently in the keynote for the second year running.

Further focus in the keynote was given to their new release cycle, where semantic versioning is being combined with scheduled releases that include potential breaking changes in a new major version release every six months. The team is working hard to make upgrading both immediately beneficial and painless, even across major versions, much like the direction one of Dries’ latest blog posts suggests for Drupal. However, they also recognize that not all sites can easily be kept up to date with each release, so the big announcement in the keynote was that Angular 4.x would be a LTS release, with critical bugs and security fixes continuing until 6.x is released.

Several other sessions I attended during the conference are worth expounding on, but for brevity, I will try to hit the highlights. Angular Universal, the framework’s isomorphic or server-side rendering story, is one I’ve spent a lot of time investigating. Since it was moved from community run into the core of the framework its maturity has significantly improved. Jeff Cross’ session on it showed the SEO, social sharing, and performance benefits it can provide, but for a wider understanding of the vision behind Universal, I highly recommend this post by Wassim Chegham. Another highlight was Sean Larkin’s workshop on Webpack, which walked us through creating our first webpack plugin from scratch while helping the audience better understand the thinking behind its architecture.

More big news came on the conference’s final day, when Brad Green and Rob Wormald delivered the second keynote. First announced was TypeScript’s adoption as an officially sanctioned language at Google, a big deal for a company that had previously only condoned the use of C/C++, Java, Python, Rust, JavaScript and Go. TypeScript is being widely embraced across frameworks and companies now, and the strongly typed superset of JavaScript deserves all the attention it has been receiving for the numerous benefits to developer experience and application stability it provides.

But even bigger news, perhaps, was Google’s announced commitment to open sourcing and improving usability around the build tools that allow all of Google’s internal Angular products to always run on the latest master branch. The ABC initiative, for Angular, Bazel, and Closure, has the potential to vastly simplify the use of Angular by enterprise clients, while increasing the performance, velocity and stability of their products. While this commitment is still in the design phase at this point, it points to just how seriously Google is taking improving the community’s ability to scale their apps while keeping up with where the framework is headed.

Initially, as a Drupal architect, I was drawn to Angular primarily by its familiar use of services and Dependency Injection, as well as a curiosity about its use of TypeScript. But much as I have found in the Drupal world, it is the inviting and passionate energy of the community that makes being involved continue to be worthwhile.

The Saturday after the conference, I was invited to participate in a Contributor’s Day event that brought together the core team and some prominent members of the community to discuss ways that Google and the community can better support each other. This ended up being a fascinating and eventful enough discussion that I’ve decided to write a separate post about it, which will be published soon.

Additional Resources
Presentation Framework Generalization, Toward Javascript and Agnosticism | Blog Post 
Decoupling in Drupal 8 Based on a Proven Model| Blog Post 
Decoupled Blocks with Drupal 8 and Javascript | Blog Post 

Apr 21 2017
Apr 21

WOW! The response to my blog post on the future of Drupal earlier this week has been phenomenal. My blog saw more traffic in 24 hours than it normally sees in a 2 to 3 week period. Around 30 comments have been left by readers. My tweet announcing the post was the top Drupal tweet for a day. Some 50 hours later it is still number 4.

It seems to really connected with many people in the community. I am still reflecting on everyone's contributions. There is a lot to take in. Rather than rush a follow up that responds to the issues raised, I will take some time to gather my thoughts.

One thing that is clear is that many people want to use DrupalCon Baltimore next week to discuss this issue. I encourage people to turn up with an open mind and engage in the conversation there.

A few people have suggested a BoF. Unfortunately all of the official BoF slots are full. Rather than that be a blocker, I've decided to run an unofficial BoF on the first day. I hope this helps facilitate the conversation.

Unofficial BoF: The Future of Drupal

When: Tuesday 25 April 2017 @ 12:30-1:30pm
Where: Exhibit Hall - meet at the Digital Echidna booth (#402) to be directed to the group
What: High level discussion about the direction people think Drupal should take.
UPDATE: An earlier version of this post had this scheduled for Monday. It is definitely happening on Tuesday./>

I hope to see you in Baltimore.

Bookmark/Search this post with

Apr 21 2017
Apr 21
Why Drupal is better than Wordpress and Joomla The top reasons to use Drupal for Your Website

Today’s top CMS platforms all offer their own unique flavor for users trying to get their website up and running. All of them have their own strengths and weaknesses, but for complete and total flexibility, Drupal is the best choice. While it requires a strong grasp of web development, the level of customization it offers is far beyond its competition.

Join us as we look at some of the top reasons to use Drupal, followed by an infographic that breaks down today’s top three platforms.

The Top 3 Reasons to Choose Drupal For Your Website

While there are plenty of articles about Drupal, and numerous reasons to use it, let’s take a look at the top three picks:

1. Agile Web 2.0 Development

Drupal embraces the best parts of agile web development. From the moment you install it, you have clean markup code, page and blog publishing, content management, search, polls, forums, user login modules, and plenty more. It cuts your development timeline down to mere days, as opposed to weeks of getting everything ready.

2. Thousands of Modules

Modules allow you to quickly add functionality to your website. With over 16,000 to choose from, this number is only growing. From additional security, to social media, to SEO, and backups, you can do just about anything with these additional tools, and provide your users with an excellent experience.

3. Ultimate Scalability

Drupal is insanely flexible. You can start with as little as 10 pages on your site, and move up to 10,000 posts without ever changing a thing. Performance and security can be easily modified through the Admin console. Perhaps this is why some of the world's biggest websites like the White House, Nascar, and the Grammys all run on Drupal.

If you are still unsure why Drupal is the best, read this article with more reasons that will convince you.

Breaking Down Today’s CMS Platforms (Infographic)

Below you’ll find an infographic that compares Drupal to the other platforms you’ll find in your search. For the reasons above, however, our team of OnBlastBlog recommends Drupal wholeheartedly.

 Drupal, WordPress, and Joomla

And which platform do you use? Let us know in the comments! 

Apr 21 2017
Apr 21

While working on a presentation for DrupalCon Baltimore, I was brainstorming various tactics and proposals for removing components and modules from Drupal core. The act of deleting something from core can, at first glance, seem simple, but it brings up a more interesting discussion.

First, some background

Earlier this year Dries Buytaert announced a change to the future backwards compatibility support for Drupal core. You can read more about the policy change in his post. To summarize, Drupal core will continue adding enhancements, marking replaced APIs as deprecated along the way. The next major version update of Drupal will simply be the removal of all the deprecated components.

Less than a month before this he also wrote about the opportunities prepackaged distributions present for Drupal 8. The new world of Composer-based dependency management is great for developers, but will become a new barrier to entry for beginners. The predefined packaging of distributions may be an important tool for combating this problem.

A clash of concerns

The real historical problem that has made the decision to add or remove components in Drupal core difficult is the dichotomy between Drupal as a framework and Drupal as a product. Framework advocates want a small, agile core focused on robust APIs that can advance at a faster pace. We’ve traditionally called this “small core.” Product advocates are focused on Drupal being a complete product for website building; with sensible defaults, out-of-the-box content modeling tools, and a plethora of features.

Let them eat cake, and have it, too

Is there a way to focus on the framework, but still provide the product-level utility that beginners, site builders, evaluators, and the like all need? Maybe.

Let’s give the small core crowd what they want and reduce Drupal core down to its core components and APIs. All the things subsystems need for Drupal to function, and only modules that the vast majority of sites will use and are fairly integrated into core; node, block, menu, field, views, etc. Everything removed will be put back into the contrib space, but maintained by the core commit team and component maintainers with the same high standards as core.

We then create an official, standard distribution that is prepackaged by drupal.org and pulls in all those additional components from the contrib space; themes, toolbar, forum, etc. This distribution would be maintained along with small core and be available on Drupal’s download page. (With small core available for download on its own.) The end result should be transparent to anyone downloading Drupal. The initial distribution would look exactly like Drupal 8 does right now.

Let small core focus on developer needs, and free up the distribution to focus on site builder and evaluator needs.

Here are some potential benefits I’ve been thinking about, most of which fall in line with the current direction of Drupal core:

  • Focus core on APIs
  • Allow developers that want to contribute to focus on those APIs, not product decisions.
  • Reduce some of the maintenance burden on core itself, or at least better segment it.
  • Moving most modules back to contrib would give component maintainers commit access to their modules and allow them to iterate and experiment.
  • Creating an official distribution separate from small core would let product managers, designers, and UX specialists focus entirely on Drupal the product; what modules and themes are included, default features, user testing, etc. (Something like the default content initiative would go right into the distribution, and never clutter core.)
  • Experimental modules/themes can be created in contrib first, and then when stable, added to the distribution via its composer file.
  • Small core would provide a small, vanilla starting point increasing the diversity and experimentation we might see with distributions; effectively removing all the unneeded components so builders can focus on what they want to add, not what they need to remove. The end result could be a wide range of Drupal “flavors” that look very different, but have the same core.

If you’d like to talk about this and the general topic of removing components from Drupal core, come to the Core Conversation session Peter Wolanin and I are having at DrupalCon Baltimore - Less is More - What Modules, Features, or APIs Should We Cut From Core?

Apr 21 2017
Apr 21

Drupal 8 promised to make website management a piece of cake, and it is fulfilling its promise! Indeed, it has plenty of useful modules to do this, like the Inline Entity Form to work with entities, the Group to manage group permissions, the Rules and the Workbench Moderation to optimize a website’s workflow, the Webform to build online forms, and many more. Today, we’ll discuss one of them that brings order to handling user roles and permissions — the User Personas module in Drupal 8, which is under active development right now.

The User Personas Drupal 8 module and its essence

Each of us has many roles in life, which may change with time. However, we are personalities above all, and we are unique. Although real life and Drupal websites are different things, this is close to the philosophy of the User Personas module in Drupal 8.

Drupal has user roles, which define who can do what on a certain site. The practice shows that the most frequently used Drupal website roles, assigned to almost anyone in any team, are Content Administrator and Content Editor. The difference is checking or unchecking certain permissions that are duplicated for every role.

The author of the User Personas Drupal 8 module, Gabe Sullice, decided to move beyond that approach. So his innovative module offers creating so-called User Personas and putting them above roles.

What is this for? This allows you to create more accurate sets of responsibilities that meet unique job descriptions for any team member. It also lets you avoid the muddle with duplicated permissions and enhances security. Let’s discover more details.

User personas: what they are and what they do

User personas are a level higher than roles — they are actually sets, or bundles, of roles. Each role, in its turn, comes equipped with its own set of permissions.

You can create personas and assign specific roles to them. Personas can refer to single users or their groups. In addition, different personas can share roles.

More accuracy due to treating roles as responsibilities

One of the most important points in the User Personas ideology is to stop treating roles as people’s jobs and start treating them as responsibilities instead. Roles should not describe who people are but rather what people do, i.e., they should be more specific and single-purpose.

OK, let’s imagine a persona called “Reader” and what they should be able to do. Logically, they should be allowed to read and probably comment on the content. So it’s worth giving them the “Viewer” and “Commentator” roles, which, in their turn, should include the permissions for viewing the comments, editing their own comments and posting their own comments. A very clean approach! This is an example Gabe Sullice gave in his article about the User Personas module (which he continued describing it in the new version of the article). He also suggested another helpful module to assign roles to new users called Auto Assign Role.

Putting an end to endless permission checkboxes

Working with traditional Drupal roles, a website administrator has the tedious task of managing checkboxes with permissions that have to be duplicated again and again. This involves security risks, makes bugs harder to find, and makes human error more likely to occur.

The User Personas module for Drupal 8 solves this issue and frees you from these endless checkboxes with permission duplicates. Permissions will be simply shared when sharing roles.

Better not try this on live websites ;)

User personas do not interfere with anything on your website: when a set of roles is assigned to a user entity, everything else can work as usual. However, you should not install user personas directly on a live website because the roles are reset then. Be careful with it.

That’s how the User Personas module in Drupal 8 works. Indeed, user personas are unique, and so is your Drupal website! Whatever you wish can be implemented there, with no limits and no exception. So don’t hesitate to contact us for help with installing and configuring some module, or creating a unique one from scratch. And, of course, you can have a new Drupal 8 website developed for you, or migrate your existing one to Drupal 8. Drop us a line! ;)

Apr 21 2017
Apr 21

The past weeks have been difficult. I'm well aware that the community is struggling, and it really pains me. I respect the various opinions expressed, including opinions different from my own. I want you to know that I'm listening and that I'm carefully considering the different aspects of this situation. I'm doing my best to progress through the issues and support the work that needs to happen to evolve our governance model. For those that are attending DrupalCon Baltimore and want to help, we just added a community discussions track.

There is a lot to figure out, and I know that it's difficult when there are unresolved questions. Leading up to DrupalCon Baltimore next week, it may be helpful for people to know that Larry Garfield and I are talking. As members of the Community Working Group reported this week, Larry remains a member of the community. While we figure out Larry's future roles, Larry is attending DrupalCon as a regular community member with the opportunity to participate in sessions, code sprints and issue queues.

As we are about to kick off DrupalCon Baltimore, please know that my wish for this conference is for it to be everything you've made it over the years; a time for bringing out the best in each other, for learning and sharing our knowledge, and for great minds to work together to move the project forward. We owe it to the 3,000 people who will be in attendance to make DrupalCon about Drupal. To that end, I ask for your patience towards me, so I can do my part in helping to achieve these goals. It can only happen with your help, support, patience and understanding. Please join me in making DrupalCon Baltimore an amazing time to connect, collaborate and learn, like the many DrupalCons before it.

(I have received a lot of comments and at this time I just want to respond with an update. I decided to close the comments on this post.)

Apr 21 2017
Apr 21

Drupal’s Extra Fields are a powerful tool for developers working with Entities. These non-editable fields allow developers to expose properties of their entities, and even properties of entities created by other modules, to the Field UI allowing site-builders to place the properties on the content creation form or in view modes on the Manage Display tab. There are times however when it’s helpful to allow more control of how these pseudo-fields are displayed when the content is rendered. We decided to create the Extrafield Settings module to give developers the ability to create settings forms for their extra fields that work in much the same way as formatter settings created with hook_field_formatter_settings_form()

To create a settings form, a developer only needs to define a `settings callback` property in their hook_field_extra_fields() definition that will return an array of renderable Form API components. These settings are stored with the extra field’s visibility setting and are easily accessed when the entity content is rendered allowing extra fields to react to the varying needs of different view modes. For example, a generated button or link could be configured to display different text, or in a different color in separate view modes, or markup can be added to wrap a property and adjusted in a streamlined and intuitive way. Check out the sample below for an example of adding some helpful options to a link:

/**
 * Implements hook_field_extra_fields().
 */
function hook_field_extra_fields() {
  $extra['entity_type']['bundle'] = array(
    'display' => array(
      'field_name' => array(
        'label' => 'Field Name',
        'weight' => 0,
        //
        // Below are the callbacks for extrafield_settings
        'callback' => 'example_field_name_render',
        'settings callback' => 'example_field_name_settings_form'
      ),
    ),
  );
  return $extra;
}
 
/**
 * Settings callback for example field.
 */
function example_field_name_settings_form($settings) {
  return array(
    'link_text' => array(
      '#type' => 'textfield',
      '#title' => isset($settings['link_text']) ? $settings['link_text'] : t('Click here'),
      '#description' => t('Link text for my custom link.'),
    ),
    'classes' => array(
      '#type' => 'textfield',
      '#title' => isset($settings['classes']) ? $settings['classes'] : '',
      '#description' => t('Classes to add to my custom link.'),
    ),
  );
}
 
/**
 * Render callback for example field.
 */
function example_field_name_render($entity, $type, $view_mode, $settings) {
  $text = isset($settings['link_text']) ? $settings['link_text'] : t('Click here');
  $classes = isset($settings['classes']) ? $settings['classes'] : '';
 
  return array(
    '#theme' => 'link',
    '#title' => $text,
    '#path' => entity_uri($type, $entity),
    '#options' => array(
      'attributes' => array('class' => $classes),
      'html' => FALSE,
    ),
  );
}

As shown above, Extrafield Settings also adds support for an optional callback that will be executed when an extra field is visible on an entity being rendered, and supplied with information about the entity and display settings for the field. If you want to retain complete control over rendering your field, skip the callback and grab the field settings with field_info_extra_fields(). To learn more and download the Extrafield Settings module check out the project page on drupal.org. Drupal 8 version coming soon!

Apr 21 2017
Apr 21

Install Drupal 8 from Configuration CMIWouldn't it be great if???

Configuration management is one of the most useful site development features in Drupal 8. It makes a site's configuration exportable, importable and manageable in git. Whilst building the configuration management feature, a thought that often occurred was "Wouldn't it be great if you can take an existing set of configuration and install a new site from it?". Every Drupal developer has turned up to a new project and had to learn a different way to build a development site. Do you get the code from github? Download a database from production or some other special location? And is that database sanitised? I often wonder how many Drupal developers there are in the world wandering around with production databases on their laptops.

We started to explore the ability to install from configuration in https://www.drupal.org/node/1613424. Why hasn't this made it into Drupal 8 yet? It transpires that changing the installer is hard and it was not a top priority in the run up to the 8.0.0 release. To fix the feature gap, I created the contrib project Configuration Installer. This is a special installation profile that allows you to install from a configuration export.

So problem solved in contrib right? Well, no. Profiles are special weird magic modules. They can do everything a module can do and more. But things don't work the same. You can uninstall the Contact module after installing the Standard profile even though the contact module is listed as a dependency. This causes problems for the Configuration Installer because Standard's hook_install() implementation will error if Contact is not installed. The Configuration Installer can work around that with ugly code but its luck runs out if the install profile has custom or contrib modules included. In order to work, the Configuration Installer swaps the currently active profile during install so Drupal can't find modules or themes buried inside the install profile.

Your site's install profile could contain all the configuration

In an ideal world, I want to get a project's code and use the Drupal installer to select install profile for the site I'm working on and and install it. I want to make some configuration changes, export them, and commit them to git. I want to throw away that site and forget about it. I want to come back six months later and update the code, re-install a fresh site that includes any changes other developers made in the meantime, and continue to work on the site. All without having to think particularly hard. I want to use the standard Drupal tools like the installer, configuration admin UI, and Drush.

The good news is that we can have all this! This is precisely what the patch available at https://www.drupal.org/node/2788777 does. We can change the installer to read from its config/sync directory and run a configuration import instead of the regular install. It builds on the Configuration Installer project but does not require the magic of swapping around the profile, so is much more robust. The final piece of the puzzle is to change the configuration sync directory to the profile's config/sync in settings.php, and it just works. As a happy developer said trying out this for the first time:

I love this workflow :)

How to have a rebuildable and reinstallable Drupal today!

  1. Use https://github.com/drupal-composer/drupal-project to manage your codebase using composer.
  2. Use https://github.com/cweagans/composer-patches to apply the latest patch on https://www.drupal.org/node/2788777 as part of composer install.
  3. Create an install profile with a config/sync directory. The new Install Profile Generator module can do this for you with a simple Drush command.

Now I can update my install profile after making configuration changes by running drush config-export. I can share those changes by pushing the install profile. I can pull in changes from other developers by pulling and running drush config-import. I can rebuild the site from scratch by checking out the codebase and running drush site-install.

Afterthoughts

If you are thinking "Wouldn't it be nice if we could also create some content at the same time?" have a look at the Default Content project. You will need the patch from https://www.drupal.org/node/2833562.

If you are wondering whether applying a patch to core is safe - in this instance I would argue it really is. The only changes the patch makes are to the installer and makes no runtime changes.

Isn't the obfuscated config sync directory generated by core important? Well I'm not a big believer in security through obscurity. But also if you are using Apache then core checks for the presence of a .htaccess in your config sync directory that should prevent access. Other webservers should also be denying access to .yml files by default too.

Further reading

Thanks

Eli-T for helpful suggestions on this blogpost and working with me on the Install Profile Generator.

Catch for helpful suggestions on this blogpost.

Apr 20 2017
Apr 20

I hope you will be attending DrupalCon 2017 next week in Baltimore. This a great opportunity to update your Drupal knowledge and network with others. It’s also your chance to sign up for a special, two-hour training session on Drupal 8 SEO which is free to Drupalcon attendees.

I will be holding a Drupal 8 SEO Hands-On Seminar beginning at 15:45 on April 25 in room 321 at the Baltimore Convention Center. We will do the most important on-page optimizations that I’d execute for a Volacci SEO client. We’ll cover specific details that marketers should know to achieve SEO results with Drupal 8 with minimal need for developer help.

In addition, everyone who attends will receive a free electronic copy of my latest book, Drupal 8 SEO. This book is a step-by-step guide for ranking high in search engines with professional tips, modules, and best practices for Drupal 8 web sites.

Search Engine Optimization is a key part of the success of any Drupal website. With recent releases, Drupal 8 is ready for the SEO prime-time, but it can be difficult to know which modules to use and exactly how to configure them. This course will take the mystery out of Drupal 8 SEO.

In the hands-on portion of the class, you can optimize your very own website. Following Volacci’s Drupal SEO guidelines, the end-result will be a website that ranks better in search engine results, creates more leads and drives more revenue. If you want to do the hands-on portion of this class, you must bring your own dev environment. It can be your own Drupal website or a test website. Get the details here.

See you at DrupalCon!

Apr 20 2017
Apr 20

Drupal Modules: The One Percent — Toolbar Menu (video tutorial)

[embedded content]

Episode 26

Here is where we bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll investigate Toolbar menu, a module which allows you to add menus to your toolbar.

Apr 20 2017
Apr 20

Open conversation is essential to the wellbeing of any community. It is especially important now, as we collaboratively determine how to evolve our governance.

This discussion thread is being posted as a place for ongoing conversation about recent community issues and the governance improvements that the community is collaborating on together.

For background information on additional conversations being held, we direct you to:

https://www.drupal.org/community/discussions

...which has links to open community discussion sessions to be held at DrupalCon Baltimore, and that are being held virtually. After those sessions are completed, minutes will be posted to page above.

We encourage you to join us at those community discussions if you are able, and/or to continue the discussion here.

Apr 20 2017
Apr 20
Matt and Mike sit down with several Lullabots who are presenting at Drupalcon Baltimore. We talk about our sessions, sessions that we're excited to see, and speaking tips for first-time presenters.
Apr 20 2017
Apr 20

In the last post in this series, we set up some routing for our module for three paths. One of those paths is to the module's main configuration form. Since this module has a Drupal 7 version, I am going to go by the old tried and true method of CDD, a.k.a Copy Driven Development. Copy, paste, cry, try to copy something else.

By the end of this post, we will have a proper configuration form that loads and saves values correctly. My form will need to interact with users and roles, but we will dip our toes into those Drupal sub-systems another time.

Form API in D8

Luckily for all of you hardcore D7 devs out there, the way forms are built in Drupal 8 hasn't changed as much as other systems, like routing, have changed.

The first thing I had to change was the "#default_value" key on my form items. Most of the time I used "variable_get()" to set default values, and as you've probably seen a thousand times already, that function has been deprecated.


// Old code...
variable_get('user_external_invite_days_valid_for', 5);

// New code...
$config = $this->config('user_external_invite.settings');
$config->get('user_external_invite_days_valid_for');

Default values are now stored in your config directory, which for me was "config/install/user_external_invite.settings.yml" from my module's root directory. All of your default values end up being plugged into that YAML file as you'd think they would.

Since my YAML experience is limited, I ran into an issue with a multi-line string I needed to enter. When trying to add the string as I had it in Drupal 7, wrapped in quotes and using default line breaks instead of "\n", I got an error when trying to install the module. StackOverflow came to the rescue once again, and while I think the syntax is a bit wonky, I can now add multi-line strings without breaking formatting.  


user_external_invite_days_valid_for: 5
user_external_invite_delete_old_invites: 2592000
user_external_invite_no_query_params: FALSE
user_external_invite_use_universal_from_email: FALSE
user_external_invite_universal_from_email:
user_external_invite_confirmation_template: |
  [user_external_invite:invite_custom]

  You have been invited to join the [site:name] website as a user with [user_external_invite:invite_role] access privileges.

You essentially just use the pipe symbol and have to make sure the multi-line string is indented two spaces from its parent YAML key.

Element Validation Handlers

I ran into another issue with a "#element_validate" key on a form element. In Drupal 7 if you need to check and see if a user entered a number, you could use a core function to do so without needing to add a custom validation handler. 


// Days invite valid for.
$form['user_external_invite_days_valid_for'] = array(
  '#type' => 'textfield',
  '#title' => t('Number of days invites are valid'),
  '#description' => t("Invites are set to expire so many days after they are created. If a user hasn't accepted the invite by that time, then you will have to send a new invite to grant that user a role."),
  '#default_value' => variable_get('user_external_invite_days_valid_for', 5),
  '#element_validate' => array('element_validate_number'),
  '#maxlength' => 3,
);

The "element_validate_number()" function was included in Drupal 7 core along with several other validation functions. If you wanted to create a custom function, you could add it in just like a submit handler. "element_validate_number" becomes "your_validation_function", and you place your validation function somewhere around your form definition. 

In Drupal 8, you need to make a slight change to how you declare custom validation handlers for elements.


// Drupal 7...
'#element_validate' => array('element_validate_number'),

// Drupal 8...
'#element_validate' => array(array($this, 'elementValidateNumber')),

In Drupal 8, you need to use a valid callback for your validation handler to work. When a user submits the form, the "call_user_func_array(callable $callback , array $param_arr )" function is called. The array within the array syntax is used to be able to call a function within a class. Since our validation function exists within our own form class, we can pass in "$this" and then the function we are calling. It is also possible to pass in another external class where your validation function might live. You can read the change record for more information and discussion on form handler changes in Drupal 8.  

For my specific case, these validation handlers aren't even needed. Since I'm wanting the user to only enter numbers, I can use the new "number" type on the form element. Once the type is set to number, a user can't even enter letters or special characters: only numerals are allowed. The "#step" key allows you to specify what values you will accept. With that key set to "1", I can't enter "3.564" and get a nice warning message before submitting the form. You should use these new form elements over text fields whenever possible so that browsers can use built-in validation checking and element rendering.  


// Days invite valid for.
$form['user_external_invite_days_valid_for'] = array(
  '#type' => 'number',
  '#title' => t('Number of days invites are valid'),
  '#description' => t("Invites are set to expire so many days after they are created. If a user hasn't accepted the invite by that time, then you will have to send a new invite to grant that user a role."),
  '#default_value' => $config->get('user_external_invite_days_valid_for'),
  '#min' => 1,
  '#step' => 1,
);

Submit Form Handlers

My next step is to save my form values so they can be used elsewhere and loaded as default values the next time the configuration form is loaded. Since "ConfigFormBase" already has a "submitForm(array &$form, FormStateInterface $form_state)" function, we can extend that to suit our purposes. 


  
  // Form definition code...
  
  // Submit button.
  $form['actions'] = ['#type' => 'actions'];
  $form['actions']['submit'] = [
    '#type' => 'submit',
    '#value' => $this->t('Save configuration'),
  ];

  return parent::buildForm($form, $form_state);
}

public function submitForm(array &$form, FormStateInterface $form_state) {
  $config = $this->config('user_external_invite.settings');
  $values = $form_state->getValues();

  // Loop through and save form values.
  foreach ($values as $key => $value) {
    // Since there are non-user input values, we need to check for the prefix
    // added to all variables to filter out values we don't want to save.
    if (strpos($key, 'user_external_invite') !== FALSE) {
      $config->set($key, $value);
    }
  }

  // Save form values to be loaded as defaults.
  $config->save();

  parent::submitForm($form, $form_state);
}

Getting the config object and form values is relatively straightforward; however, saving the values in a concise manner gets a little more involved. The values returned from "$form_state->getValues()" end up containing things like the submit object that you don't need or want to save as a value. Luckily for us procedural devs with habits of defensive function and variable naming, you can check for a prefix you placed on each variable and only save those values. Since I had prefixed my variables in Drupal 7, I didn't have to change much to save the values I cared about saving. 

Also to note, you don't need to declare "$form['actions']['submit']" for the submit button to show up because it is added by the parent function. It is always good to check what the parent function does when you are yielding control back to it. 

You should now be able to define form elements, create custom validation handlers, and save values in a standard submit handler. For most configuration forms, this is all the code knowledge you will need. For more information, please read the Drupal 8 introduction to the Form API.  

Apr 20 2017
jam
Apr 20
To me, meeting and building relationships in person is the glue that holds us together and makes Drupal a community. If this is your first DrupalCon or first Drupal community event, it’ll be your first taste of this crazy, smart bunch of people scattered around the globe most of the rest of the year. Welcome! I’d like to help you get the most out of your first DrupalCon!
Apr 20 2017
Apr 20

Dropcast: Episode 31 - DRUPALCON

Dropcast: Episode 31 - DRUPALCON

Recorded April 12th, 2017

Yes once again, folks, the wonderful DrupalConNA is happening in shiny Baltimore MD, and we have special guest, Heather Rodriguez (@hrodrig) from Civic Actions joins us to talk about the events of Drupalcon and to talk about her talk on Concurring Imposter's Syndrome. As always, we have some Drupal News, a couple of Pro Project Picks, and with Ryan unable to join us, Bob takes over the Final Bell.


Episode 31 Audio Download Link

Updates:

Interview Heather Rodriguez

  1. Tell us about yourself.

  2. How did you get started with Drupal?

  3. Tell us about your upcoming session at Drupalcon.

  4. What was the outcome of last year’s BADCamp FE Summit?

  5. Are there plans to do it again this year?

Drupal News:

Pro Project Pick:

MAIL DROP

Events:

The Final Bell:

Apr 20 2017
Apr 20

Speak out about your feelings on several topics that are swirling in the Drupalsphere. The results of the poll will be published here during Drupalcon Baltimore. 

Take the Poll!

Tags: Drupal Planet
Apr 20 2017
Apr 20

Many Drupal 7 sites relied upon hook_boot and hook_init for critical functionality that needed to be executed on every page, even pages cached by Drupal. Oftentimes these hooks were incorrectly used and an alternate approach would have been much more performant by triggering logic exactly where it was needed instead of on every page. For example, drupal_add_js could be used to add JavaScript for a particular block or theme hook globally, but using a targeted preprocess function is often the correct approach. However, in some cases, these hooks were indeed the correct solution. Both hook_boot and hook_init were deprecated in Drupal 8, so an alternate approach will be needed.

Cacheable Logic

In Drupal 7, hook_init offered a hook that was fired on every page that Drupal did not cache. Drupal 8 offers this same functionality, using the Event Subscriber pattern as detailed on the hook_init change notice. These pages provide detailed examples, which walk you through the process of setting one up. How to Register an Event Subscriber in Drupal 8 also provides examples of event dispatching code.

Uncacheable Logic

Uncacheable logic should seldom be needed, as the solution is often to use proper cache settings on your render arrays. In the rare case that it is indeed needed, there are two viable options depending on the situation.

Using settings.php

The change notice page states:

A module that needs to run on cached pages should prompt its users to add code in settings.php

Note that Services are not instantiated yet when this code runs, thus severely limiting the available functionality. So while this approach is by no means ideal, it is available. The StackMiddleware approach below is a better approach that offers deeper integration with Drupal functionality.

Using StackMiddleware

This comment on the hook_boot change notice page provides an example of using StackMiddleware. It provides 95% of the functionality needed to run logic on cached pages by utilizing a tagged service with the http_middleware tag. Since the new class is a service, it will have full access to other core and contrib services, allowing for much greater functionality. The example shows the following for a module’s *.services.yml file:

services:
  http_middleware.mymodule:
    class: Drupal\mymodule\StackMiddleware\MyModule
    tags:
      - { name: http_middleware, priority: 180, responder: true }


This is a pretty standard service definition, but note the items added to the tags property that register our service with the http_middleware tag and also set a priority. In order to bypass the page cache, understanding the page_cache.services.yml file is helpful. There, a similar definition can be found, but with a higher priority value.

services:
  http_middleware.page_cache:
    class: Drupal\page_cache\StackMiddleware\PageCache
    arguments: [[email protected]', [email protected]_cache_request_policy', [email protected]_cache_response_policy']
    tags:
      - { name: http_middleware, priority: 200, responder: true }


Higher priority services are run first. So to trigger logic before the page cache module takes over the request, a priority greater than 200 is needed.

services:
  http_middleware.mymodule:
    class: Drupal\mymodule\StackMiddleware\MyModule
    tags:
      - { name: http_middleware, priority: 210, responder: true }

With this change in the services files, and proper setup of the service as described by the comment, the http_middleware.mymodule service should now be called on every page load, even on fully cached pages.

namespace Drupal\example\StackMiddleware;

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpKernel\HttpKernelInterface;

/**
 * Performs a custom task.
 */
class ExampleStackMiddleware implements HttpKernelInterface {

  /**
   * The wrapped HTTP kernel.
   *
   * @var \Symfony\Component\HttpKernel\HttpKernelInterface
   */
  protected $httpKernel;

  /**
   * Creates a HTTP middleware handler.
   *
   * @param \Symfony\Component\HttpKernel\HttpKernelInterface $kernel
   *   The HTTP kernel.
   */
  public function __construct(HttpKernelInterface $kernel) {
    $this->httpKernel = $kernel;
  }

  /**
   * [email protected]}
   */
  public function handle(Request $request, $type = self::MASTER_REQUEST, $catch = TRUE) {
    // Custom logic goes here.

    return $this->httpKernel->handle($request, $type, $catch);
  }
}


Verifying the Results

A quick and easy way to test all of this is to simply add \Drupal::logger('test')->notice(‘not cached’); into the functions triggered by each of the approaches above. Ensure that the Drupal cache is enabled, and simply refresh a page while watching your log (drush ws --tail). Then verify the logic is being called as expected.

Apr 20 2017
Apr 20

Entity Views Attachment, or EVA, is a Drupal module that allows you to attach view displays to entities of your choosing. We used it recently on a project and loved it. You know it’s good because it has a no-nonsense name and an even better acronym. (Plus, the maintainers have taken full advantage of the acronym and placed a spaceman on the project page. Nice!)

Since the now-ubiquitous Paragraphs module provides the “paragraph” entity type, I figured these two will make good dancing partners.

Getting them to tango is simple enough. You create a paragraph bundle, target that bundle in the settings on an EVA view display, then arrange the view in the paragraph’s display settings. Voila – your view display shows up wherever you add this paragraph!

By attaching a view display to a paragraph entity and enabling that paragraph on a node’s paragraph reference field, you give your content editors the ability to place a view wherever they want within their page content. Better still, they can contextualize what they are doing since this all happens in the edit form where the rest of the node content lives. As far as I can tell, no other approach in the Drupal ecosystem (I’m looking at you Blocks and Panels) makes adding views to content this easy for your editors.

Case Study

The concept is pretty straightforward, but with a little cleverness it allows you to build some complex page elements. Let’s walk through an example. Consider the following design:

This mockup represents Section nodes and lists of Subpage nodes that reference them. In addition, the buttons links should point to the parent Section node. With a little elbow grease, we can build a system to output this with our friends EVA and Paragraphs.

Here’s how I’m breaking this down conceptually:

We have three things to build:

  1. A create a container paragraph bundle

  2. A child paragraph bundle with a Section entity reference field

  3. An EVA of subpages to attach to the child paragraph bundle

Building the Subpage EVA

As I mentioned before, Subpage nodes will reference Section nodes. With this in mind, we can build the EVA that lists subpages and expects a section node ID to contextually filter to subpages that reference that node.

Building the Section paragraph type

Next, we’ll create the Section paragraph type that will handle each grouping of a section node with its related subpages. The Section paragraph will have one field, an entity reference field limited to Section nodes, that gives us all the data we need from our section.

We’ll attach our EVA to this paragraph type and configure it to pass the referenced node’s ID as the contextual filter using tokens in the EVA settings. You will need to install the Token module to do this. Go to /admin/help/token to see all available tokens once installed. You need to grab the node ID through your entity reference field, so your token argument should look something like this:

[paragraph:field_node_reference:entity:nid]

We pass that token to our contextual filter, and we can tell our view to use that argument to create a link to the section node for our “View All Subpages” link. To do this, we’ll add a global text area to the view footer and check the “Use replacement tokens from the first row” checkbox. Then we’ll write some HTML to create a link. It’ll look something like this:

<a href="https://www.zivtech.com/node/{{ raw_arguments.nid }}">View all Subpages</a>

Building the Section List paragraph type

Lastly, we’ll create the Section List paragraph type. This only really needs a paragraph reference field that only allows the user to add Section paragraphs, but I also added a title field that will act as a header for the whole list.

Tip: Install Fences module to control your field’s wrapper markup. I used this here to wrap the title in <h2> tags.

We’re finished!

Now that everything is built, we can allow users to select the Section List paragraph type in a paragraph reference field of our choosing. A user adds a Section List, then adds Sections via the entity reference. It looks like this in the node edit form:

Do you have any cool ways you use the EVA module in your builds? Let us know in the comments section below.

Apr 20 2017
Apr 20

In my last post, I showed you how to migrate translated content from Drupal 6 to Drupal 8. But clients often don't start with their data in Drupal 6. Instead there's some other source of data that may include translations, like a CSV spreadsheet. In this article, I'll show you how to migrate multilingual content from such sources to Drupal 8.

This article would not have been possible without the help of my colleague Dave. Gracias Dave!

The problem

We have two CSV files containing some data about chemical elements in two languages. One file contains data in English and the other file, in Spanish. Our goal is to migrate these records into a Drupal 8 website, preserving the translations.

Before we start

  • Since this is an advanced migration topic, it is assumed you already know the basics of migration.
  • To execute the migrations in this example, you can download the migrate example i18n. The module should work without any trouble for a standard Drupal 8 install. See quick-start for more information.

Migrating JSON, XML and other formats

Though this example shows how to work with a CSV data source, one can easily work with other data sources. Here are some quick pointers:

  • Find and install the relevant migrate source module. If you do not have a standard source module available, you can:
    • try converting your data to a supported format first.
    • write your own migration source plugin, if you're feeling adventurous.
  • Modify the migration definitions to include custom parameters for the data source.
  • Some useful source formats are supported by these projects:

The module

To write the migrations, we create a module—in our case, it is named migrate_example_i18n. There's nothing special about the module declaration except for the dependencies:

How to migrate translations

Before we start writing migrations, it is important to mention how Drupal 8 translations work. In a nutshell:

  • First, we create content in its base language, say in English. For example, we could create a brand new node for the element Hydrogen, which might have a unique node ID 4.
  • Now that the base node is in place, we can translate the node, say to Spanish. Unlike some previous versions of Drupal, this won't become a new node with its own node ID. Instead, the translation is saved against the same node generated above, and so will have the same node ID—just a different language setting.

Hence, the migration definition for this example includes the following:

  • We migrate the base data in English using in example_element_en migration.
  • We migrate the Spanish translations using the example_element_es migration, and link each translation to the original English version.
  • We group the two migrations in the example_element migration group to keep things clean and organized.

Thus, we can execute the migrations of this example with the command drush migrate-import --group=example_element.

Warning

Note that this plan only works because every single node we are importing has at least an English translation! If some nodes only existed in Spanish, we would not be able to link them to the (non-existent) original English version. If you encounter data like this, you'll need to handle it in a different way.

Step 1: Element base migration (English)

To migrate the English translations, we define the example_element_en migration. Here is a quick look at some important parameters used in the migration definition.

Source

source:
  plugin: csv
  path: 'element.data.en.csv'
  header_row_count: 1
  keys:
    - Symbol
  fields:
    Name: 'Name'
    Symbol: 'Symbol'
    'Atomic Number': 'Atomic number'
    'Discovered By': 'Name of people who discovered the element'
  constants:
    lang_en: en
    node_element: 'element'
  • plugin: Since we want to import data from a CSV file, we need to use the csv plugin provided by the migrate_source_csv module.
  • path: Path to the CSV data source so that the source plugin can read the file. Our source files for this example actually live within our module, so we modify this path at runtime using hook_migration_plugins_alter() in migrate_example_i18n.module.
  • header_row_count: Number of initial rows in the CSV file which do not contain actual data. This helps ignore column headings.
  • keys: The column(s) in the CSV file which uniquely identify each record. In our example, the chemical symbol in the column Symbol is unique to each row, so we can use that as the key.
  • fields: A description for every column present in the CSV file. This is used for displaying source details in the UI.
  • constants: Some static values for use during the migration.

Destination

destination:
  plugin: 'entity:node'
  • plugin: Nothing fancy here. We aim to create node entities, so we set the plugin as entity:node.
  • translations: Since we are importing the content in base language, we do not specify the translations parameter. This will make Drupal create new nodes for every record.

Process

process:
  type: constants/node_element
  title: Name
  langcode: constants/lang_en
  field_element_symbol: Symbol
  field_element_discoverer:
    plugin: explode
    delimiter: ', '
    source: Discovered By

This is where we map the columns of the CSV file to properties of our target nodes. Here are some mappings which require a special mention and explication:

  • type: We hard-code the content type for the nodes we wish to create, to type element.
  • langcode: Since all source records are in English, we tell Drupal to save the destination nodes in English as well. We do this by explicitly specifying langcode as en.
  • field_element_discoverer: This field is a bit tricky. Looking at the source data, we realize that every element has one or more discoverers. Multiple discoverer names are separated by commas. Thus, we use plugin: explode and delimiter: ', ' to split multiple records into arrays. With the values split into arrays, Drupal understands and saves the data in this column as multiple values.

When we run this migration like drush migrate-import example_element_en, we import all the nodes in the base language (English).

Step 2: Element translation migration (Spanish)

With the base nodes in place, we define a migration similar to the previous one with the ID example_element_es.

source:
  plugin: csv
  path: 'element.data.es.csv'
  header_row_count: 1
  keys:
    - 'Simbolo'
  constants:
    lang_en: en
  # ...
destination:
  plugin: 'entity:node'
  translations: true
process:
  nid:
    plugin: migration
    source: Simbolo
    migration: example_element_en
  langcode: constants/lang_es
  content_translation_source: constants/lang_en
  # ...
migration_dependencies:
  required:
    - example_element_en

Let us look at some major differences between the example_element_es migration and the example_element_en migration:

  • source:
    • path: Since the Spanish node data is in another file, we change the path accordingly.
    • keys: The Spanish word for Symbol is Símbolo, and it is the column containing the unique ID of each record. Hence, we define it as the source data key. Unfortunately, Drupal migrate support keys with non-ASCII characters such as í (with its accent). So, as a workaround, I had to remove all such accented characters from the column headings and write the key parameter as Simbolo, without the special í.
    • fields: The field definitions had to be changed to match the Spanish column names used in the CSV.
  • destination:
    • translations: Since we want Drupal to create translations for English language nodes created during the example_element_en migration, we specify translations: true.
  • process:
    • nid: We use the plugin: migration to make Drupal lookup nodes which were created during the English element migration and use their ID as the nid. This results in the Spanish translations being attached to the original nodes created in English.
    • langcode: Since all records in element.data.es.csv are in Spanish, we hard-code the langcode to es for each record of this migration. This tells Drupal that these are Spanish translations.
    • content_translation_source: Each translation of a Drupal node comes from a previous translation—for example, you might take the Spanish translation, and translate it into French. In this case, we'd say that Spanish was the source language of the French translation. By adding this process step, we tell Drupal that all our Spanish translations are coming from English.
  • migration_dependencies: This ensures that the base data is migrated before the translations. So to run this migration, one must run the example_element_en migration first.

Voilà! Run the Spanish migration (drush migrate-import example_element_es) and you have the Spanish translations for the elements! We can run both the English and Spanish migration at once using the migration group we created. Here's how the output should look in the command-line:

$ drush migrate-import --group=example_element
Processed 111 items (111 created, 0 updated, 0 failed, 0 ignored) - done with 'example_element_en'
Processed 105 items (105 created, 0 updated, 0 failed, 0 ignored) - done with 'example_element_es'

If we had another file containing French translations, we would create another migration like we did for Spanish, and import the French data in a similar way. I couldn't find a CSV file with element data in French, so I didn't include it in this example—but go try it out on your own, and leave a comment to tell me how it went!

Next steps

Apr 20 2017
Apr 20

Advisory by the Drupal security team

Recently, the References module started receiving some attention (read here, here and here). The reason for this is that the Drupal security team posted an advisory to migrate away from the References module for Drupal 7 and move to the entity_reference module. At the time of writing (20 April), 121.091 sites are actively reporting to Drupal.org that they are using this module. That makes for a lot of unhappy developers.

Things kicked off after a security vulnerability was discovered in the References module. The security team tried to contact the existing maintainers of that module, but there was no response. The security team had no choice but to mark the module as abandoned and send out the following advisory explaining that the details would be made public in a month and that everyone should upgrade, as there was no fix available.

Migrate efficiently

At Dropsolid, we noticed that for many of our older Drupal 7 installs we were still using this module extensively. Migrating all of the affected sites would have meant a very lengthy undertaking, so I was curious to find a way to spend less time and effort while still fixing the problem. We immediately contacted one of the people who reported the security issue and tried to get more information other than what was publicly available. That person stayed true to the rules and did not disclose any information about the issue.

We didn’t give up, but made an official request to the security team offering to help and requesting access to the security vulnerability issue. The Drupal security team reviewed the request and granted me access. In the Drupal Security issue queue there was some historical information about this vulnerability, some answers and a proposed patch. The patch had not been tested, but this is where Dropsolid chimed in. After extensively testing the patch on all the different scenarios on an actual site that was vulnerable, we marked the issue as Reviewed and Tested by the Community (RTBC) and stepped up maintain the References module for future security issues.

It pays off to step in

I’d like to thank Niels Aers, one of my colleagues, as his involvement was critical in this journey and he is now the current maintainer of this module. He jumped straight in without hesitation. In the end, we spent less time fixing the actual issue compared to the potential effort for changing all our sites to use a different module. So remember: you can also make a similar impact to the Drupal community by stepping up when something like this happens. Do not freak out, but think how you can help your clients, company and career by fixing something for more than just you or your company.

Apr 20 2017
Apr 20

As part of our work to make Drupal 8 the leading CMS for developer portals, we are implementing a mechanism to import the OpenAPI (formerly known as Swagger) specification format. This is a crucial feature not only for dedicated developer portals, but also for all Drupal sites that are exposing an API. Now that it has become much easier to create a RESTful API service in Drupal 8, the next step is to make it more straightforward to create its API reference documentation. That is why we think our work will be useful for site builders, and not just for technical writers and API product owners.

Swagger is a REST API documentation tool, it provides a specification language for describing the APIs and also a set of support tools. One of those tools is Swagger UI, which generates an appealing and readable layout for API endpoints and methods. The Drupal community is considering using the Swagger specification to document Drupal 8 core web services, and Swagger tool adaptations can be found in several contributed modules. In this blogpost we will introduce some of these modules and explain how we want to go beyond the shallow integration that most of them have done, to take full advantage of Drupal’s architecture. But before diving into the technical details, we want to list the features that we seek in the ultimate API reference CMS.

6 features that make the difference between a good and a great API reference system

The following are 6 technical developer portal features that customers have requested from us in the past 2 years working with Apigee’s developer portal. They provide functionality that go beyond what most API management platforms provide.

overview dev portal components

For an overview of other Developer Portal components (besides the API reference), check out our blog post series on this topic.

Read more

This feature list is based on our investigations of existing developer sites, our practical experience from creating developer portals and architecture workshops we’ve held.

1. Storing multiple API versions: versioning

As API services can have multiple supported versions (e.g. v1, v2) in parallel, a Developer Portal should provide a clear user experience that gives visitors the option to choose which version they would like to read about (but still default to the latest supported stable one).

2. Track changes in the documentation of each API version: revisioning

Most developer portal platforms rebuild the documentation as part of an automated build process, Drupal’s revisioning system allows editors and site maintainers to make and track changes in specific versions of the API documentation. While this is less important for the developers that use the documentation, it is an editorial feature that can be useful for technical writers and site owners.

3. Possibility to attach conceptual content to the API reference

API references are very technical and factual. Sometimes developers need more verbose documentation that provides a longer explanation of the context an API operates in. That is why, several of our customers have asked us to add conceptual documentation to their imported content - about domain language, underlying architecture, data models, or code samples that surround an API call.

4. Access control for individual API methods

In order to restrict the visibility of certain API methods (e.g. for partner APIs), a Developer Portal must allow site maintainers to set granular access permissions/restrictions for specific versions, endpoints or other parts of the documentation.

5. Trying out API calls on the Developer Portal’s UI

Integrating a system with an API service can be accelerated by a Try it out feature, that helps developers to decide which API endpoint with what parameters to use in order to get the expected result.

6. Importing reference documentation from a version control system

Recently technical writers have also started using the online collaboration and versioning tools that developers work with. Documentation is now often committed into code repositories, especially when developers contribute to the writing process. One key problem with this approach is that, apart from the API reference documentation where most teams use the Swagger specification, there is no obvious standard to store the content and layout of documentation. We’ve been working with markdown topics, and manifest files to allow technical writers to store conceptual documentation and their navigation structure (what we used to organize in a book hierarchy in Drupal) separate from the API specification. This way all the documentation can be stored in the version control system (e.g. a GitHub or GitLab repository).

Existing Swagger modules in Drupal

The Swagger API documentation toolset covers the entire publishing process: building (Swagger Codegen), documenting, and visualizing (Swagger Editor, Swagger UI). Existing Drupal modules typically focus on the building and visualization steps.

As usual Drupal.org has some modules that seem to be abandoned, but there are two Swagger docs related modules that have been maintained in the past year. One is the Swagger UI Field Formatter module, it renders fields with valid Swagger source file using the Swagger UI tool. The other is Swagger php module (sandbox only), it can generate JSON formatted Swagger code based on annotations and it can render that code using the Swagger UI.

Both of these modules use the Swagger UI project to generate a human readable output from the specification. Swagger UI only needs a valid source file to generate the output and the ‘Try it out’ section (for sending requests to the endpoints); it is useful if you only need to publish the content, but it has its limitations.

Free and Open Source API Documentation Tools

If you are interested in other free and open source API documentation generators, check out our blog post about other solutions.

Read more

The problem we see with this solution and most other API documentation tools is that API providers usually need access control, search, and conceptual documentation for their API descriptions. These functions demand a different approach.

Don’t just show it, integrate it!

After careful evaluation, we came to the conclusion that the currently existing Swagger tools can’t support the 6 advanced API documentation features our customers request from us. To make the API documentations fieldable, revisionable and to be able to apply custom access control on all components of them in Drupal, a more robust API integration is needed. No open-source module is available for Drupal 8 that does this, so we decided to make it a key contribution we would work on with our team.

Since there are other specification languages (such as RAML or I/O Docs) that are widely used and that store similar information as the OpenAPI format, we take great care to make sure that our architecture would be extendable and reusable.

Mapping Swagger objects into Drupal data types

To get a flexible system that can be extended and altered with proper Drupal 8 solutions, we designed custom Drupal 8 entities and field types for every piece of a Swagger source file. The first step was to observe the individual Swagger specification elements and to decide the most suitable Drupal 8 data types for storing them.

We just finished the planning phase of the entity architecture, the overall structure won’t change much, but there might be some small changes during the implementation period.

The below image describes a small part of the planned entity architecture. We defined a vendor independent API documentation as a content entity (basically the root entity) which might have bundles, providing the ability to extend the base system with vendor specific formats other than Swagger (e.g. I/O Docs or Raml). Based on this concept, each specification language format makes a new bundle with vendor specific fields. By default the Swagger 2.0 specification format bundle is provided. Each piece of content in a bundle represents a different API version, so multiple versions (e.g. v1, v2) can be made available in parallel on the Developer Portal (feature 1).

API documentation

type: content entity

has bundles: yes

label: string

version: string

...

endpoints: ER list (endpoint)

security schemes: ER list (security scheme)

[Not supported by viewer] Swagger 2.0

type: entity bundle

parent: API documentation

description: string

...

[Not supported by viewer] Consumes

type: trait

consumes: ER (MIME types)

[Not supported by viewer]

Uses

Uses Produces

type: trait

produces: ER (MIME types)

[Not supported by viewer]

Uses

Uses MIME types

type: vocabulary

Terms: application/json, application/xml, ...

[Not supported by viewer]

References

References

References

References Endpoint

type: content entity

has bundles: yes

URI: URI/string

[Not supported by viewer]

References

References

All of the documentation components are tied to the properties or references of an API documentation entity. For example API endpoints form another content entity type, which can get referenced from the root (API documentation) entity. Moreover, as we are planning to use fieldable entities, any additional information can be attached to them easily (feature 3).

Thanks to the OOP nature of Drupal 8, reusable properties and methods can be attached to entity classes through traits. For example, base field definitions of the consumes and the produces specification properties can be defined in traits and used in multiple entities, as they can be attached to the API documentation entity or to an API method/operation (overriding the default global settings of these properties). The consumes and the produces properties in the Swagger source are technically MIME types (such as application/json), so they can be collected into a vocabulary as taxonomy terms.

Thinking in traits will also enable us to extend the default API specification with custom properties (e.g. extend Swagger specification objects with ‘x-’ properties). Code snippets could for example be included for different programming languages (such as Java, PHP, Python), these might help the readers to understand the API reference.

With the above architecture we can map specification languages into a Drupal entity system where basic revisioning is supported by default (feature 2). Although custom access control can also be added to any type of entity and its fields (feature 4), it’s not as powerful as Drupal’s node access control system. There is already a Drupal core issue that tries to expand the node access grants system to a generic entity grants system, and we are trying to contribute to it while working on our Drupal Developer Portal.

Importing the data into the Drupal system

For the import process we leverage Drupal 8’s Migrate API to import any type of API specification formats to our custom entities and to store them in a unified way. Source files can be either uploaded in the UI or imported from a Github repository (feature 6) through a documentation importer that we are building to support editorial workflows that rely on code repositories and that automatically publish to Drupal as part of a continuous integration process.

If you are interested in our GitHub importer and Migrate processing solution, join our Developer Portal mailing list to receive notifications about blog posts on the subject.

Why Drupal?

We chose Drupal 8 as the framework for our Developer Portal, because it already had a large number of features that our customers need. With a 10 year long history in Drupal, we are obviously somewhat biased, but even if we disregard our prior expertise, we believe that Drupal is one of the best CMSs for building documentation and developer portals.

That is why we decided to extend the existing solutions, with a sufficiently complex system that would enable us to address all the needs our customers have. Some of our code is still in stealth mode, the developer portal market is a relatively small niche, and we need to make sure we can find a sustainable way to give back to the Drupal community. That is why in parallel to our development, we are working on a new business model for our distribution to make sure we will be able to continue sharing our work with the wider community. We are committed to the open source community and credo, but we want to prevent some of the failures we have seen with previous Drupal distributions, more about that in a later post...

Apr 20 2017
Apr 20

Vote Up/Down is a drupal module that uses Voting API to provide a way to vote.
These notes are about part of the history of the module, and the recent news about it, including a couple of releases!

A long time ago...

The project itself is really ancient, it started in 2006 by frjo, in Drupal 4.7, and the same code has evolved until Drupal 7.
I took co-maintainership of the project around 2009-2010, when I met with lut4rp, at the time the one maintainer of the project; who made a rewrite to modularize it at the start of 6.x-2.x.
At that time we were still using CVS officially (and some of us git locally), and we were thrilled to receive and integrate a patch from merlinofchaos, that extended the module a lot, and make it more maintainable.
With the past of the time, I became the only active maintainer of the module.

At the start I was pretty active as a maintainer there; but over the years, I have not been responsive enough, especially around the D7 port.
During that time the community provided several patches and finally amitaibu created a sandbox, that I end up integrating into the project.
Also, I managed to write another submodule, vud_field, in that process.
For me it was clear, I advocated to remove vud_node, vud_term, and vud_comment form the project in favour of vud_field.
From my perspective it was more beneficial: (a) vud_field provided mostly the same functionality on nodes, taxonomy terms, and comments; but also (b) provided voting on any entity, embracing D7 new APIs; and also (c) made things more maintainable.
Sadly, the removal did not happened at that time, and that was one of the reasons why D7 version was never out of alpha status.

Recent news

After quite some time of inactivity in vote_up_down, this January, I started to port the module to D8, but I only started: only 4 porting commits got into the new 8.x-1.x branch.

Then, I decided to add a GSoC project as student's suggestion to port Vote Up/Down to D8 for this year.

In preparation, this week I have branched out D7 into two different versions 7.x-1.x and 7.x-2.x, adding respective releases to make things more clear:

  • 7.x.1-x (with 7.x-1.0-beta1 release): It still keeps all submodules, but it is not planned to be maintained for much longer anymore. I applied there all related code pending about vud_node, vud_comment, and vud_term.
  • 7.x-2.x (with 7.x-2.0 release): Instead, it only contains vud and vud_field, and it is planned to be maintained as the stable branch. Sadly there in not a complete upgrade path neither from 6.x-2.x nor from 7.x-1.x, but I added some starting code to do that on the related issue #1363928, and maybe someone would like to continue that.

Hopefully one of the students proposing the port to Vote Up/Down to D8 gets accepted.
It will be great to see the module active again!

Apr 19 2017
Apr 19

I know quite a few developers that love Vim but think they have to use an IDE to be able to debug their applications. In this post I will show you how to set up Vim as a Xdebug client.

The Vdebug plugin for Vim provides a way to do debugging inside Vim using the tools that Vim provides to great advantage. As the project page says,

Vdebug is a new, fast, powerful debugger client for Vim. It's multi-language, and has been tested with PHP, Python, Ruby, Perl, Tcl and NodeJS. It interfaces with any debugger that faithfully uses the DBGP protocol, such as Xdebug for PHP.

In this post we will focus on PHP, and more specifically, Drupal.

Xdebug

The first step we must take is to confirm you have Xdebug working in your application. If you don't have Xdebug installed head over to their site and follow the installation guide. You don't have to do anything special in order to use Vdebug with your PHP application. . But, for sake of completeness here is an example Xdebug configuration we (Mediacurrent) use on all of our projects. We have standardized our local development work on the great Drupal VM project.


[XDebug]
zend_extension="/usr/lib/php5/modules/xdebug.so"
xdebug.coverage_enable=0
xdebug.default_enable=0
xdebug.remote_enable=1
xdebug.remote_connect_back=1
xdebug.remote_host=10.0.2.2
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_log=/tmp/xdebug.log
xdebug.remote_autostart=false
xdebug.idekey="PHPSTORM"
xdebug.max_nesting_level=256

Xdebug Helper for Chrome

The next step is to set up your browser to allow you to easily enable and disable Xdebug. To do this, I use the Xdebug helper for Chrome. It's much easier than setting up POST variables and cookies for each browser session. You will want to make sure your ` is set to match what you are using in xdebug on the server. that is PHPSTORM.

Vdebug Features

Now that we have Xdebug all squared learn about Vdebug. Just what can Vdebug allow you to do?

  • Set and toggle
  • Step through your code line by line.
  • Step over functions and methods.
  • Step into and out of functions and methods.
  • Run the application to the cursor.
  • Evaluate variables under the cursor at run time.
  • Navigate objects and arrays.
  • Evaluate code and display the result.

Installing Vdebug

If you don't already use a plugin manager for Vim I recommend you check out Vundle, but the way you install Vdebug has no affect on how you use it. I recommend that you follow the installation instructions on the Vdebug project page to get it set up.

Default Keybindings

For your convenience, I have listed the default key bindings for Vdebug below (I have changed the defaults in my own vimrc since I find them to be somewhat difficult to remember).

<F5>: start/run (to next breakpoint/end of script)
<F2>: step over
<F3>: step into
<F4>: step out
<F6>: stop debugging (kills script)
<F7>: detach script from debugger
<F9>: run to cursor
<F10>: toggle line breakpoint
<F11>: show context variables (e.g. after "eval")
<F12>: evaluate variable under cursor
:Breakpoint <type> <args>: set a breakpoint of any type (see :help VdebugBreakpoints)
:VdebugEval <code>: evaluate some code and display the result
<Leader>e: evaluate the expression under visual highlight and display the result

Using Vdebug

Note: during this screen cast I am using my own key bindings which I outline later in this post.

[embedded content]

Screen cast

Debugging Drupal in a Virtual Machine

If you only ever debug using your machine's native version of PHP you can skip this step. But if you need to connect to a server running your or you will need to do one more step to set up Vdebug. You need to tell Vdebug where your files are on your local file system and the server's files system. The reason you need to do this is because the file paths on your local machine and the server are most likely different. Let's look at an example.

" Mapping '/remote/path' : '/local/path'
let g:vdebug_options['path_maps'] = {
      \  '/var/www/drupalvm/web' : '/Users/kepford/Sites/someproject
      \  '/home/vagrant/docroot' : '/Users/kepford/Sites/anotherproject/docroot'
      \}

The first portion of the mapping is for the remote path /var/www/drupalvm/web. The second is for the local path /Users/kepford/Sites/someproject/web. That's all you have to do for remote debugging.

Customizing Vdebug

Now that we have everything set up let's talk about custom configuration. The default keybindings that ship with Vdebug may not suit your preferences. Personally, I try to come up with mnemonics for each Vim command and struggle to remember the correct function keys for Vdebug. The good news is it's easy to override the defaults in your .vimrc file. Here's an example of what I have done with my defaults.

let g:vdebug_keymap = {
\    "run" : "<Leader>/",
\    "run_to_cursor" : "<Down>",
\    "step_over" : "<Up>",
\    "step_into" : "<Left>",
\    "step_out" : "<Right>",
\    "close" : "q",
\    "detach" : "<F7>",
\    "set_breakpoint" : "<Leader>s",
\    "eval_visual" : "<Leader>e"
\}

Note: I have my <Leader> key set to be the space bar and find this is very productive.

You may not like my key mappings but they work for me. The rest of my configuration is fairly straight forward.

" Allows Vdebug to bind to all interfaces.
let g:vdebug_options = {}

" Stops execution at the first line.
let g:vdebug_options['break_on_open'] = 1
let g:vdebug_options['max_children'] = 128

" Use the compact window layout.
let g:vdebug_options['watch_window_style'] = 'compact'

" Because it's the company default.
let g:vdebug_options['ide_key'] = 'PHPSTORM'


" Need to set as empty for this to work with Vagrant boxes.
let g:vdebug_options['server'] = ""

Debugging the Debugger

If you encounter a problem getting Vdebug to work it's likely that you need to change a setting. But before you do that you should turn on debugging. Run the follow two commands to dump the output of the Vdebug log to a file.

:VdebugOpt debug_file ~/vdebug.log
:VdebugOpt debug_file_level 2

Then tail the output of this file like so, tail -f ~/vdebug.log as you start Vdebug and try to use it.

More reading

As with any good Vim plugin you can learn a lot more about how to use it by reading the help documentation at :help Vdebug.

Additional Resources
Loading and Rendering Modal Forms in Drupal 8 |Blog
Flag Migrations in Drupal 8 | Blog
Migration with Custom Values in Drupal 8 | Blog

Apr 19 2017
jam
Apr 19
If you’re coming to DrupalCon Baltimore and you’re curious about Acquia, there are a couple of ways to meet the company and see what we’re about beyond the marketing and sales efforts that get directed at potential clients. One great way is to come to our sessions!
Apr 19 2017
Apr 19

We’re packing our bags for Baltimore and polishing up our slide decks for DrupalCon! We’re so excited to join the Drupal community for a full week of Drupal-y things. We’ve got some great content planned for this year’s conference, and we’re very excited to share it with you all - here’s what you need to know:

Exhibit Hall

The ThinkShout Headquarters this year is booth 432! We’ll be giving away free t-shirts and raffling off an Amazon Echo. You can enter to win for the low, low price of one business card. If you have any questions about our work, current available job opportunities, or what the weather’s like in Portland (spoiler: it’s probably raining), stop by - we’d love to chat with you!

ThinkShout Sessions

The ThinkShout team has two sessions in the DrupalCon agenda this year. We’re also very excited to be leading a discussion in our first DrupalCon Nonprofit Summit. Take a look at our lineup and mark your calendars

Rapid Response Campaigns & Digital Tools” - Monday (4/24), 12:30 - 1:15pm, Nonprofit Summit

The news cycle doesn’t stop, and your website must help you respond to emergencies, not act as a barrier. Drupal can help you react quickly, in concert with your other channels, to turn current events into opportunities to spread your message and further your mission. In this breakout session, Brett Meyer and Lev Tsypin will talk about the tools you have at your disposal in Drupal, scenarios that call for rapid response solutions and how to implement them, and strategies that will help you turn these situations into lasting engagement with your constituents.

Demystifying Rendered Content in Drupal 8 Twig Files” - Tuesday (4/25), 3:45 - 4:45pm

Amy Vaillancourt-Sals is going to show you the ins and outs of Twig! Twig is a robust and elegant template engine for PHP. It’s lightweight, fairly quick to pick up, very readable, and it grants users ultimate control over the markup, including wrapping elements and rendering exactly the output you need. In this session, you’ll learn about the debugging process of sorting through twig variables, using xdebug in PHPStorm, the other helpful debugging tools at your disposal, plus common patterns Amy found helpful for rendering content in twig files.

Content Strategy in Popular Culture, Part Deux” - Thursday (4/27), 10:45 - 11:45am

Brett Meyer’s got a sequel to his session from DrupalCon New Orleans. Another year, another array of pop culture obsessions to examine and apply to the work we do. By exploring how crucial aspects of content strategy play out in movies, music, comic books, and video games, we’ll continue to expand the palette of language we can use to explain and convince more people about the importance of content strategy online, and ensure they understand that it’s not just vital, but fun as well.

Let’s Chat

If you’d like to schedule some time to chat with us in advance, drop us a line via our contact form. We’d be happy to meet up with you in Baltimore!

Get In Touch

Questions? Comments? We want to know! Drop us a line and let’s start talking.

Learn More Get In Touch
Apr 19 2017
Apr 19

WordPress controls a whopping 27% of the CMS market share on the web. Although it grew out of a blogging platform, it can now can handle advanced functionality similar to Drupal and is a major (yet friendly) competitor to Drupal. Like Drupal, it’s open source and has an amazing community. Both communities learn from each other, but there is still much more to share between the two platforms.

Recently I had the opportunity to speak at WordCamp Miami on the topic of Drupal. WordCamp Miami is one of the larger WordCamps in the world, with a sold-out attendance of approximately 800 people.

Venn diagram showing Drupal and WordPress overlap.

What makes Drupal so great?

Drupal commands somewhere in the neighborhood of 2% of the CMS market share of the web. It makes complex data models easy, and much of this can be accomplished through the user interface. It has very robust APIs and enables modules to share one another’s APIs. Taken together, you can develop very complex functionality with little to no custom code.

So, what can WordPress take away from Drupal?

Developer Experience: More and better APIs included in WordPress Core

The WordPress plugin ecosystem could dramatically benefit from standardizing API’s in core.

  • Something analogous to Drupal’s Render API and Form API would make it possible for WordPress plugins to standardize and integrate their markup, which in turn would allow plugins to work together without stepping on each other’s toes.
  • WordPress could benefit from a way to create a custom post type in the core UI. Drupal has this functionality out the the box. WordPress has the functionality available, but only to the developer. This results in WordPress site builders searching for very specific plugins that create a specific post type, and hoping it does what they want.
  • WordPress already has plugins similar to Drupal’s Field API. Plugins such as Advanced Custom Fields and CMB2 go along way to allowing WordPress developers to easily create custom fields. Integrating something similar to this into WordPress core would allow plugin developers to count on a stable API and easily extend it.
  • An API for plugins to set dependencies on other plugins is something that Drupal has done since its beginning. It enables mini-ecosystems to develop that extend more complex modules. In Drupal, we see a module ecosystems built around Views, Fields, Commerce, Organic Groups, and more. WordPress would benefit greatly from this.
  • A go-to solution for custom query/list building would be wonderful for WordPress. Drupal has Views, but WordPress does not, so site builders end up using plugins that create very specific queries with output according to a very specific need. When a user needs to make a list of “popular posts,” they end up looking through multiple plugins dedicated to this single task.

A potential issue with including new APIs in WordPress core is that it could possibly break WordPress’ commitment to backwards compatibility, and would also dramatically affect their plugin ecosystem (much of this functionality is for sale right now).

WordPress Security Improvements

WordPress has a much-maligned security reputation. Because it commands a significant portion of the web, it’s a large attack vector. WordPress sites are also frequently set up by non-technical users, who don’t have the experience to keep it (and all of its plugins) updated, and/or lock down the site properly.

That being said, WordPress has some low-hanging fruit that would go a long way to help the platform’s reputation.

  • Brute force password protection (flood control) would prevent bots from repeatedly connecting to wp-login.php. How often do you see attempted connections to wp-login.php in your server logs?.
  • Raise the minimum supported PHP version from 5.2 (which does not receive security updates). Various WordPress plugins are already doing this, and there’s also talk about changing the ‘recommended’ version of PHP to 7.0.
  • An official public mailing list for all WordPress core and plugin vulnerabilities would be an easy way to alert developers to potential security issues. Note that there are third-party vendors that offer mailing lists like this.

Why is WordPress’ market share so large?

Easy: It can be set up and operated by non-developers—and there are a lot more non-developers than developers! Installing both Drupal and WordPress is dead simple, but once you’re up and running, WordPress becomes much easier.

Case in Point: Changing Your Site's Appearance

Changing what your site looks like is often the first thing that a new owner will want to do. With WordPress, you go to Appearance > Themes > Add New, and can easily browse themes from within your admin UI. To enable the theme, click Install, then click Activate.

WordPress user interface to download and install themesWordPress makes downloading and installing themes easy-peasy.

With Drupal, you go to Appearance, but you only see core themes that are installed. If you happen to look at the top text, you read in small text that "alternative themes are available." Below that there is a button to “Install a New Theme.”

Drupal user interface for enabling themesWith Drupal, you navigate through these links for the ability to download, then upload your themes.

Clicking the button takes you to a page where you can either 1) paste in a URL to the tarball/zip, or upload a downloaded tarball/zip. You still have to know how to to download the zip or tarball, and where to extract it, and then browse to appearance, and enable the theme.

So it goes with Drupal. The same process goes with modules and more. Drupal makes things much more difficult. 

So, what can Drupal learn from WordPress?

To continue to grow, Drupal needs to enable non-developers. New non-developers can eventually turn into developers, and will become “new blood” in the community. Here’s how Drupal can do it:

  • A built in theme and module browser would do wonders for enabling users to discover new functionality and ways to change their site’s appearance. A working attempt at this is the Project Browser module (available only for Drupal 7). The catch 22 of this is that you have to download this the old-fashioned way in order to use it.
  • The ability to download vetted install profiles during the Drupal installation process would be amazing. This would go a long way to enable the “casual explorers," and show them the power of Drupal. A discussion of this can be found here.
  • Automatic security updates is a feature that would be used by many smaller sites. Projects have been steered toward WordPress specifically because smaller clients don’t have the budget to pay developers to keep up with updates. This feature has been conceptually signed off on by Drupal’s core committers, but significant work has yet to be done.

Mitigating Security Risks

The downside for this functionality is that Drupal would need to have a writable file-system, which at it’s core, is less secure. Whether that balances out with automatic updates is debatable.

Automatic security updates and theme/module installation would not have to be enabled out of the box. The functionality could be provided in core modules that could be enabled only when needed.

What has Drupal already learned from WordPress?

Cross-pollination has already been happening for a while. Let’s take a look at what the Drupal community has already, or is in the process of, implementing:

  • Semantic versioning is one of the most important changes in Drupal 8. With semantic versioning, bug fixes and new features can be added at a regular cadence. Prior to this, Drupal developers had to wait a few years for the next major version. WordPress has been doing this for a long time.
  • A better authoring experience is something that Drupal has been working on for years (remember when there was no admin theme?). With Drupal 8, the default authoring experience is finally on par with WordPress and even surpasses it in many areas.
  • Media management is the ability to upload images and video, and easily reference them from multiple pieces of content. There’s currently a media initiative to finally put this functionality in core.
  • Easier major version upgrades is something that WordPress has been doing since it’s inception.

Drupal has traditionally required significant development work in between major versions. That however, is changing. In a recent blog post, the lead of the Drupal project, Dries Buytaert said,

Updating from Drupal 8's latest version to Drupal 9.0.0 should be as easy as updating between minor versions of Drupal 8.

This is a very big deal, as it drastically limits the technical debt of Drupal as new versions of Drupal appear.

Conclusion

Drupal and WordPress have extremely intelligent people contributing to their respective platforms. And, because of the GPL, both platforms have the opportunity to use vetted and proven approaches that are shortcuts to increased usability and usage. This, in turn, can lead to a more open (and usable) web.

Special thanks to Jonathan Daggerhart, John TuckerMatthew Tift, and Juampy NR for reviewing and contributing to this article.

Wapuu hugging a Druplicon
Apr 19 2017
Apr 19

Custom form with CRUD Operations is basically building the form with different fields like UID, Name, Mobile Number, Address, Email id etc. The CRUD operations for these fields is Deleting the value of the fields from the database or updating the existing value with new value, and printing the updated value. 

How To Create a Custom form with CRUD Operations?

To create a custom form with CRUD Operations, we need to follow the following folder structure as shown in the image. To perform the same operation of crud in drupal we need to follow the following folder structure.

CRUD Folder Structure

The data from the database will be displayed in the form of a table and the table will contain operations as a new column. The role of operations column is to perform edit(update) operation or the delete operation. The edit operation is used to update the present value into new values and delete operations is used to delete the entire row. The following files and procedures help us to create a custom form with CRUD operations. Create the files as shown in the image.

mydata.info.yml:
The .info.yml files is most important part of Drupal Modules. The .info.yml file is a collection of static text file, used to define and configuring a module. First, we have to create info.yml file which contains metadata about the project like the name of the module, description, core, package.

mydata.install:

mydata.install helps to create a table in the database. I have created a table called mydata in the database.hook_schema helps to store the values into the database. In our custom form the crud database will be stored in mydata as the table name. If the value is stored in the database, it helps in performing CRUD operations,like edit or delete. I have stored the fields as name, id, mobile number, email, age gender. Id is autoincrement with the help of serial type.

mydata.routing.yml
mydata.routing.yml helps to transfer the function to the Controller to display of data in table format, to create form and placing that form in blocks. When '/mydata/hello/table' is passed to the url the Controller  DisplayTableController is called and the controller will display the data from database in table format. Similarly when the ‘/mydata/form/mydata’ is passed to the url the form containing credentials like name, id , age etc is shown to the user. The user has to enter the details.

When the path  '/mydata/form/delete/{cid}' is passed to url DeleteForm.php is called. By this file you can delete the fields present in the database row by row.

Controller
In the src/Controller create a file called 
DisplayTableController :

In this file, we will display the output in the table format. We have used the standard way of displaying the values of the row in table format.
The code for displaying the value in table format. The $header_table must be defined, like what are the column values that need to be displayed in the table format.

Form
In the src create a folder called Form, In the form folder, we will create a file which will help to create form fields like Textfield, checkbox, select list, number etc..

MydataForm:

In this file, we will create the form fields for  UID, Name, Mobile Number, Email, age etc. For more info on form API, visit https://www.drupal.org/docs/8/api/form-api/introduction-to-form-api . The complete code for the Mydata form is shown below

In the above file we have performed both Insert and update operations. If the user clicks the edit operations then it will call the update functions or it will be insert operation.We have used three methods to perform the operation

  • Buildform: It is the method which is used to construct the form with different types like text field email, select checkbox etc
  • ValidateForm : In this method we provide validation conditions for the form, that has to be validated before the form values get submitted
  • Submit form : In this method the values will be submitted to the database so, it can be retrieved. 

   2.  DeleteForm.php :

In this file we will perform delete operation. I have followed certain standards to delete operation, we can also user db_delete operation. The complete code for the delete operation is shown below

Note : cid is the current value form the url and cid is stored in this->id(current id).

BLOCK


1 MydataBlock:

This block helps to place the form fields anywhere in the UI. Placing the block can be done by going to admin/Structure/block and placing the block in any of the regions. The code of MydataBlock is shown below

The output of the above module is shown below
CustomForm

The above screenshot displays all the form fields that are to be entered by the user .It is a block that is placed 

CrudOperationPage(output page):  

It display the option for delete or edit

Output of CRUD

Reference : https://github.com/pavanBS/drupal-module-crud

Apr 19 2017
Apr 19

It’s that time of year again - DrupalCon North America! The Chromatic team is excited to get together for a week of Drupal and fun in Baltimore, Maryland. We’ll be presenting several sessions throughout the week, so don’t miss out!

We’ll be attending a few of the summits on Monday, so if you see us, make sure to say hello. You might also spot one of our team members pitching in at the Drupal Diversity & Inclusion Booth, so stop by & take a picture at their photo booth!

Once again, Chromatic is sponsoring the conference via a Birds of a Feather room. As we have in the past, our room will be stocked with free Chromatic swag that you can pick up at any time. We’ll have stickers and some new tee shirts to share!

Sessions

This year, Chromatic will be presenting 4 sessions during the conference:

Tuesday, April 25

Dave Look
Culture is Curated
10:45 AM - 11:45 AM
Community Stage - Exhibit Hall

Alanna Burke
Work/Life Balance - You CAN Have It All!
2:15 PM - 2:45 PM
Community Stage - Exhibit Hall

Wednesday, April 26

Ryan Hagerty
JavaScript ES6: The best vanilla you’ve ever tasted
3:45 PM - 4:45 PM
Room 309

Alanna Burke
Code Standards: It's Okay to be Yourself, But Write Your Code Like Everyone Else
3:45 PM - 4:45 PM
Room 314

Birds of a Feather

Chromatic is also hosting one BoF session on Tuesday:

Tuesday, April 25

Alanna Burke
Managing Our Stress
3:45 PM - 4:45 PM
Room 313

Apr 19 2017
Apr 19

Drupal has a problem. No, not that problem.

We live in a post peak Drupal world. Drupal peaked some time during the Drupal 8 development cycle. I’ve had conversations with quite a few people who feel that we’ve lost momentum. DrupalCon attendances peaked in 2014, Google search impressions haven’t returned to their 2009 level, core downloads have trended down since 2015. We need to accept this and talk about what it means for the future of Drupal.<.p>

Technically Drupal 8 is impressive. Unfortunately the uptake has been very slow. A factor in this slow uptake is that from a developer's perspective, Drupal 8 is a new application. The upgrade path from Drupal 7 to 8 is another factor.

In the five years Drupal 8 was being developed there was a fundamental shift in software architecture. During this time we witnessed the rise of microservices. Drupal is a monolithic application that tries to do everything. Don't worry this isn't trying to rekindle the smallcore debate from last decade.

Today it is more common to see an application that is built using a handful of Laravel micro services, a couple of golang services and one built with nodejs. These applications often have multiple frontends; web (react, vuejs etc), mobile apps and an API. This is more effort to build out, but it likely to be less effort maintaining it long term.

I have heard so many excuses for why Drupal 8 adoption is so slow. After a year I think it is safe to say the community is in denial. Drupal 8 won't be as popular as D7.

Why isn't this being talked about publicly? Is it because there is a commercial interest in perpetuating the myth? Are the businesses built on offering Drupal services worried about scaring away customers? Adobe, Sitecore and others would point to such blog posts to attack Drupal. Sure, admitting we have a problem could cause some short term pain. But if we don't have the conversation we will go the way of Joomla; an irrelevant product that continues its slow decline.

Drupal needs to decide what is its future. The community is full of smart people, we should be talking about the future. This needs to be a public conversation, not something that is discussed in small groups in dark corners.

I don't think we will ever see Drupal become a collection of microservices, but I do think we need to become more modular. It is time for Drupal to pivot. I think we need to cut features and decouple the components. I think it is time for us to get back to our roots, but modernise at the same time.

Drupal has always been a content management system. It does not need to be a content delivery system. This goes beyond "Decoupled (Headless) Drupal". Drupal should become a "content hub" with pluggable workflows for creating and managing that content.

We should adopt the unix approach, do one thing and do it well. This approach would allow Drupal to be "just another service" that compliments the application.

What do you think is needed to arrest the decline of Drupal? What should Drupal 9 look like? Let's have the conversation.

Bookmark/Search this post with

Apr 19 2017
Apr 19

Drupal is software that allows an individual or a community of users to easily publish, manage and organize a great variety of content on a website.

CMS

Bells, whistles, and maybe bagpipes

Drupal provides a rich toolset to allow you to manage the content on your website. It goes beyond the capabilities of most content management systems (CMS) however by enabling you to define custom content types without the need for programming. This means you are never limited to the kinds of pages that are built into the system.

Community & Collaboration

Drupal makes user management as flexible as content management. Control access to your content through user roles or group membership. Customise the information you collect about each user, and get Drupal to automatically link users together based on matching information.

Drupal really shines at collaborative and community content management. Instead of your site relying on the work of a few editors, Drupal allows you to spread the load. Community moderation, voting, group blogging, forums and numerous plug-ins add all sorts of capabilities.

Visual Design

More than a pretty face

The visual presentation of data is kept carefully separate by strict standards. This means that designers have complete control of the look of their site.

Security

Safe as houses

A dedicated security team constantly reviews Drupal’s code for potential security weaknesses, and works to ensure that Drupal’s development community is educated and aware of security issues. We are part of this security team.

A policy of full disclosure means information about security problems is always made public once the threat has been addressed and a secure version of Drupal is available.

Development Speed & Reliability

Drupal’s mature API provides a solid set of re-usable building blocks that allow your project to be built quickly, reliably and securely.

Modular

Like little coloured bricks

Drupal has a very modular framework. Features can be added or enhanced cleanly and easily without any changes to the core system.

Easily Upgraded

That new feature smell

Since any customisations you may have added to your site are cleanly compartmentalised, you can always upgrade to the newest version of Drupal without having to worry about undoing your work.

Web standards

We all want to fit in

Drupal enforces a clean separation of data, logic, markup, and styling – enabling projects to use their preferred standards to structure and display output, including HTML, XML, CSS, RDF, and PDF.

Accessibility

Welcome one and all

"Drupal - Open source content management platform that cares about accessibility and standards."
– Jeffrey Zeldman, co-founder of the Web Standards Project (WaSP) and author of ‘Designing With Web Standards’.

Performance

The wind in your hair

Sophisticated caching mechanisms keep Drupal powered sites running even when there’s a sudden surge in traffic.

Growth

Bigger, better, faster, more

Drupal is more than software – it’s a rapidly growing community. There’s a wide range of skills and services within the Drupal community ranging from design and development to documentation and training.

Who uses Drupal?

Drupal has been selected for projects by Worldpay, Sage Pay, and the UK Government.

We'd love to help you with your Drupal project - contact us

Apr 19 2017
Apr 19

Last week we promised that from now on, we'll be more informative about where you will be able to find us. Therefore, Web Camp was our first described destination. That event is a local thing for us since our headquarters are in Ljubljana, Slovenia. Now, we are proud to say that after Web Camp we are heading towards DrupalCon Baltimore!

DrupalCon is organized by Drupal Association three times a year at three different locations. Next week, from 24th to 28th April it's time for the United States to shine. The biggest Drupal event, which brings together thousands of people from all around the world who use, develop, design, and support Drupal (also known as »Drupalistas«), will take place in Baltimore, Maryland. Drupal Community, who is at the moment experiencing a rough time, will come together and offer learning, collaboration, and networking opportunities.

 

Marko Iztok

 

We are proud to say that AGILEDROP will once again be present at the event. Our commercial director Iztok Smolic will be accompanied by Marko Bahor, our operations director. Iztok is very familiar with DrupalCons. This will be his seventh, with the first one dating back to 2009. And it was the first DrupalCon that inspired him so much that he dedicated his life to Drupal and with help from some other people formed AGILEDROP, which now exists. On the other hand, Marko is not so »experienced« with DrupalCons, but he will gladly exchange his opinions with you. So, if you spot either Iztok or Marko, catch up with them and share your thoughts. Don't wait for the next DrupalCon in Vienna in September!

The only possible downside of not catching up with our duo may be because of the size of the event. Everything became so large on DrupalCons and we discussed that problem in our interview with Janez Urevc some time ago. Nevertheless, besides learning new things, meeting up with old friends, team members, clients ... and potentially making new friends and business partners, there are also other positive things. Therefore, we have made a list of reasons why you should attend any DrupalCon.

 

DrupalCon Baltimore 2

 

If you are currently making up your mind whether you should stay a day or two after the event, you should. Visiting the city of the event is one of the reasons to go to DrupalCon and Baltimore is, with all the literary tradition and museums, not an exception. There are also some social events, which will help you enjoy the atmosphere.

One last thing. Don't forget about training and summits that happen on Monday before the conference begins. Just keep in mind that both are not included in a DrupalCon ticket. Latter is also required for some of the sprints. We hope you'll have a great time. Iztok and Marko will certainly make the most of it and are both hoping to see you there.

Apr 19 2017
Apr 19

(Disclaimer: Dries did not ask/order/suggest/request me to post this neither to make any changes whatsoever.)

I was reading Drupal Confessions with great interest, because my primary job for quite a while now is to help enable the best efforts in the Drupal community to work together to reach new heights. I am really privileged to be able to do this and make a living out of it, it is the job I always dreamed of. I also hope that I am being useful to the Drupal community in doing so. I kept nodding in agreement with the open letter's statements on diversity so I could not get rid of my cognitive dissonance on their connection with reality for several days now. The open letter says "We ask you to fight for us, Dries, to protect us from intolerance, harassment, smearing, bullying, and discrimination, no matter why or where it originates from."

As someone who is getting a paycheck at least indirectly from Dries in the past 10 years, and working as directly with him as possible in Acquia's Office of the CTO for the second half of that period, I have the opportunity to look at his practices in terms of diversity. Which would be the most observable group to learn more from if not his personal department where he directly appoints people?

In the past 5 years I've been closely working with Dries as a remote employee in the Office of the CTO at Acquia, which consisted of 15 people at most at any given time. In this time I worked with at least the following types of people directly in this group (in random order): blind, stutterer, person with ADHD, person with serious sleep problems, person with even more serious sleep problems, divorced, gay, bi, lesbian, asexual, polyamorous, gospel singer, BDSM, religiously raised, atheist, clinically infertile, cosplayer, very tall, short, people from Eastern Europe, Western Europe, US and India, native-borns, immigrants, people in offices, people always working remotely, capitalist, socialist, pacifist, people from a military family, adopting parent, transgender, people with tics, people who don't drink alcohol, etc. The teams I worked on usually had relatively high percentage of women in technical roles. My current team is 50% female, and 1/3rd of the department overall is female. This could not happen by accident.

While none of this represent the whole rainbow of humanity, and it could definitely be further improved, our limited group of 15 people already covered outstanding diversity in my view. Also this is a group that cares, we discuss and live through our struggles and support each other on every step where we can. I would challenge many of those signing the open letter to practice this kind of diversity in their teams. I for one really enjoy the varying values that people brought in and am sad that some of those great people have left to pursue other technical challenges.

In this five years, I never experienced that when hiring people either of these things were considered as a negative or that any person was treated or felt treated badly for any personal life matter. Neither that any of the amazing people who unfortunately left and are covered in the list left because of any of those.

Given that I just cannot get over my cognitive dissonance. Who are being convinced of what?

Apr 18 2017
Apr 18

Those who know me will be well aware that I am both a passionate cyclist. Last June I wrote a blog about cycling. It told the dreadfully sad tale of a cyclist who died close to my home following a road traffic incident. In just 24 hours the post had over 10,000 reads. This triggered me to take positive action, the result of which is my campaign "BeyondACyclist", which has backing and support from CyclingUK.

A totally volunteer effort (entirely inspired by my work with Drupal) BeyondACyclist has a groundswell of support and active participation from the likes of Three Degrees West film company, Cheshire Fire Service, Cheshire East Council, West Midlands Police, Christie Hospital, composer Brian Lane, script writer Craig Roderick (Southpaw Agency) and Phil Jones MBE Managing Director - Brother UK to name but a few. Plans are in advanced stages to produce an ambitious cinema quality short film, supporting studio portraits and action photography, social media campaign and distribution across a variety of mediums.

Why I am reaching out to you the Drupal community

Within the next few months we will have the film completed. But there is a final missing link. I need a website designed, built and themed to drive traffic towards. A site to serve as central focal point for all campaign activity. The place where all traffic will arrive be that from TV news, print media, social or offline. I cannot do all of this alone. I already have a lot on my plate!

I'm hoping someone in the Drupal community will be reading right now and feel this is a cause they would like to get involved with. Obviously Drupal 8, it will be high traffic as I have built excellent relations with media outlets including TV, print and social. And this is a global issue. In Ireland, across USA, Australia there are currently hot news stories about cycle safety and sadly more deaths. So don't think being outside the UK is a blocker, no.

I anticipate needing 2-3 individuals to complete the task - Designer, Site builder or Site builder and Themer (as separate roles). If you would like to discuss the idea further or are just plain interested in getting involved please use my contact form to reach me. And thank you in advance. Paul.

Apr 18 2017
Apr 18

We're all thrilled to be heading to Baltimore soon for DrupalCon!

The Hook 42 team is on their way to the historic city of Baltimore. Its early days helped shape the narrative of America. This year it hosts DrupalCon North America and perhaps it will share a role in shaping the future of Drupal.

The team is excited to share what they are looking forward to, not only at DrupalCon, but also what the city might have in store for them during their down time.

First, let's talk about DrupalCon...

What session, BoF, training or speaker are you most excited about?

Aimee:

This has been a rough time for the Drupal community and I am looking forward to connecting with colleagues and friends through both business and social events. I am always interested in the future, so will be attending Core Conversations and other future facing initiative events.

AmyJune:

I am looking forward to attending the Drupal 8 Theming Training, but I am more interested in the Drupal.org panel. I am curious what the team is working on and how they will forge ahead with Drupal in the year to come.

Chris:

Parties, meeting new people, meeting old people, getting some of the ‘buzz’ back, which can be lost when stuck in projects, hopefully getting into some initiative work that I never got round to from last year, various forward looking front end implementations for Drupal, and swag!

Darryl:

While the parties are good, as a dev, the sessions are what I’m about and there are a bunch I’ve earmarked.

Genevieve:

As always I look forward to meeting up with friends old and new in a different city each year. I love getting to see the support at the Women in Drupal events, and this year am excited about the Being Human track. I’ve got a few UX/Design sessions on my schedule as well.

Idil:

I’m am looking forward to the Business Summit, attending site building & pm sessions and connecting with people in the Drupal community. Conferences are a great way bring back some of the excitement in Drupal that gets lost when we’re in our day-to-day coding & implementation. Parties and swag are always fun too!

Joseph:

I am excited to catch up with the Drupal community and meet new people. I also like learning about performance and plan to attend any session I can about performance.

Drupal Community

Kristen (KP):

When I first started going to DrupalCons, I went to back-to-back sessions. Over the years that transformed to mostly doing the "hallway" track where I talk informally to people in the community. This is what I look forward to the most in Baltimore.

Kristin (K2):

What am I not looking forward to? DrupalCon is always a fun time, and I love meeting new people, learning what’s going on in the community and getting some good booth swag. Specifically, I am really excited about the Women in Drupal event, it is always such a great moment to chat and meet some really stellar developers. Can’t wait to see you all there!

 

Now, on to the less serious part...

What are you most excited to see or do in Baltimore?

Aimee:

I really liked the TV show “The Wire”, but that is a bit heavy for the visit. My son Ryan will be attending his first DrupalCon out of utero, so we’ll are going to Washington DC to play on the big lawns and visit museums. :)

AmyJune:

I enjoy beer and new people, and I have heard rumors that Baltimore has both, so I am good to go! In all seriousness, I am looking forward to finding my most Eastern geocache and enjoying beer with some of my fellow Drupal Easy Alumni. As far as sight-seeing goes, I'd like to get out of Baltimore and visit Sandy Spring's historic Quaker Friends Meeting House.

Chris:

Shiiiiiiieeeeeeeeet.. The projects, it's all about The Wire! Haha.. that's all I know about the place!

Video of The Wire - Senator Clay Davis - Shit

Darryl:

Going to see the Smithsonian, especially the Air and Space museum!

Genevieve:

Last February I had never been to Baltimore, then I got the chance to go to Baltimore twice last year, once was immediately following DrupalCon last year… and here I am going for the 3rd time! I’ve enjoyed getting to explore the different neighborhoods, seeing some historical sites, visiting some museums, and eating lots of food. So I am excited to do some more of all of that, this time with co-workers and drupal friends along for the ride.

Idil:

Crab. And site-seeing. But mostly crab.

Baltimore crab

-photo Itze Alonzo via Captain James Landing

Joseph:

As someone who has been to 9 countries, I love to visit new places and try the local favorite foods.

Kristen (KP):

To be honest, I really don't know much about Baltimore so not sure what is in store but Idil says there will be CRAB and I like crab so that sounds good to me. :)

Kristin (K2):

As I am a huge John Waters and Hairspray fan, I’m looking forward to singing “Good Morning Baltimore!” Baltimore holds some special place in my heart as a city where anything can happen. I’m looking forward to exploring the city and seeing what it has to offer.

Can't wait to see everyone in Charm City!!

Baltimore sunset

- photo https://en.wikipedia.org/wiki/File:Baltimore-sunset-pano.jpg

Apr 18 2017
Apr 18

At Platform.sh, we believe that all websites deserve to be secure, fast, and feature-rich, and that it should be easy to have all three. Secure has always meant that a site is encrypted using SSL, which is why we’ve never charged for an SSL certificate. Fast means using HTTP/2, which we added support for earlier this year, but most browsers only support HTTP/2 over SSL. And feature-rich means allowing the full range of newer web functionality such as geolocation, access to media devices, or notifications, many of which browsers are now only permitting over SSL connections. You know what? The modern web only works properly with SSL so let’s cut out the middleman. Let’s Encrypt everything.

We’re happy to announce automatic support for Let’s Encrypt SSL certificates on every production site on Platform.sh Professional, at no charge.

Starting today for all new projects, on every deploy we will automatically provision and install an SSL certificate for you using the free Let’s Encrypt service. You don’t have to do anything. It will just be there.

For existing projects, we're bringing that functionality online in batches to avoid overwhelming the Let's Encrypt servers. We expect to finish getting through them all within the next week or two. If you're about to bring a site live and want to make sure you get Let's Encrypt functionality before that, just file a support ticket and we'll bump you to the front of the line.

Wait, what does this mean for my site?

If you currently just have HTTP routes defined in your routes.yaml file, then as of your next deploy HTTPS requests will be served as HTTPS requests rather than being redirected to HTTP. Both will “just work”.

If you want to serve your entire site over HTTPS all the time (and yes, you do), simply change all http:// routes in your routing file to be https://. That will automatically redirect HTTP requests to HTTPS going forward.

See the Routes section of the documentation for more details, but really, there’s not many details beyond that. It just works.

What about Platform.sh Enterprise?

Most Platform.sh Enterprise sites are served through a Content Delivery Network already, in which case the SSL certificate is handled by the CDN. This change has no impact on Platform.sh Enterprise customers.

Neat! So what should I do?

You don’t have to do anything. HTTPS just works now. As above, you can configure your site to use HTTPS exclusively by adding the letter "s" to your routes.yaml file in a few places. (We told you it was easy.)

Of course, now that you know your site will use SSL, you also know it will be using HTTP/2. All SSL-protected sites on Platform.sh use HTTP/2. HTTP/2 is supported by nearly 80% of web browsers in the world. That makes it safe, and a good investment, to start optimizing your site for HTTP/2, layering in HTTP/2-specific capabilities like server push, and so forth.

Secure, fast, feature-rich, and easy. Welcome to Platform.sh!

Apr 18 2017
Apr 18
April 18th, 2017

Fun & Games

DrupalCon Baltimore is next week and we’re so excited to get back together in Baltimore! As the official Drupal Games sponsors, we take fun very seriously and this year you can be sure to find some exciting things to do at our booth—we won’t spoil the surprise but let’s just say you’ll get to see some of us IRL and IVRL.

And if you visited us last year, you know we are all about that Free Throw game. Our undefeated Web Chef, Brian Lewis, will be there to take on any challenger. We’ve all been practicing and we are READY. Are you?

We’ll also have some of our widely-enjoyed Lightning Talks during lunch intervals right at our booth! Learn something new in just a few minutes, howbowdat? Stop by our booth to check out the schedule.

Web Chef Talks

It’s been an exciting year and the Web Chefs are ready to drop some knowledge, including:

Future of the CMS: Decoupled, Multichannel, and Content-as-a-Service, presented by Four Kitchens Co-Founder and CEO, Todd Ross Nienkerk.

Supercharge Your Next Web App with Electron, presented by Web Chef engineer, James Todd.

Why Klingon Matters for Content: The Secret Power of Language, presented by our content specialist, Douglas Bigham.

Training: API First Drupal 8 with React.js and Waterwheel, a training with JavaScript engineer, Luke Herrington.

Party with a Purpose

Last—but definitely not least—you’re cordially invited to our official DrupalCon gathering, Drinks with a Mission, hosted by Four Kitchens and our friends at Kalamuna and Manatí.

Join us on April 25th at Peter’s Pour House from 6-9pm for lively conversation, free-flowing libations, and a structured forum for hashing out ideas on how to use Drupal to overcome the challenges many of our communities face in today’s national and global political climate.

RSVP here!

See you in BMD!

Oh! The kittens are coming along to Baltimore as well—four of them to be exact—and we can’t wait to reveal this year’s DrupalCon t-shirt design. We’re not kitten around. We wish we could show you right meow.

P.S. Check out the 10-day Baltimore weather forecast.

Recommended Posts

Lucy Weinmeister
Lucy Weinmeister

Lucy Weinmeister is the marketing coordinator at Four Kitchens. She loves to share all the new and exciting things the Web Chefs are cooking up at 4K. She is forever reading a book.

Events

Blog posts about ephemeral news, events, parties, conferences, talks—anything with a date attached to it.

Read more Events
Apr 18 2017
Apr 18

by David Snopek on April 18, 2017 - 1:05pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the CCK module to fix an Access Bypass vulnerability.

CCK allows you to add custom fields to any content type.

The Node Reference sub-module had a bug where it could list the node titles of nodes that the user doesn't have access to.

Here you can download the Drupal 6 patch.

If you have a Drupal 6 site using the CCK module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Apr 18 2017
Apr 18

Fairfax County Public Schools (FCPS) is the largest school system in Virginia and the 10th largest in the United States, with more than 200 schools and centers serving 186,000 students. To keep this large community of students, parents, teachers, employees, and the general public informed, FCPS is building out a network of 195 school websites.

Over time and without a unified and modern content management system, FCPS faced numerous obstacles to managing its content and effectively communicating with its audiences. The school system engaged Forum One to help realize its vision of a modern enterprise web platform that connected their sites centrally. Harnessing the content creation and syndication powers of Drupal with Pantheon’s Upstream system, Forum One developed a platform that enables FCPS to deploy, manage, and update this network of school websites from a common codebase and to easily share news, events, and alerts from a central source.

I’m Brooke Heaton, a senior developer at Forum One, and I helped lead the development of our solution for the FCPS system. In this post, I’ll discuss how we worked with Pantheon to devise a powerful solution that met a number of critical needs for FCPS. I’ll outline the modules we used to scaffold each school site starting from a Pantheon Upstream, and I’ll also dig into the tools and practices we used to quickly deploy multiple sites.

One Codebase Upstream, Dozens of School Sites Downstream

Getting the solution right for FCPS required a long-term vision that would meet a range of needs in a sustainable and scalable way. Our solution needed to:

  • Provide a common CMS that is user friendly, highly efficient, and cost effective

  • Modernize the FCPS brand with an updated visual identity

  • Syndicate central communications for multiple, diverse audiences

  • Quickly scaffold and deploy numerous new sites with common menu items, homepage and landing pages, content importers, and a unified user interface

  • Centrally add or remove users from a central source

While a Drupal “multisite” approach could have met many such needs, experienced Drupalists can attest that the multisite approach has been fraught with issues. We opted instead to harness Pantheon’s Upstream platform, which allowed us to unify all sites with a common codebase while also customizing each site with each school’s own configuration—allowing them to display their individual school name, logo, custom menus items, unique landing pages, and their own users.

Utilizing the Pantheon Upstream, we are also able to continually develop core functionality and new features and to then propagate these updates to downstream school sites.

school repo Upstream graphic

Code Propagation: Upstream code changes are merged to downstream school repositories.

Our solution was also able to create a content strategy and governance model that allows FCPS administrators to syndicate content from a central point—the central FCPS site—to individual schools by harnessing Drupal 8’s core Views, Feeds, and Migrate modules.  

FCPS.edu upstream graphic

Content Propagation: Up-to-the minute News, Events, and Blog updates are syndicated by the central FCPS website to all school sites and imported by Feeds or Migrate.

mobile view of FCPS site

Creating Turn-Key Sites with Drupal 8

To get where we wanted to go, the Forum One dev team utilized a suite of powerful Drupal 8 core and contributed modules that generate default-content, menus, taxonomy terms, and blocks—even images!—immediately after spinning up a new site from the Pantheon Upstream.

Key modules we used include:

  • Configuration Installer: A common installation profile that would import Drupal 8 configuration from a directory so that all of the core configuration of a standard FCPS school site would be there from the start.

  • Default Content: The ability to create generic and school system-wide content that cannot be saved in configuration and to export this in json format. Upon site deployment, the Default Content module scans the modules directory for any exported default content and adds it to the database. Brilliant!

  • Migrate: Now integrated into the Drupal core, the Migrate module allows us to import complex content from a central source, whether csv or xml. While the Drupal 8 Feeds module continues to mature, the Migrate module combined with Migrate Plus and Migrate Source CSV provides powerful tools to import content.

  • Views: Also part of Drupal core, the Views module provides powerful content. syndication tools, including the ability to produce content “feeds” in json, csv, or xml format. This allows content from the central FCPS site to be broadcast in a lightweight data format, then imported by the Feeds module on each individual school site. Triggered regularly by a cron job, Feeds instances import the latest system-wide News, Events, and Blog posts.

The FCPS Install Profile

With a solid foundation in a central FCPS site (hat tip to F1 Tech Lead Chaz Chumley), we were able to clone the central site then ‘genericize’ the initial site so that it could be customized by each school. We removed site.settings from config to prevent Upstream code from overwriting downstream site settings, such as the site name, url, email, etc. We also developed a special solution in the theme settings to allow schools adjust their site colors with a custom theme color selector. Bring on the team spirit!

With this genericized starting site in code and all pages, menus, taxonomy terms, image files, and blocks exported via Default Content, we were ready to deploy our code to the Upstream. To set up the Upstream, we placed a request to Pantheon with some basic information about our Upstream and within minutes, we were ready to deploy our first FCPS school site. Huzzah!

Spinning up a New FCPS School Site from Pantheon’s Upstream

With the installation profile complete and our codebase hosted on Pantheon’s Upstream, we could now create our first school site and install Drupal from the profile. While sites can be created via Pantheon’s UI, we sped up the process using Pantheon’s Terminus CLI tool and Drush to quickly spin up multiple sites while meticulously tracking site metadata and settings. Pantheon’s helpful documentation illustrates just how easy this is:

$ terminus site:create --org=1a2b3c4d5e6f7g8h9i10j11k12l13m14n15o our_new_site 'Our New Site Label' o15n14m13l12k11j10i9h8g7f6e5d4c3b2a1 

The above command uses the format site: create [--org [ORG]] [--] <site> <label> <upstream_id>

[notice] Creating a new site...

With a site created from the Upstream codebase, the next step was to update our local Drush aliases via Terminus so that we could install Drupal from our configuration_installer:

$ terminus sites aliases
[2017-04-05 00:00:00] [info] Pantheon aliases updated 

Then we run drush sa to identify the new DEV site alias: 

$ drush sa

@pantheon.our-new-site.test
@pantheon.our-new-site.dev
 ← we will use this alias to install the site on DEV

@pantheon.our-new-site.live

With the alias for our newly created site we install Drupal from the Upstream using Drush:

drush @pantheon.our-new-site.dev  si  config_installer -y --notify --account-name=administrator --account-pass=password \
 config_installer_site_configure_form.account.name=admin \
 config_installer_site_configure_form.account.pass.pass1=admin \
 config_installer_site_configure_form.account.pass.pass2=admin \
 config_installer_site_configure_form.account.mail=[email protected]

The above command will fully install Drupal using our configuration and will automatically add the default content provided by the default content exported to our custom module. 

Once Drupal was installed on Pantheon, we added site editor accounts for FCPS and trained school staff in customizing their site(s).

school sites dashboard

The initial batch of FCPS schools sites after deployment

What about Updates?

After we deployed the first fifteen FCPS school sites and made them live to the world, it was inevitable that changes would soon be needed. Beyond the normal module and core updates, we also faced new functional needs and requests for enhancements (and yes, maybe even a few bugs that crept in), so we needed to updated our ‘downstream’ sites from the Pantheon Upstream. To do so, we merged our changes into our Upstream ‘master’ branch and within a few minutes each site displayed an update message showing that Upstream Updates are available’. This meant that we could merge Upstream changes into each school repository.

Upstream updates screenshot

To merge these changes into each site, we once again opted for the faster approach of using Pantheon’s Terminus CLI tool to quickly accept the Upstream changes and then run update.php on each of the school sites.

$ terminus site:list --format=list | terminus site:mass-update:apply --accept-upstream --updatedb --dry-run

$ terminus site:list --format=list | terminus site:mass-update:apply --accept-upstream --updatedb

To import the modified Drupal configuration, we also had to run a drush cim --partial on each site—a step that can be further automated in deployments by harnessing yet another brilliant Pantheon tool: Quicksilver Platform Hooks. With a Quicksilver hook to automatically run a Drupal partial configuration import after code deployments, we are able to remove another manual step from the process, further speeding up the efficiency of the platform.

Is This for you?

Combining Pantheon’s Upstream with Drupal 8 and its contributed modules can unleash a very powerful solution for nearly any organization that includes sub-organizations, branches, departments or other entities. Universities, public schools, government agencies, and even private enterprises can leverage this powerful tool to maintain strict control over “core” functionality while allowing for flexibility with individual sites.

You may also like: 

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