Drupal

DrupalEasy: DrupalEasy Podcast 184 - PMA (Marc Drummond - Next Steps in Drupal Theming)

Planet Drupal - 24 August 2016 - 5:54am

Direct .mp3 file download.

Marc Drummond (mdrummond), Front-end developer at Lullabot, Drupal core contributor, and self-processed Star Wars expert joins Kelley and Mike to discuss all the things the Drupal front-end community has been talking about lately. We also discuss the next major version of Drupal, whether or not a major Drupal contrib module will be deprecated, as well as our picks of the week.

Interview DrupalEasy News Three Stories
  1. Proposal: Deprecate Field Collections for Drupal 8, focus on Entity Reference Revisions & Paragraphs.
  2. The Average Web Page (Data from Analyzing 8 Million Websites).
  3. There will never be a Drupal 9 vs. There will be a Drupal 9, and here is why.
Sponsors Picks of the Week Upcoming Events Follow us on Twitter Five Questions (answers only)
  1. Disney
  2. Docker for Mac
  3. Writing a fantasy novel
  4. Llama
  5. DrupalCamp Twin Cities
Intro Music
  • Chunk-y Town - performed by Marc Drummond at Twin Cities DrupalCamp 2016.
Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Categories: Drupal

Gábor Hojtsy: Want to get issues resolved in Drupal core? Find community with an initiative!

Planet Drupal - 24 August 2016 - 5:36am

In my previous post I explained why there will be a Drupal 9 even though we have previously unseen possibilities to add new things within Drupal 8.x.y. Now I'd like to dispel another myth, that initiatives are only there to add those new things.

Drupal 8 introduced initiatives to the core development process with the intention that even core development became too big to follow, understand or really get involved with in general. However because there are key areas that people want to work in, it makes sense to set up focused groups to organize work in those areas and support each other in those smaller groups. So initiatives like Configuration Management, Views in Core, Web Services, Multilingual, etc. were set up and mostly worked well, not in small part because it is easier to devote yourself to improving web services capabilities or multilingual support as opposed to "make Drupal better". Too abstract goals are harder to sign up for, a team with a thousand people is harder to feel a member of.

Given the success of this approach, even after the release of Drupal 8.0.0, we continued using this model and there are now several groups of people working on making things happen in Drupal 8.x. Ongoing initiatives include API-first, Media, Migrate, Content Workflows and so on. Several of these are primarily working on fixing bugs and plugging holes. A significant part of Migrate and API-first work to date was about fixing bugs and implementing originally intended functionality for example.

The wonder of these initiatives is they are all groups of dedicated people who are really passionate about that topic. They not only have plan or meta issues linked in the roadmap but also have issue tags and have regular meeting times. The Drupal 8 core calendar is full of meetings happening almost every single workday (that said, somehow people prefer Wednesdays and avoid Fridays).

If you have an issue involving usability, a bug with a Drupal web service API, a missing migration feature and so on, your best choice is to bring it to the teams already focused on the topics. The number and diverse areas of teams already in place gives you a very good chance that whatever you are intending to work on is somehow related to one or more of them. And since no issue will get done by one person (you need a reviewer and a committer at minimum), your only way to get something resolved is to seek interested parties as soon as possible. Does it sound like you are demanding time from these folks unfairly? I don't think so. As long as you are genuinely interested to solve the problem at hand, you are in fact contributing to the team which is for the benefit of everyone. And who knows, maybe you quickly become an integral team member as well.

Thanks for contributing and happy team-match finding!

Ps. If your issue is no match for an existing team, the friendly folks at #drupal-contribute in IRC are also there to help.

Categories: Drupal

Zyxware Technologies: [Drupal-8] How to send a mail programmatically in Drupal-8

Planet Drupal - 24 August 2016 - 5:33am

This article covers, how to send email programmatically in your Drupal 8 site. There are two main steps to send an email using Drupal 8. First we need to implement hook_mail() to define email templates and the second step is to use the mail manager to send emails using these templates. Let's see an example for sending an email from the custom module, also the following name spaces.

DrupalDrupal 8Drupal Planet
Categories: Drupal

Unimity Solutions Drupal Blog: Identification of an Open Source Video Annotations Tool for NVLI

Planet Drupal - 24 August 2016 - 5:00am

As mentioned in our earlier blog on Video Annotations: A powerful and innovative tool for education, the most intriguing feature of the pilot version of NVLI is Video Annotation. UniMity Solutions assisted in building Annotation feature for Audio and Video assets. This involved identifying and integrating an open plugin that supported video and audio annotations and a generic annotation store module that was plugin agnostic.

Categories: Drupal

Drupal Bits at Web-Dev: Import nodes as as part of deployment using Hook Update Deploy Tools

Planet Drupal - 23 August 2016 - 8:52pm

With the 7.x-1.18 release of Hook Update Deploy Tools for Drupal 7 it is now possible to export a node on a development sandbox, commit the export file to the repository, then import it using either a hook_update_N() or using drush site-deploy-import node

Pros:

  • No need to re-create a node on prod after a client approves it.
  • Early content that keeps getting wiped out by database snapshots (think style guides) can get re-created instantly with a single drush command.
  • Content imported into an existing node shows up as a revision.
  • Atomated deployment is testable and repeatable on all dev environments.
  • No uuid required.
Workflow Example:

You have a styleguide you created on your sandbox and want to deploy it to the production site.

  1.  Create the node on your sandbox (node id = 1234).
  2. Export the node to an export file.
    drush site-deploy-export 1234
  3. The command created an export file named  for the alias of the node being exported
    ex: site-deploy/node_source/helpzZzstyle-guide.txt  ('zZz' represents '/')
  4. Create a hook_update_N() to import the file on deployment
     

    <?php
    /**
     * Import a the style guide
     */
    function site_deploy_update_7129() {
      $nodes = array('help/style-guide');
      $message = HookUpdateDeployTools\Nodes::import($nodes);
      return $message;
    }
    ?>
  5. Commit the file and update hook to your repo.
  6. Push the code, run 'drush updb'
drush updb -y
Site_deploy  7129  Import a the style guide

Site_deploy: Updated: node/1234: help/style-guide - successful.
Summary: Imported Nodes 1/1.  Completed the following:
   [help/style-guide] => Updated: node/1234
  
Performed update: site_deploy_update_7129

or the import can be performed by

drush site-deploy-import  help/style-guide
Categories: Drupal

Drupal @ Penn State: Drupal 8 Theme Generation and Development Intro Using the Drupal Console

Planet Drupal - 23 August 2016 - 4:56pm

Here is a screen cast of how to get started with Drupal 8 theme development.

In the video I cover:

  • using the drupal console to generate a theme from a base theme
  • creating a libraries yml file
  • adding global css to your theme
  • Using Kint with the devel module
  • debugging twig
  • adding your own twig file to your theme
Categories: Drupal

Drupal @ Penn State: Lower the Drupal 8 development barrier to entry by using the Drupal Console to generate boiler plate code.

Planet Drupal - 23 August 2016 - 4:56pm

I admit that I haven't really looked at Drupal 8 too much yet. There is a variety of reasons why I haven't and I surely don't want this to turn into a forum listing the pros and cons of D8. We can leave that for another post. 

Categories: Drupal

Drupal @ Penn State: The Care and Feeding of Your Website

Planet Drupal - 23 August 2016 - 4:56pm

A question on the PSU DUG Slack channel got me thinking. How is it that websites are still being constructed at Penn State without any thought being put in as to how its is going to be maintained? Or by whom?  

To be clear, I am not talking about content creation or maintenance, but maintaining the code/server/DB/etc. that supports or runs the site? Or to develop new features and functionality, going beyond just updating code or applying security patches. Of course, this is not restricted to Drupal development - there are many other examples.

Categories: Drupal

PreviousNext: Introducing Drush CMI tools

Planet Drupal - 23 August 2016 - 4:46pm

Now we've got the experience of a number of production D8 sites under our belt we took the time to consolidate our CMI workflow into some useful drush commands.

And naturally we've open sourced them.

Read on to find out more about our drush CMI tools.

Categories: Drupal

GVSO Blog: [GSoC 2016: Social API] Week 13: Thanks GSoC!

Planet Drupal - 23 August 2016 - 3:07pm
[GSoC 2016: Social API] Week 13: Thanks GSoC! Submitted by gvso on Tue, 08/23/2016 - 18:07

Students' final evaluations is over, and only mentors' evaluations is left. During these months, I have been working on projects to harmonize social networking functionality in Drupal and documenting them. Notwithstanding, the Social API project started as an idea for a framework in fact, the main components provide extensible functionality. Therefore, I documented the process of creating new implementers.

Tags Drupal Drupal Planet GSoC 2016
Categories: Drupal

Roy Scholten: UX meeting recap

Planet Drupal - 23 August 2016 - 2:58pm

Two meetings every week since end of march this year. Safe to say we’ve found a consistent rhythm.

And it’s working. It’s become a useful way to check in on current priorities, review patches while screensharing (visuals, transitions, flows!), decide on next steps and generally discuss hard problems without having to type so much.

The agenda for today was
  1. Roadmap – The core roadmap was updated to current state of things. Use this page to get a bird’s eye view on where Drupal core is moving towards.
  2. Ideation process – The first part of going from idea to plan got positive feedback and helpful questions and suggestions. Maybe a few words from actual maintainers and then we can make it so.
  3. Status page – We have a beautiful new design that now needs review and more code to create a complete patch. If you know your core markup and CSS, go have a look!
  4. Block place design update – An issue that iterates the design of an initial commit. We quickly discussed what the feedback should be and I added a comment to that effect right then and there. It’s an example of managing scope, pushing to focus on the actual fix first, and defer new, potentially good ideas to a followup discussion.
  5. Sample content – Kevin shared his initial thoughts and ideas for adding sample content, structure and configuration to core. More questions then answers but that’s just where we’re at for now. You are welcome to add your questions and ideas, please do.

As always, most welcome to join if you’re interested. Find us in the ux channel of the Drupal Slack room, or follow @drupalux on the twitters.

Tags: drupaluxuxmeetingdrupalplanetSub title: Topics du jour, how we work, where you can help, the usual
Categories: Drupal

Drupal Blog: Drupal 8.2, now with more outside-in

Planet Drupal - 23 August 2016 - 12:14pm

Over the weekend, Drupal 8.2 beta was released. One of the reasons why I'm so excited about this release is that it ships with "more outside-in". In an "outside-in experience", you can click anything on the page, edit its configuration in place without having to navigate to the administration back end, and watch it take effect immediately. This kind of on-the-fly editorial experience could be a game changer for Drupal's usability.

When I last discussed turning Drupal outside-in, we were still in the conceptual stages, with mockups illustrating the concepts. Since then, those designs have gone through multiple rounds of feedback from Drupal's usability team and a round of user testing led by Cheppers. This study identified some issues and provided some insights which were incorporated into subsequent designs.

Two policy changes we introduced in Drupal 8—semantic versioning and experimental modules—have fundamentally changed Drupal's innovation model starting with Drupal 8. I should write a longer blog post about this, but the net result of those two changes is ongoing improvements with an easy upgrade path. In this case, it enabled us to add outside-in experiences to Drupal 8.2 instead of having to wait for Drupal 9. The authoring experience improvements we made in Drupal 8 are well-received, but that doesn't mean we are done. It's exciting that we can move much faster on making Drupal easier to use.

In-place block configuration

As you can see from the image below, Drupal 8.2 adds the ability to trigger "Edit" mode, which currently highlights all blocks on the page. Clicking on one — in this case, the block with the site's name — pops out a new tray or sidebar. A content creator can change the site name directly from the tray, without having to navigate through Drupal's administrative interface to theme settings as they would have to in Drupal 7 and Drupal 8.1.

Making adjustments to menus

In the second image, the pattern is applied to a menu block. You can make adjustments to the menu right from the new tray instead of having to navigate to the back end. Here the content creator changes the order of the menu links (moving "About us" after "Contact") and toggles the "Team" menu item from hidden to visible.

In-context block placement

In Drupal 8.1 and prior, placing a new block on the page required navigating away from your front end into the administrative back end and noting the available regions. Once you discover where to go to add a block, which can in itself be a challenge, you'll have to learn about the different regions, and some trial and error might be required to place a block exactly where you want it to go.

Starting in Drupal 8.2, content creators can now just click "Place block" without navigating to a different page and knowing about available regions ahead of time. Clicking "Place block" will highlight the different possible locations for a block to be placed in.

Next steps

These improvements are currently tagged "experimental". This means that anyone who downloads Drupal 8.2 can test these changes and provide feedback. It also means that we aren't quite satisfied with these changes yet and that you should expect to see this functionality improve between now and 8.2.0's release, and even after the Drupal 8.2.0 release.

As you probably noticed, things still look pretty raw in places; as an example, the forms in the tray are exposing too many visual details. There is more work to do to bring this functionality to the level of the designs. We're focused on improving that, as well as the underlying architecture and accessibility. Once we feel good about how it all works and looks, we'll remove the experimental label.

We deliberately postponed most of the design work to focus on introducing the fundamental concepts and patterns. That was an important first step. We wanted to enable Drupal developers to start experimenting with the outside-in pattern in Drupal 8.2. As part of that, we'll have to determine how this new pattern will apply broadly to Drupal core and the many contributed modules that would leverage it. Our hope is that once the outside-in work is stable and no longer experimental, it will trickle down to every Drupal module. At that point we can all work together, in parallel, on making Drupal much easier to use.

Users have proven time and again in usability studies to be extremely "preview-driven", so the ability to make quick configuration changes right from their front end, without becoming an expert in Drupal's information architecture, could be revolutionary for Drupal.

If you'd like to help get these features to stable release faster, please join us in the outside-in roadmap issue.

Thank you

I'd also like to thank everyone who contributed to these features and reviewed them, including Bojhanyoroypwolaninandrewmacphersongtamaspetycompzsofimajor,SKAUGHTnod_effulgentsiaWim Leerscatchalexpott, and xjm.

And finally, a special thank you to Acquia's outside-in team for driving most of the design and implementation: tkolearywebchicktedbowGábor Hojtsytim.plunkett, and drpal.

Acquia's outside-in team celebrating that the outside-in patch was committed to Drupal 8.2 beta. Go team!

Categories: Drupal

Cacheable Cookie Handling

New Drupal Modules - 23 August 2016 - 10:44am

This module provides a framework for setting cookies that works well with page caching. It does not do anything on its own, but rather provides an API that other modules can use.

Categories: Drupal

DROWL Trademark

New Drupal Modules - 23 August 2016 - 7:08am

Simply adds a registered trademark sign (®) as <sup> element behind defined words at runtime by JavaScript.

The words to append the trademark to can be defined on the module page as comma-separated list.

BTW: This is NOT being done by an input filter intentionally, because words coming from the menu system or other areas without input filtering are also replaced this way.

Categories: Drupal

DROWL word no linebreak (white-space:nowrap at runtime)

New Drupal Modules - 23 August 2016 - 6:55am

Simply wraps defined words in a nowrap span element at runtime by JavaScript to prevent breaks within or between these words. This is for example useful for trademarks with more than one word.

The words not to break can be defined on the module page as comma-separated list.

BTW: This is NOT being done by an input filter intentionally, because words coming from the menu system or other areas without input filtering are also replaced this way.

Categories: Drupal

myDropWizard.com: Survey Results From "Is Drupal Hard?"

Planet Drupal - 23 August 2016 - 5:51am

A few weeks ago, we had A Survey! Is Drupal Hard?

First of all, thank you for taking the time to answer (even though we had a short-lived technical snafu!). At myDropWizard, we believe in transparency and openness, so I'm going to share the unfiltered data with you - as well as what my thoughts are in interpreting this non-scientific study.

The Data

Some Issues

  1. Many of those answering would be biased towards Drupal
  2. The choices were somewhat arbitrary, and no doubt some were left out
  3. There was an initial bug in the survey keeping some good data out
  4. The choice "It's about what I would expect" is probably better labeled as something more along the lines of "an average web developer should be able to accomplish their needs in a reasonable amount of time"
Analysis

So, there were plenty of flaws in the data, but that won't keep me from drawing a few conclusions - and I'm anxious to hear what others feel as well.

Drupal 7 Still a Favorite

"0" respondents claimed it "impossible" to do complex things while coupled with the lowest number of "Never Used It / No Opinion" at 5.

Categories: Drupal

Nuvole: Maintain local development configuration with Configuration Split

Planet Drupal - 23 August 2016 - 5:21am
Answering the most commonly asked question about Configuration Management in Drupal 8; and a preview of our DrupalCon training.

This post is an excerpt from the topics covered by our DrupalCon Dublin training: Drupal 8 Development - Workflows and Tools.

For the last two years we have been giving trainings and presentations at various Drupal events about configuration management and its new workflows in Drupal 8. One of the recurring questions has been:

How do I keep some configuration from being deployed? For example the devel module and its configuration?

Until now we have answered to use drush with the --skip-modules flag and then to gitignore the configuration for devel. But then you can't share the development configuration and the process is error prone when there are more modules and other configuration items that depend on the configuration you gitignore.

For some simpler cases where configuration needs to be different between environments (for example the error verbosity) the configuration override system allows to override the configuration in settings.php. This is a solution for some cases, however, you can not override which modules are enabled or override configuration that doesn't exist.

Enter: Configuration split!

Our new module Configuration split splits the configuration when exporting it with a special Drupal Console command. It can be configured to split out enabled modules and given blacklisted configuration and it will then separate all the configuration that is dependent on the listed modules or configuration. The module's settings also allow to set a folder to which the separated configuration will be exported to.

That way the configuration set which you use to deploy configuration between different environments is a subset of your development configuration and the trusty configuration system of Drupal 8 can be used unharmed. Of course when importing with the special command the split configuration is merged back, allowing you to keep your development configuration in place.

"To split" is a synonym for "to break" and as such "Configuration split" has a dangerous ring to it. This is on purpose because the exported subset is on purpose not what you have on your development site and not what you have locally tested. So you need to compensate that with a workflow that imports and verifies the configuration you are going to deploy. This is better than to import and export individual configuration because Drupal needs the whole set of configuration to do its checks.

How do I use it?

Download and enable the Configuration split module like any other module. Then configure it under admin/config/development/configuration/config_split. Set the split folder to a different folder than your normal config sync folder. If you want a prettier interface, consider using Chosen. Then use the Drupal Console command config_split:export and config_split:import to export and import respectively.

Let's look at the devel example from above. We typically version the configuration outside of the webroot in ../config/sync as seen by Drupal. (In the project root when starting a project with drupal-composer/drupal-project.) So the folder we specify for config_split would be ../config/dev. The module to filter would be Devel and the rest can be left empty. The devel.settings will be detected automatically. Note though that the system.menu.devel does not depend on the devel module and can not be detected automatically, but it is easy to add it to the blacklisted config and it could theoretically be deployed without breaking anything.

The config_split.settings.yml could look something like this:

folder: ../config/dev
module:
  devel: 0
theme: {  }
blacklist:
  - system.menu.devel

Finally the following command will export the configuration to the default sync directory without the devel module enabled and export the devel configuration into the dev directory.
web$ ../vendor/bin/drupal config_split:export

Now if you would import the configuration through the UI or with drush cim the devel module would be un-installed, and you can do that to see the site without its development configuration. However, If you want the development configuration to stay or become active and the devel module installed use the following command:
web$ ../vendor/bin/drupal config_split:import

How does it work internally?

We implemented a StorageWrapper that allows filters to interact with the configuration after it has been read and before it is written to the wrapped FileStorage during the import and export operation. The SplitFilter has a secondary storage and decides where to read from or write to. This is a very similar concept to what drush does with its --skip-modules flag since we will want to easily integrate this with drush in the future.

What comes next?

The module is still in an early development stage and some more additions in the scope of splitting configuration could be added. The subset without the split configuration could be verified after exporting it and we could warn the user if it couldn't be imported. Or for example we currently use only config_split.settings but if the need arises we could support multiple split configurations. Or we could add a "gray list" to ignore some configuration that exists rather than removing it when splitting, essentially making it a configuration override outside of the scope of Drupal's runtime. This could be useful when maintaining several sites that are almost the same but all have their little "special snowflake" configuration which in turn could be synchronized with the normal workflow.

It is important to understand that the configuration system of Drupal has limitations that are there for a good reason. Most of them are to ensure data integrity and robustness and reliability of the synchronisation and so on. In other words measures to protect you from accidentally breaking your site. Using tools like config_split or drush --skip-modules you circumvent some of these security and integrity checks so use them with caution.

Since the module is not required for the regular functioning of a Drupal 8 site (it can even be used to blacklist itself) it can already be used in the development process of your current projects already. Your feedback is welcome, see you in the issue queue.

Tags: Drupal PlanetDrupal 8DrupalConTrainingCode Driven Development
Categories: Drupal

Rakesh's DSoC 16 blog: GSoC Final Submission

Planet Drupal - 23 August 2016 - 1:59am
GSoC Final Submission rakesh Tue, 08/23/2016 - 14:29
Categories: Drupal

Download all files

New Drupal Modules - 23 August 2016 - 1:41am

This module will give the option to download the all files attached to a node.

Categories: Drupal

Drupal 8.2, now with more outside-in

Dries Buytaert - 23 August 2016 - 12:10am

Over the weekend, Drupal 8.2 beta was released. One of the reasons why I'm so excited about this release is that it ships with "more outside-in". In an "outside-in experience", you can click anything on the page, edit its configuration in place without having to navigate to the administration back end, and watch it take effect immediately. This kind of on-the-fly editorial experience could be a game changer for Drupal's usability.

When I last discussed turning Drupal outside-in, we were still in the conceptual stages, with mockups illustrating the concepts. Since then, those designs have gone through multiple rounds of feedback from Drupal's usability team and a round of user testing led by Cheppers. This study identified some issues and provided some insights which were incorporated into subsequent designs.

Two policy changes we introduced in Drupal 8 — semantic versioning and experimental modules — have fundamentally changed Drupal's innovation model starting with Drupal 8. I should write a longer blog post about this, but the net result of those two changes is ongoing improvements with an easy upgrade path. In this case, it enabled us to add outside-in experiences to Drupal 8.2 instead of having to wait for Drupal 9. The authoring experience improvements we made in Drupal 8 are well-received, but that doesn't mean we are done. It's exciting that we can move much faster on making Drupal easier to use.

In-place block configuration

As you can see from the image below, Drupal 8.2 adds the ability to trigger "Edit" mode, which currently highlights all blocks on the page. Clicking on one — in this case, the block with the site's name — pops out a new tray or sidebar. A content creator can change the site name directly from the tray, without having to navigate through Drupal's administrative interface to theme settings as they would have to in Drupal 7 and Drupal 8.1.

Making adjustments to menus

In the second image, the pattern is applied to a menu block. You can make adjustments to the menu right from the new tray instead of having to navigate to the back end. Here the content creator changes the order of the menu links (moving "About us" after "Contact") and toggles the "Team" menu item from hidden to visible.

In-context block placement

In Drupal 8.1 and prior, placing a new block on the page required navigating away from your front end into the administrative back end and noting the available regions. Once you discover where to go to add a block, which can in itself be a challenge, you'll have to learn about the different regions, and some trial and error might be required to place a block exactly where you want it to go.

Starting in Drupal 8.2, content creators can now just click "Place block" without navigating to a different page and knowing about available regions ahead of time. Clicking "Place block" will highlight the different possible locations for a block to be placed in.

Next steps

These improvements are currently tagged "experimental". This means that anyone who downloads Drupal 8.2 can test these changes and provide feedback. It also means that we aren't quite satisfied with these changes yet and that you should expect to see this functionality improve between now and 8.2.0's release, and even after the Drupal 8.2.0 release.

As you probably noticed, things still look pretty raw in places; as an example, the forms in the tray are exposing too many visual details. There is more work to do to bring this functionality to the level of the designs. We're focused on improving that, as well as the underlying architecture and accessibility. Once we feel good about how it all works and looks, we'll remove the experimental label.

We deliberately postponed most of the design work to focus on introducing the fundamental concepts and patterns. That was an important first step. We wanted to enable Drupal developers to start experimenting with the outside-in pattern in Drupal 8.2. As part of that, we'll have to determine how this new pattern will apply broadly to Drupal core and the many contributed modules that would leverage it. Our hope is that once the outside-in work is stable and no longer experimental, it will trickle down to every Drupal module. At that point we can all work together, in parallel, on making Drupal much easier to use.

Users have proven time and again in usability studies to be extremely "preview-driven", so the ability to make quick configuration changes right from their front end, without becoming an expert in Drupal's information architecture, could be revolutionary for Drupal.

If you'd like to help get these features to stable release faster, please join us in the outside-in roadmap issue.

Thank you

I'd also like to thank everyone who contributed to these features and reviewed them, including Bojhan, yoroy, pwolanin, andrewmacpherson, gtamas, petycomp, zsofimajor, SKAUGHT, nod_, effulgentsia, Wim Leers, catch, alexpott, and xjm.

And finally, a special thank you to Acquia's outside-in team for driving most of the design and implementation: tkoleary, webchick, tedbow, Gábor Hojtsy, tim.plunkett, and drpal.

Acquia's outside-in team celebrating that the outside-in patch was committed to Drupal 8.2 beta. Go team!
Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal