Drupal Planet

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 13 hours 49 min ago

Miloš Bovan: Post comments via email

Fri, 2016-07-15 04:08
Post comments via email

The overall test coverage of Mailhandler module has been improved in the week 7 of Google Summer of Code. The plan for the week 8 was to implement feature for posting comments by sending an email.

Similarly to MailhandlerNode (handler for nodes), we had to create a new config entity: inmail.handler.mailhandler_comment and a handler plugin class. Since comments will have limited support, during the last weekly meeting with my mentors (Miro and Primoz), we decided not to add more analyzers as proposed first, but rather to move comment specific business logic to MailhandlerComment Inmail handler plugin.

In order to simplify the logic in the comment handler, EntityTypeAnalyzer was updated to support partial entity type matching. The entity type was extracted from the subject independently of the second part, which can be bundle or entity ID in case of comments.

The current steps in the comment handler are:

  • Assert we are dealing with comments (the identified entity type is comment)

  • Parse the referenced entity ID from the mail subject: [comment][#entity_id]

  • Validate (authenticate and authorize) a user

  • Create a comment entity if all previous conditions are met

The pull request on Github was already created and it will request additional updates after it received some nice suggestions from my mentor.

The Inmail issue Lack of standard result in collaboration of analyzers progressed well during the last week. After several feedbacks and broad discussion, it is currently in “Needs review” state. In my opinion, it is quite close to be fixed and we will be able to implement the standard analyzer result object into Mailhandler module very soon.

Also, last week I made a few UX improvements in the module.
Inmail demo now supports sample mail messages from mailhandler_d8_demo module. As a related issue, PGP-signed sample mails were added to the demo.

The Mailhandler Demo is our focus for the following week. It will be extended with a sample Mailhandler user with already preconfigured Inmail settings, PGP keys and relevant form and display updates. The goal is to provide an easy start for new Mailhandler users. The progress made on the module so far, will be presented as a short (video) demo. Stay tuned!

 

 

Milos Fri, 07/15/2016 - 13:08 Tags Drupal Open source Google Summer of Code Drupal Planet Add new comment
Categories: Drupal

Janez Urevc: Presentations about various Drupal 8 media modules

Thu, 2016-07-14 13:34
Presentations about various Drupal 8 media modules slashrsm Thu, 14.07.2016 - 22:34

In the past few months I gave many talks about the modules that we created as part od Drupal 8 media initiative.

Slide decks for all sessions are available on GitHub and are released under Attribution-NonCommercial-ShareAlike 4.0 International License. This basically means that anyone is free to change and use them for non-commercial purposes. The only thing I ask is to give attribution to the original authors.

If you'd like to give a similar talk at your local meetup or camp feel you are encouraged to do so.

What are the topics that you can cover?

Entity embed

Embedding solution for Drupal 8: https://github.com/slashrsm/entity-embed-session.

Entity browser

Entity browsing and selecting tool for Drupal 8: https://github.com/slashrsm/entity-browser-session.

Drupal 8 cropping

Cropping solutions for Drupal 8: https://github.com/slashrsm/d8-cropping-session.

I co-authored and co-presented this session with Alexander Ross.

NP8 enterprise media distribution

Enterprise media distribution built on Drupal 8: https://github.com/slashrsm/np8-session.

Categories: Drupal

ImageX Media: Higher Education Notes and Trends for the Week of July 11, 2016

Thu, 2016-07-14 13:10

There’s never a dull moment in the higher education sector. This week, we had our eyes on a dozen interesting articles across higher education. As always, you’ll find an undercurrent of themes that generally revolve around revenue and student demographics. This week’s higher education notes and trends has topics ranging from wealth distribution amongst North American post-secondary institutions, “over-education” of millennials and enrollment staff becoming the next generation of corporate headhunters.

Categories: Drupal

Acquia Developer Center Blog: Accessibility Testing: The Basic Facts You Need to Know

Thu, 2016-07-14 13:04

As businesses realize the importance of having an accessible website, there is a push to check both content and code to ensure that they are meeting 508 compliance standards and other accessibility standards, such as the Web Content Accessibility Guidelines (WCAG).

Tags: acquia drupal planet
Categories: Drupal

Lullabot: Rapidly Iterating with the ELMS Learning Network Drupal Distribution

Thu, 2016-07-14 13:00
Matt and Mike talk to Bryan Ollendyke and Michael Potter about everything LMS (Learning Management System) and their ELMSLN Drupal distribution that goes a long way into solving problems within that niche.
Categories: Drupal

Valuebound: How to define an Event, Dispatcher and Subscriber in Drupal 8?

Thu, 2016-07-14 12:50

As we all know Symfony Event Components are  included in Drupal8 core. In future versions of Drupal Core, Events are going to play a major role for sure. Let’s see how the Event component is going to help our Drupal Development. 

In one of the recent project, we got a tricky requirement in content authoring and publishing workflow. In specific, the Editor has to get a notification for reviewing, once a content author writes an article and saves it for reviewing. By using Events we can easily achieve this kind of  …

Categories: Drupal

Faichi.com: Automating Project Estimation Process

Thu, 2016-07-14 10:24
Categories: Drupal

Freelock : Ask Freelock: Why haven't you migrated to Drupal 8?

Thu, 2016-07-14 10:11

Richard asks:

Just a question after reading an article posted here back from January 21, 2016 on Drupal 8, why Freelock.com has not moved to Drupal 8?  Just wondering if there was a particular reason we should avoid before jumping in?  Thanks.

Ha! What a great question!

Three reasons: Time, requirements, priorities.

Drupal PlanetDrupal 8Decision-makingValue
Categories: Drupal

Mediacurrent: A Marketer Meets GitHub

Thu, 2016-07-14 09:20

One of the many perks of working at Mediacurrent is the ability to work in the comfort of your own home or nearby coffee shop.

Categories: Drupal

Appnovation Technologies: Appnovators Submit 7 Sessions for DrupalCon Dublin

Thu, 2016-07-14 09:20

DrupalCon is the heartbeat of the Drupal community, where important connections are made, improvements to the project happen, and cutting edge knowledge is shared.

Categories: Drupal

Deeson: 24 things about Drupal 8 every CTO should know - Part 3

Wed, 2016-07-13 00:52

Are you one of the growing number of CTOs who is preparing to migrate to Drupal 8? Our technical lead John Ennew has gathered together all of the questions we’ve received to bring you some useful answers (to see all we’ve covered so far, you can read part 1 and part 2 of this post). In the final part of our mini-series, we’re going to tackle three topics: Drupal 8 in the enterprise, architecture changes, and the crucial issues of performance and security.

Drupal 8 in the enterprise 15. Does Drupal 8 make enterprise development practices such as automated testing easier?

Several improvements in Drupal 8 make it a more effective platform for practising continuous development.

The configuration management system means configuration now lives in code in a standard way meaning code can be safely transferred between environments and its behaviour is now predictable.

Drupal 8 code makes more use of objects and PHPUnit is supported by the testing infrastructure within the core codebase, meaning all code can now be written with unit tests.

Drush, the Drupal CLI tool, has been updated to work with Drupal 8 already, and can be used to automate most deployment activities from testing the quality of the custom code using the coder module, to testing the functionality using PHPUnit.

Automated testing, outside of the core codebase, has also been improved with Drupal 8. The core product now includes PHPUnit which is a test runner which allows both Unit and Functional tests.  These are more robust tests that run much quicker than previous versions.

Since PHPUnit is a well recognised tool in the wider PHP developer community, hopefully finding people to write tests and finding resources to help developers get to grips with testing will be easier with Drupal 8.

Drupal 8 is also supported by the popular Behat testing framework for Symfony allowing well formed behaviour driven development practices (BDD).

16. Is it easier to manage a large portfolio of sites with Drupal 8?

Drupal 8 is a good choice for organisations maintaing large portfolios of sites. Drupal is the most flexible and extensible CMS and so can be used to develop both small, simple websites but also larger, more complex ones. By choosing to consolidate on Drupal you can reduce the development effort required in maintaining a large estate.

Drupal 8’s RESTful APIs allows you to develop the sorts of enterprise tools needed to manage an estate of sites. Features like Drupal’s multi-site and the Group module mean that you can also take a single Drupal codebase and use it to deliver multiple websites.

In addition, the new Configuration Management system means that changes can be deployed to a large number of sites far more reliably than with Drupal 7. While there will always be complexities with such approaches Drupal 8 is flexible enough to adapt to your specific requirements.

17. Has configuration management improved in Drupal 8?

Configuration management is the ability to define the configuration of a software application like a Drupal website in a testable, versionable way. In Drupal 7 it was often the case that configuration had to be done manually in each environment after a release rather than defining the behaviour of the website in each environment within the code of the website.

Drupal 7 had some addons that made exporting configuration to code possible such as the Features module, but these were never done in an entirely satisfactory manner and each module had to define its exportable behaviour to Features.  

In addition, the variable table in Drupal 7 became a dumping ground of both configuration and state for each environment which meant that determining what needed to be exported into configuration in code and what could be safely ignored on a per-environment basis was complicated, time consuming and could lead to errors during deployment.

The Configuration Management Initiative in Drupal 8 has brought a standardised way for modules to define their editable configuration. Site builders can then export the configuration for an environment into configuration files which can be put into the website’s version control system and changed on a per-environment basis. This allows configuration to be audited, rolled back and be testable.

Architecture changes 18. What does Drupal 8 mean for ‘headless Drupal’?

Headless Drupal or Decoupled Drupal are terms used to describe the system’s architectural practice of separating the back-end and theming components of Drupal. In such an architecture, Drupal is used as a Content Management System for data entry and retrieval, but the rendering of web pages of content to end users (the theming layer) is passed over to another tool.

This allows development teams to build rich internet applications, mobile applications or apps for devices such as smart TVs, watches or the next Google Glass. Each of these devices have their own theming mechanisms and all of them just want pure data from the Content Management System.

Drupal 8 is capable of outputting data not just as HTML but in many forms such as JSON or XML. How it delivers data depends on the device or application which is requesting the data.

Choosing Drupal 8 as the Content Management system is a good investment for the future. Initially it may just be a website delivering to traditional web browsers, but later other apps or dynamic internet applications may be built which use the same Drupal back-end for retrieving their data.

The Drupal community as a whole is actively developing a variety to tools to make Headless or Decoupled Drupal increasingly easier. There are now modules that allow Drupal to provide GraphQL responses, the core REST APIs are improving and best practices around how to integrate with front-end frameworks such as Angular or React are being developed.

19. Does Drupal 8 change how Drupal integrates with other systems?

There are two levels at which Drupal 8 provides significant steps forwards.

At the PHP application level Drupal 8’s inclusion of standard PHP libraries means that for any particular application it is likely that a good external library already exists. There is less of a reliance on a single developer working inside of the Drupal ecosystem to meet your integration needs.  In addition, the new plugin system within Drupal means that extensions to Drupal can easily be developed. This technology maintains Drupal’s position as the most extensible and flexible CMS framework available.

At the API level Drupal 8 provides mechanisms for interacting with its data via a RESTful API allowing it to easily integrate with other systems.

20. Is the database abstraction layer any different?

In Drupal 7 a process began to standardise how information is described and stored in Drupal through the Drupal Entities. This model was only partially implemented in 7 but Drupal 8 takes this much further to make it become the only model developers need to use.

As such,  developers working on developing websites with Drupal 8 will work at the Entity level rather than the database level. This allows Drupal 8 websites to work agnostically with a larger number of database technologies, not just the traditional relational ones such as MySQL. For example, it is possible to use NoSQL solutions such as MongoDB as the database storage layer with a Drupal 8 website.

In Drupal 8, the database API is pretty much the same as Drupal 7, but developers should almost never be making database calls directly unless they are developing core APIs.

21. I’ve heard Symfony is used heavily in Drupal 8 core, what are the implications?

In previous versions of Drupal all the code within Drupal was built by members of the Drupal community. In Drupal 8, the developers have embraced other projects like Symfony directly incorporating Symfony components in Drupal, and, likewise, are building libraries which can be reused in other projects. Rather than re-inventing the wheel, Drupal 8 includes components developed by a larger community to solve common problems.

This means that Drupal benefits from a more stable codebase used in more projects. In return, projects like Symfony also get the benefit of more people making use of their code and so becomes more robust in the process.

A key addition benefit is that developers familiar with Symfony and not Drupal will now be able to move into Drupal development with much less effort. This opens up the pool of talent development teams can draw on.

Symfony is written using industry standards and best practices, such as PSR-4 name spacing of classes, these have been incorporated in Drupal 8.

Performance and security 22. Are there performance improvements in Drupal 8?

Drupal 8 is not necessarily faster out of the box when compared to Drupal 7 but pure page load speed is less relevant these days. Drupal 8 can scale much better and that is in large part due to a complete redesign of the caching system and the page build pipeline.

In Drupal 7, often when a cache needed to be cleared the only option was to clear all caches meaning that a small change could cause a greater strain on the website as all the caches had to refill.  Caching usually occurred at the page level as well in Drupal 7, which meant that either the whole page was returned from cache or the whole page needed to be regenerated. For logged in users, generally no caching happened and the whole page was generated for every page request.

In Drupal 8 the caches are much more complex and caching can be defined and cleared in a fine-grained manner. The new Cache Tags system allows, for example, pieces of a page to be cached so that logged in users might receive most of a page from cache and just the link to their account is generated. Cache Tags also allows the developers to define specific cache-clear scenarios for their sites based on the known behaviour of the site - for example, it is possible to clear all caches which contain information about user with id 300 following an update to their account without clearing every other user’s cached data.

In addition, the cache system, like much of Drupal 8, is pluggable which means that better caching tools can be plugged in at all levels. For large, complex sites, much more precise selections of tools can be used to improve performance.

The way the page build pipeline works has been overhauled in Drupal 8 meaning that a web page is built in a much more efficient manner to previous versions of Drupal. There is also a general ‘fast by default’ principle used by the Drupal 8 core development which makes sure that nothing needs to be enabled to provide performance boosts for Drupal 8.

There two architectural improvements meant that advanced page rendering techniques such as Big Pipe could be made a part of a Drupal and in Drupal 8.1 the Big Pipe module was introduced. This technique, pioneered by Facebook, allows for different components of the page to be delivered asynchronously and while overall page build time does not improve the user’s experience of the page build is greatly improved. It feels as if the page loaded much faster because the key components can be delivered first allowing the user to focus on them while secondary components are delivered subsequently.

23. Has High Availability (HA) improved in Drupal 8?

Drupal has been used in HA environments for many years now and is a well understood problem. Drupal 8 is similar to Drupal 7 in this respect. The improvements to the caching layer means that more complex strategies are now possible with Drupal 8 and additional thought may optionally be put into the configuration of caching tools.

24. Does Drupal 8 have any major differences in its approach to security?

The key headline with respect to security in Drupal 8 is that it is now much harder for oversights or simply bad development practices to introduce problems. At the theming layer the use of the introduction of Twig templating system as a substitute to PHPTemplate means that there is no need for PHP code within templating. Twig is full of features for ensuring a secure theming layer, which has historically been a common source of security vulnerabilities.

Another common vulnerability was introduced through site builders manually configuring text filters for a variety of third party WYSIWYG editors. While such editors are a must for a content management system installing them wasn’t supported natively by Drupal core and was one of the more complex tasks of a site builder. In Drupal 8, the CKEditor editor is included as standard with sensibly configured defaults which will work for most cases and be secure.

The PHP module has been removed from core which allowed site builders to write PHP code in the browser. This led to bad practices and also allowed a way for a malicious user who gained higher privileges in the website due to poor configuration to execute code on the server.

All input variables from the URL are properly declared by the new routing system. This means bad or unexpected data types get filtered by default. The previous CSRF protection provided by Drupal 7’s core APIs are also still available in Drupal 8.

A team of volunteers called the Drupal security team have managed looking for security issues in Drupal core and managing the security issue queue and advisory notices.

With so much third party code now required for Drupal 8 to work, managing security advisories to external libraries is more important. Modules making use of external libraries can alert to security problems with their dependencies via the hook_requirements event.

In Drupal core, external code actually forms part of the Drupal 8 codebase. When security problems are found in that code, the security team must then work with the third party developers to fix the problems and ensure security advisories affecting both code bases are released together.

Drupal 8 doesn’t provide an automated way of applying updates out of the box. However it’s possible for companies using Drupal websites to do this via a continuous integration process using the drush command line tool, version control and automated tests.

So there you have it; some straightforward answers to Drupal 8’s most commonly asked questions. Have you found it helpful? If so, don’t forget to share it with your network on social media.

Categories: Drupal

GVSO Blog: [GSoC 2016: Social API] Week 7: Miscellaneous

Tue, 2016-07-12 17:50
[GSoC 2016: Social API] Week 7: Miscellaneous Week 7 is over, and we are working hard to have the Social API project ready before GSoC final evaluation. This week was particularly different from others. In week 7, I focus on many different tasks: from code to documentation and from closing issues to testing patches. gvso Tue, 07/12/2016 - 20:50 Tags Drupal Drupal Planet GSoC 2016
Categories: Drupal

Hook 42: Writing My First Drupal 8 Module

Tue, 2016-07-12 16:48
Tuesday, July 12, 2016

While it’s amazing how easy it is for an experienced Drupal 7 site builder to get around using the Drupal 8 UI, the same is not true for writing code for D8. As has been made clear for years now, Drupal 8 is very different inside. Many of the hooks we know and love have gone away, most procedural code has been replaced with interfaces, classes, and methods, and there are scads of YAML (Yet Another Markup Language, .yml file extension) files that wire everything together. How does a developer get her/his footing in this slippery new landscape?

I set out to write a new contrib module, Admin Status (please visit the project page for more details and to download the source code). Its goal is to provide a way to add reminder status messages that are displayed to selected users under particular circumstances. An example message might be to display a warning, “Cron hasn’t run in over 3 hours”, to users with the administrator role. Admin Status currently doesn’t actually do that specific thing, it provides a framework for adding message plugins that can be enabled and disabled, and the plugins determine what and to whom to display a message.

For Drupal 7, we can easily imagine how this module would be constructed: 1) provide hook_admin_status_info to allow message plugins to register; 2) provide an administration page that lists the registered plugins and allows them to be enabled and disabled, saving the status to an Admin Status entry in the variable table; and 3) writing admin_status_init, which runs at the beginning of each page request and loops through all the enabled plugins, calling their hook_admin_status_view function to retrieve a message and status level, which are then supplied to drupal_set_message. Two files for the module, plus an example plugin file, and we’re done.

Where to start?

For Drupal 8, it can be difficult to find firm ground from which to start. It seems like a D8 module is composed of dozens of little files in a complex directory structure. Of course, we know that this will be a big advantage eventually, because everything is autoloaded and so Drupal can minimize its footprint and only run code needed to generate the page. But, it is hard to grasp what exactly is needed to build a particular module.

One great place to start is with the Examples module. It has completely functional modules that show how to work with the different systems inside Drupal… and Symfony, for that matter. Because it seemed to be at the heart of what I wanted to accomplish, I used the plugin_type_example module as the basis for my own.

The example shows how to find plugins that are registered in the system via annotations (special comments that include data that is compiled into Drupal’s configuration - see more about this below), as well as incidental information about how to register a route (a URL to a page) and build a page for display.

I began by copying the plugin_type_example module’s code to my module’s directory. I went through the subdirectories and files, renaming everything to match my new module’s name. From this exercise, I began to understand how things were structured and what the various .yml files specified.  

Directory Structure and Namespaces

Before even diving into the code, it was clear that a module’s directory is highly structured and fine-grained. The root usually has some .yml files and a .module file. The latter is often not needed because Drupal will find what it needs from the .yml files; but you can implement things like hook_help() in here. Sometimes a .install file is needed. If the module provides a hook-based API, then there will likely be a .api.php file too.

├── plugin_type_example.api.php

├── plugin_type_example.info.yml

├── plugin_type_example.links.menu.yml

├── plugin_type_example.module

├── plugin_type_example.routing.yml

├── plugin_type_example.services.yml

└── src

    ├── Controller

    │   └── PluginTypeExampleController.php

    ├── Plugin

    │   └── Sandwich

    │       ├── ExampleHamSandwich.php

    │       └── ExampleMeatballSandwich.php

    ├── SandwichInterface.php

    ├── SandwichPluginManager.php

    └── Tests

        └── PluginTypeExampleTest.php

Also in the module root directory are the src and, perhaps, config directories. The config folder typically will have .yml files that describe configuration that you might normally build in the UI, like node types, fields, and so on. It also may have subdirectories for database table schemas and config that is added to the system at module install time. Although not in the plugin example, some of the other examples do have this directory.

In the src directory, there are files for services and interfaces defined by the module, along with subdirectories for the other class types in the module. The directory structure is mirrored in the namespaces used inside each of the source files. If you want to find the ExampleHamSandwich plugin class in the plugin_type_example module, then you know it’s going to be in plug_in_type_example/src/Plugin/Sandwich/ExampleHamSandwich.php. Similarly, if you need to use the SandwichInterface, then you need to use \Drupal\plugin_type_example\ in your code and you know that modules/plugin_type_example/src/SandwichInterface.php will be referenced.

Dependency Injection

Right off the bat, I noticed a very important concept being used: dependency injection. If you haven’t encountered this idea before, it sounds like a mysterious buzzword. (At a session at DrupalCon a couple years ago, I heard it described as a $5 buzzword for a 25¢ idea.) The idea is that a module’s code shouldn’t have specific references to outside dependencies or services; these should all be passed in. Doing so decouples the module from the rest of the system and makes it possible to test it in isolation. It also allows for outside systems to change or be entirely swapped out without modifying code inside the module.

In Drupal’s case, a lot of this dependency injection happens by specifying the services needed by a class in the services.yml file (admin_status.services.yml, in my case). When the system instantiates an object of a class, for example, a plugin manager or a form, an arguments list in the services.yml file can specify what services should be passed into the constructor.

Plugins and Annotations

Plugins are a generic way of adding customized functionality, that are used throughout Drupal 8. Plugin subclasses replace a number of different procedural interfaces that existed in Drupal 7; think of all the hook_xxx_info hooks that we used to have to work with. Drupal has a plugin framework ([docroot]/core/lib/Drupal/Component/Plugin) that provides for creation, discovery, enumeration and individual plugin access.

To use this framework, a developer creates a plugin manager subclass, a plugin subclass, and an interface that provides the specific methods needed to use the plugin type they are creating. By subclassing from Drupal’s plugin classes, the new plugin type gets the standard features described above, and usually only needs the specific code to support the features of the particular plugin type. When a new instance of a given plugin type is needed, the developer needs only to subclass the plugin type class and implement the methods in the interface.

The next important thing I saw were the annotations that were included in each of the example module’s plugins. Annotations are a particular kind of comment included with a class declaration. These are recognized and parsed during module discovery, and any configuration information is captured and stored in the database.

Drupal’s plugin classes automatically support annotations. Plugins use annotations to provide at least a machine name, but can have much more information. In fact, for particularly simple plugins, it may be the case that no actual code is required at all, just the configuration information in the annotation.

To build the Admin Status plugin types, I copied the plugin_type_example files and renamed them. I went through the code and changed machine names, directory names and class names to match. I changed the annotation information to include a machine name and a label (human readable name). I created an AdminStatusInterface interface to describe the specific methods my plugins had to provide and  changed the constructor for the plugin manager to know about the Admin Status plugin interface.

Finally, I created the src/Plugin/AdminStatus subdirectory and added two files there. The first, AdminStatusPluginBase.php, contained an implementation of the AdminStatusInterface with default methods. Then I created DefaultMsg.php, my test case plugin, which subclassed AdminStatusPluginBase and overrode just those methods that needed changing.

Forms and Configuration

The next thing needed was to create an administration form page. I needed to place this in the administration menu under Configuration > System. I started out by looking at the config_entity_example code. Config entities are like other entities in Drupal, they have bundles and can have attached fields. They are stored in their own tables in the database, but their default form is stored as YAML, so they can be recreated, the way one might revert Features in Drupal 7. This was overkill for what Admin Status needed.

Fortunately, I came across this very nice blog post by Hillary Lewandowski about building forms, and administration configuration forms in particular. Drupal 8 has a config system that provides the kind of settings storage that is more on the level of the old Variable system in Drupal 7. These settings are saved out into YAML files, of course, so they can be committed to a code repository.

Design Patterns at Work

One thing I do want to mention, which is emphasized in Hillary’s blog, is the idea of Design Patterns. These are generalized ways of handling certain kinds of programming problems that have proved to work well in the past, and are (or will become) familiar to other programmers, making it easier to pick up the code.

In this case, I saw the Factory pattern being used as a way to support instantiating classes when the constructor may have wildly different parameters from its superclass and/or sibling classes. Rather than getting a new object by directly asking for new AdminStatusForm, this pattern has you call AdminStatus::create, which is a static function of the class, and has a uniform call signature for all ConfigFormBase subclasses. The create method takes the Services Container as its only parameter and then invokes new AdminStatusForm with its particular requirements. This allows the class constructor function to have whatever parameters it needs, so it isn’t constrained by its superclass, and it doesn’t constrain any subclass that might extend it.

The idea of Design Patterns was originally laid out in the eponymous classic book published in 1995 (you can find it at Amazon or any other technical bookseller). The four authors discuss 23 such patterns in three broad categories: Creational, Structural, and Behavioral. (The Factory pattern is in the Creational category.)

Catching Events

Over the last couple years you may have been unable to avoid the phrase Proudly Invented Elsewhere, or the discussion about Getting Off the Island, or indeed, the news that Drupal was integrating another open source project, Symfony, into its basic infrastructure. Symfony is a web application framework that handles all the details of receiving web requests and returning responses. It provides an event model to do this. You can see how this happens in great and gory detail by viewing Wim Leers’ Drupal 8 Render Pipeline talk.

The final piece of this puzzle is getting hooked into each page creation so we can display the enabled messages on each page by calling drupal_set_message. To do this, we need to register an event subscriber to catch Symfony’s kernel.request event, which is triggered when a request begins processing. This is similar to Drupal 7’s hook_init.  

Because, by this point, I actually had a clue about what I needed to produce at this step, I turned to Drupal Console, the brainchild of Jesus Manuel Olivas. This is a command line tool akin to Drush. Once you install it and then visit the top directory of your module, you can use it to generate all of the boilerplate for a particular kind of class (among other things). By running drupal generate:event:subscriber and answering a series of questions, it produced the necessary class and YAML settings. You can see all that it can do by running drupal list.

When I did this, Console created the file src/EventSubscriber/AdminStatusEventSubscriber.php, which contains the event subscriber class AdminStatusEventSubscriber, which extends EventSubscriberInterface. Console included code for static function getSubscribedEvents (which returns a list of all the events that the class would like to catch, and which method to call for each) and a boilerplate implementation of the kernel_event method to handle the kernel.event event. Console also added admin_status.eventsubscriber to the admin_status.services.yml file, including the plugin.manager.admin_status service dependency injection argument and these two lines:

tags:

     - { name: event_subscriber }

They tell the system to add our class to the list of event subscribers that Symfony should query (by calling getSubscribedEvents).

In our case, all that was needed was to change the boilerplate code in the kernel_event method so that it:

  • Gets the configuration information saved from the administration form
  • Loops through each potential plugin
    • Checks to see if the plugin is enabled
      • If so, instantiates the plugin
      • Gets the configuration data for the plugin
      • Retrieves the status and message from the plugin
      • Calls drupal_set_message with the status and message as parameters
Conclusion

For experienced Drupal developers, it may be difficult to harken back to those difficult and confusing days when first learning about Drupal hooks, the detailed knowledge needed to interact with each separate subsystem and the endless, deeply nested arrays, whose content could only be discerned with dpm() calls or a debugger. The struggle involved to master Drupal 6 and 7 subsystems left a lot of developers pretty frustrated:

Source: https://web.archive.org/web/20160406122424/http://www.codem0nk3y.com/2012/04/what-bugs-me-about-modx-and-why/cms-learning-curve/

In Drupal 8, while there are more “moving parts” (individual class files, subdirectories to collect like type classes and a selection of YAML files) needed to build a module, the ideas are more uniform, which I believe will make building a Drupal site easier, with some experience, than in the past. Perhaps this can smooth out some of the steeper parts of the Drupal Learning Curve!

Darryl Richman Topics: Services:
Categories: Drupal

Torchbox: Highly Critical Drupal Security Update

Tue, 2016-07-12 16:00

Drupal’s Security Team have announced that at 17:00 BST today, they will be releasing security updates to several contributed modules for Drupal. 

Categories: Drupal

Bevan Rudge: Drupalgeddon; Are you ready?

Tue, 2016-07-12 14:57

The Drupal security team announced multiple highly critical updates to Drupal contrib modules in PSA-2016-001. Expect attacks within less than one hour from the announcement; 18 hours from the time this article is published. This is probably going to be Drupalgeddon all over again.

My advice

read more

Categories: Drupal

ImageX Media: Insights from a Web Redesign that Transformed our Online Presence

Tue, 2016-07-12 13:36

One of the greatest benefits of working in our field is the opportunity to connect with industry leaders who we might not have crossed paths with otherwise. Our clients span the gamut -- from higher education, to technology and beyond -- and Noe Marti from Verimatrix is one of those leaders. Noe was kind enough to contribute to our blog, sharing some of the insights that Verimatrix learned from a recent website redesign that they partnered with ImageX on -- and that ultimately transformed their online presence entirely.

Categories: Drupal

Aten Design Group: Drupal's Weak Link

Tue, 2016-07-12 13:16

One of the things I love about Drupal is the entity reference field. In Drupal 8, entity reference fields are even better because they’re now included in Drupal Core. This makes building composed and well-structured data is much easier. However, I think as Drupal developers and architects, we’re fundamentally misusing them in far too many cases. Over and over, we use entity references to denote a relationship between two entities instead of a simple reference or inclusion. Mere entity references severely limit our ability to create rich, rational content type architectures and force us to jump through additional hoops and write more custom code than ought to be required. I believe that Drupal having only entity references to forge relationships between content types is a major shortcoming.

What We’ve Got

Before we can understand what Drupal is missing, we first need to know what we already have. Out of the box, we can create different types of data. These are our Content Types. Different types of data might be people, blog posts or schools. If you can give it a name and describe it, there’s probably a way to represent it as an entity in Drupal. These data types can reference one another using entity references – a blog post might reference its author or a school might have a reference to all of its students. When we create the reference, we’re drawing a little imaginary arrow that points from a blog post to user entity.

Let’s explore this concept through a scenario. You’ve been tasked with building a club management system. It should be able to represent a lots of different clubs. The Engineering Club and the Theater Club, for example. We know that every club can have members and those members are the users of our application.

How should we manage memberships? Currently, we would model the relationship between clubs and members with an entity reference. Users might have an entity reference field that references the clubs to which they belong or club nodes might have a field holding all the users that are part of its membership.

What We’re Missing

So, what’s wrong with that? Problems start to creep up as you start building out the rest of the application. Let’s add a some new requirements. Some clubs need to represent who their Chair and Co-Chair is on their club homepage. Another club needs to have a treasurer. Another club just arbitrarily gives away titles to their members like, “Director of Pizza Ordering”

WIth entity references alone, we’d be hard pressed to model all of this. We might try to create a “President” or “Treasurer” field on the club content type, but that wouldn’t solve our arbitrary title requirement. We could but a text field on the user for their title, but permissions would get weird and it wouldn’t work for members of more than one club.

The truth is that the reference model doesn't work. Relationships aren’t just little arrow from A→B like an entity reference implies. Relationships aren’t always going in just one direction either, sometimes a relationship can both ways, like a friendship. The technical term for this is ‘directed’ and ‘undirected’. Entity references only ever go one direction.

At the end of the day, relationships between data types are complex and varied. It’s important to be able to describe the nature of a relationship between things in Drupal, be it duration, kind or direction. Clubs can have different kinds of members. Flights can have first class and economy passengers. Friends can be best friends. A celebrity might have followers, but that doesn’t mean that the celebrity is following all of their fans. All of these relationships aren’t easy to model in Drupal. Entity references are a blunt tool for an intricate world.

A Stronger Link

The correct approach to our club management problem is to model relationships as entities themselves. In the club management application, what we really needed was a ‘membership’ entity. That ‘membership’ type, would store a reference to the club and to the user, linking them together. But because this ‘membership’ type would be a fieldable entity, it would be trivial to create a taxonomy of membership types. We could just have an autocomplete taxonomy term field for terms like “President”, “Treasurer” or even “Director of Pizza Ordering.”

The idea is really that simple. Yet, time and time again, I see Drupal sites relying solely on an entity reference when there’s clearly a relationship involved. Entity references should only be used where the referenced content is truly part of the thing from which it’s being referenced. Media entities and taxonomy terms are perfect use cases for an entity reference. As we’ve seen though, entity references aren’t the right tool for everything. To spot relationships vs. references, ask yourself, “is this thing really part of this content? Is there a verb between my content?” Like, “A user joins a club.”

What’s Stopping Us?

In many ways, we already have all the tools we need to build our sites and applications with these concepts. It’s entirely possible for you to create entities representing relationships now. Nothing is stopping you from creating a membership node or a more custom entity using something like Entity Construction Kit.

If the answer to these issues is so simple. Why don’t we always use this strategy? Why do we as Drupal developers instinctively reach for the entity reference when we clearly want entity relationships?

The reality is that it’s more work up front. You have to worry about more content types. You need to theme more things. When creating a user, it’s not just as easy as checking all the clubs they belong to on their edit form. It’s a two-step process. When a user is deleted, we have to automatically know to delete their memberships. Frankly, it’s just more work.

The Fix

Most, if not all, of the problems with relationship types can be solved with no knowledge of the kinds of relationships involved. For example, automatically deleting a relationship with one of the entities on it is removed could be a pretty universal rule that could be easily overridden when needed.

That’s why I think imagining Drupal with a core Relationship type is an enticing idea. There’s already precedent for creating new entity types to better model content. That’s exactly what taxonomy terms are. They’re an entity type separate from a node that have some extra features like hierarchy and autocomplete/creation. Taxonomy terms are a fantastic tool in our toolbox. Sure, we might have to educate new site builders and clients about them, but once the concept is conveyed, people really run with the idea.

There are solutions out there that attempt to address these problems of relating entities today, but none are fully satisfying. There are plenty of modules that create bidirectional entity or node references, but they fall short because they are not fieldable. Foremost among these solutions is the Relation module. I really liked this module in D7, in fact, I built a few modules around it. Unfortunately though, it does not have a shippable release for Drupal 8 and it’s billed purely as an API module for developers. There’s not much of a user interface either. *

Relationships, I think, are the next logical progression in Drupal’s content architecture model. Having true relationships would enable us to do all kinds of neat things and make so much custom code completely unnecessary. Just imagine the simple idea of a publishing company where a manager should be able to edit any of the content of their subordinates. You might be able to write some custom code, but with Relationships, we could write simple modules that rely on the relationship abstraction to configure access policies, not write them custom code.

I’m working on a module to explore these ideas and uncover roadblocks, but I really would love to get the community’s response. If you found this post interesting, tell me what you thought made sense and what didn’t. What would you want out of a Relationship type. Maybe you think I’m crazy? All of it will be valuable feedback.

* If you're a maintainer of Relation reading this, thank you! I really do love Relation. It inspired me to think about problems with content modelling in Drupal in this way; I just want to go a heck of a lot further with it!

Categories: Drupal

Palantir: Building Ambitious Projects With Drupal

Tue, 2016-07-12 12:49
Want to know more about how we make web projects successful? Sign up for our webinar.

Recently, Drupal project lead Dries Buytaert published that Drupal is for ambitious digital experiences. In the post, Dries calls for open discussion of what this term might mean, noting that “Stating that Drupal is for ambitious digital experiences however is only a start. It only gives a taste of Drupal's objectives, scope, target audience and advantages.”

At Palantir, we’ve been working with Drupal for over ten years now. From our perspective as a Drupal-focused team, the term resonates. A quick review of some of our Drupal projects shows what we mean when we talk about ambition.

  • Foreign Affairs
    Innovative interactions with decades of foreign policy expertise, with deep, contextual links to related content.
  • University of Minnesota
    A scalable, replicable site building tool that powers thousands of websites on a common platform.
  • Streaming Video API
    An editorial platform and API service for building on-demand streaming video services.
  • Long Term Ecological Research Network
    A Drupal distribution that allows environmental scientists around the world to publish, share, and discover terabytes of historical climate data.
  • The King Center
    An interactive archive of the complete letters and papers of one of the 20th century’s most important figures, Dr. Martin Luther King, Jr.

On a personal note, I developed the first version of Domain Access back in 2005-2006 as part of an ambitious project. The magazine company I was working with asked “would it be possible to spin up new sites, complete with content and custom design, within minutes instead of weeks?” That spirit of exploration and discovery fires the work we do with Drupal.

It’s that ability to do rapid iteration on new ideas -- an idea that is central to the open source movement that Drupal is part of -- that powers innovation and keeps us motivated. It’s why we’re working now on the Drupal 8 port of that module.

But that innovation isn’t just technical. The idea of ambition maps very closely to one of the activities we do during client kickoff meetings. We like to ask our clients what they Like, Wish, and Wonder about their digital marketing. It’s that final question about wonder that uncovers project ambitions and opens up new possibilities. As an open platform, Drupal excels in making those ambitions possible.

And it’s the wonder of possibility that I think is captured in Dries’ use of the term ambitious.

We want to make your ambitious project a success. Let's schedule a time to talk.
Categories: Drupal

James Oakley: Be Prepared for Drupal Contrib Security Updates

Tue, 2016-07-12 11:33

The Drupal Security team has just released a public security announcement, PSA 2016-001.

There will be multiple releases of Drupal contributed modules on Wednesday July 13th 2016 16:00 UTC that will fix highly critical remote code execution vulnerabilities (risk scores up to 22/25).

If you run any Drupal sites, please be prepared, and be ready to update your site as soon as this is released.

Blog Category: Drupal Planet
Categories: Drupal

Cheeky Monkey Media: Building a Custom Module - Part 3

Tue, 2016-07-12 11:06
Building a Custom Module - Part 3 yan Tue, 07/12/2016 - 18:06

This is part 3, of a 3 part tutorial for creating a custom module for drupal 7. If you haven't already done so, you may wish to look at part 1 and part 2 first. Anyway, here is the source code of this tutorial.

First of all, though, I have to apologize that I did not do a good job of keeping track of all of the changes made so far. I code everything before I start writing, so hopefully it is not too confusing.

There are few things I would like update this time so here is a list of the things that I want to cover in this tutorial:

Categories: Drupal

Powered By