Newsfeeds

Roman Agabekov: How we applied SA-CORE-2018-002 for several dozen Drupal-powered sites

Planet Drupal - 9 April 2018 - 2:41am
How we applied SA-CORE-2018-002 for several dozen Drupal-powered sites Submitted by admin on Mon, 04/09/2018 - 09:41

Here is a brief account of how we applied the most critical Drupal security update in the past couple of years to web projects we support and monitor.

Tags
Categories: Drupal

Lucius Digital: 26 Cool Drupal modules for site builders | April 2018

Planet Drupal - 9 April 2018 - 1:52am
The biggest ‘module’ being updated was the Drupal core of course: Drupal 8.5.0 was released about a month ago, read more. Also, everything else what stood out to the module updates of last month, enjoy:
Categories: Drupal

Fuzzy Thinking: Explaining a Dice Pool

RPGNet - 9 April 2018 - 12:00am
Fuzzy pools
Categories: Game Theory & Design

Jeff Geerling's Blog: Installing PHP 7 and Composer on Windows 10

Planet Drupal - 8 April 2018 - 8:23pm

I am working a lot on Composer-based Drupal projects lately (especially gearing up for DrupalCon Nashville and my joint workshop on Drupal and Composer with Matthew Grasmick), and have been trying to come up with the simplest solutions that work across macOS, Linux, and Windows. For macOS and Linux, getting PHP and Composer installed is fairly quick and easy. However, on Windows there seem to crop up little issues here and there.

Since I finally spent a little time getting the official version of PHP for native Windows installed, I figured I'd document the process here. Note that many parts of this process were learned from the concise article Install PHP7 and Composer on Windows 10 from the website KIZU 514.

Install PHP 7 on Windows 10

Categories: Drupal

Love Huria: Cool things you can do with Sass - Part 1

Planet Drupal - 8 April 2018 - 5:00pm

I have been using Sass for like past two years and now I’m a huge fan. Even though we were doing pretty much alright with writing CSS but it never gave us that kind of flexibility that Sass provides like one of the things could be managing the complexity in stylesheets as our apps get more and more substantial. Anyways, Enough about my experience already as today we have got a bunch of cool things to cover!

What is Sass?

It’s a CSS preprocessor, that’s what you will get if you start googling and its true but hold that...

Categories: Drupal

Wim Leers: API-First Drupal: file uploads — 572 comments summarized

Planet Drupal - 8 April 2018 - 2:11pm

This blog post summarizes the 572 comments spanning 5 years and 2 months to get REST file upload support in #1927648 committed. Many thanks to everyone who contributed!

From February 2013 until the end of March 2017, issue #1927648 mostly … lingered. On April 3 of 2017, damiankloip posted an initial patch for an approach he’d been working on for a while, thanks to Acquia (my employer) sponsoring his time. Exactly one year later his work is committed to Drupal core. Shaped by the input of dozens of people! Just *look at that commit message!*

Background: API-First Drupal: file uploads!.

  • Little happened between February 2013 (opening of issue) and November 2015 (shipping of Drupal 8).
  • Between February 2013 and April 2014, only half a dozen comments were posted, until moshe weitzman aptly said Still a gaping hole in our REST support. Come on Internets ….
  • The first proof-of-concept patch followed in August 2014 by juampynr, but was still very rough. A fair amount of iteration occurred that month, between juampynr and Arla. It used base64 encoding, which means it needed 33% more bytes on the wire to transfer a file than if it were transmitted in binary rather than base64.
  • Then again a period of silence. Remember that this was around the time when we were trying to get Drupal 8 to a shippable state: the #1 priority was to stabilize, fix critical bugs. Not to add missing features, no matter how important. To the best of my knowledge, the funding for those who originally worked on Drupal 8’s REST API had also dried up.
  • In May 2015, another flurry of activity occurred, this time fueled by marthinal. Comment #100 was posted. Note that all patches up until this point had zero validation logic! Which of course was a massive security risk. marthinal is the first to state that this is really necessary, and does a first iteration of that.
  • A few months of silence, and then again progress in September, around DrupalCon Barcelona 2015. dawehner remarked in a review on the lack of tests for the validation logic.
  • In February 2016 I pointed out that I’m missing integration tests that prove the patch actually works. To which Berdir responded that we’d first need to figure out how to deal with File entity type access control!
  • Meanwhile, marthinal works on the integration test coverage in 2016. And … we reached comment #200.
  • In May 2016, I did a deep review, and found many problems. Quick iterations fix those problems! But then damiankloip pointed out that despite the issue being about the general File (de)serialization problem, it actually only worked for the HAL normalization. We also ended up realizing that the issue so far was about stand-alone File entity creation, even though those entities cannot be viewed stand-alone nor can they be created stand-alone through the existing Drupal UI: they can only be created to be referenced from file fields. And consequently, we have no access control logic for this yet, nor is it clear how access control should work; nor is it how validation should work! Berdir explained this well in comment 232. This lead us to explore moving parts of https://www.drupal.org/project/file_entity into core (which would be a hard blocker). The issue then went quiet again.
  • In July 2016, garphy pointed out that large file uploads still were not yet supported. Some work around that happened. In September, kylebrowning stressed this again, and provided a more detailed rationale.
  • Then … silence. Until damiankloip posted comment #281 on April 3, 2017. Acquia was sponsoring him to work on this issue. Damian is the maintainer of the serialization.module component and therefore of course wanted to see this issue get fixed. My employer Acquia agreed with my proposal to sponsor Damian to work on REST file upload support. Because after 280 comments, some fundamental capabilities are still absent: this was such a complex issue, with so many concerns and needs to balance, that it was nigh impossible to finish it without dedicated time.
    To get this going, I asked Damian to look at the documentation for a bunch of well-known sites to observe how they handle file uploads. I also asked him to read the entire issue. Combined, this should give him a good mental map of how to approach this.
  • #281 was a PoC patch that only barely worked but did support binary (non-base64) uploads. damiankloip articulated the essential things yet to be figured out: validation and access checking. Berdir chimes in with his perspective on that in #291 … in which he basically outlines what ended up in core! Besides Berdir, dagmar, dawehner, garphy, dabito, ibustos all chimed in and influenced the patch. Berdir, damiankloip and I had a meeting about how to deal with validation, and I disagreed with with both of them. And turned out to be very wrong! More feedback is provided by the now familiar names, and the intense progress/activity continues for two months, until comment #376!
  • Damian got stuck on test coverage — and since I’d written most of the REST test coverage in the preceding months, it made sense for me to pick up the baton from Damian. So I did that in July 2017, just making trivial changes that were hard to figure out. Damian then continued again, expanding test coverage and finding a core bug in the process! And so comment #400 was reached!
  • At the beginning of August, the patch was looking pretty good, so I did an architectural review. For the first time, we realized that we first needed to fix the normalization of File entities before this could land. And many more edge cases need to be tested for us to be confident that there were no security vulnerabilities. blainelang did manual testing and posted super helpful feedback based on his experience. Blaine and Damian tag-teamed for a good while, then graphy chimed in again, and we entered September. Then dawehner chimed in once more, followed by tedbow.
  • On September 6 2017, in comment #452 I marked the issue postponed on two other issues, stating that it otherwise looked tantalizingly close to RTBC. aheimlich found a problem nobody else had spotted yet, which Damian fixed.
  • Silence while the other issues get fixed … and December 21 2017 (comment #476), it finally was unblocked! Lots of detailed reviews by tedbow, gabesullice, Berdir and myself followed, as well as rerolls to address them, until I finally RTBC‘d it … in comment #502 on February 1 2018.
  • Due to the pending Drupal 8.5 release, the issue mostly sat waiting in RTBC for about two months … and then got committed on April 3 2018!!!

Damian’s first comment (preceded by many hours of research) was on April 3, 2017. Exactly one year later his work is committed to Drupal core. Shaped by the input of dozens of people! Just look at that commit message!

  • API
  • Acquia
  • Drupal
Categories: Drupal

Wim Leers: API-First Drupal: file uploads!

Planet Drupal - 8 April 2018 - 2:09pm

Drupal 8’s REST API has been maturing steadily since the Drupal 8.0.0 was released in November 2015. One of the big missing features has been file upload support. As of April 3 2018, Drupal 8.6 will support it, when it ships in September 2018! See the change record for the practical consequences: https://www.drupal.org/node/2941420.

It doesn’t make sense for me to repeat what is already written in that change record: that already has both a tl;dr and a practical example.

What I’m going to do instead, is give you a high-level overview of what it took to get to this point: why it took so long, which considerations went into it, why this particular approach was chosen. You could read the entire issue (#1927648), but … it’s one of the longest issues in Drupal history, at 572 comments1. You would probably need at least an entire workday to read it all! It’s also one of the longest commit messages ever, thanks to the many, many people who shaped it over the years:

Issue #1927648 by damiankloip, Wim Leers, marthinal, tedbow, Arla, alexpott, juampynr, garphy, bc, ibustos, eiriksm, larowlan, dawehner, gcardinal, vivekvpandya, kylebrowning, Sam152, neclimdul, pnagornyak, drnikki, gaurav.goyal, queenvictoria, kim.pepper, Berdir, clemens.tolboom, blainelang, moshe weitzman, linclark, webchick, Dave Reid, dabito, skyredwang, klausi, dagmar, gabesullice, pwolanin, amateescu, slashrsm, andypost, catch, aheimlich: Allow creation of file entities from binary data via REST requests

Thanks to all of you in that commit message!

I hope it can serve as a reference not just for people interested in Drupal, but also for people outside the Drupal community: there is no One Best Practice Way to handle file uploads for RESTful APIs. There is a surprising spectrum of approaches2. Some even avoid this problem space even entirely, by only allowing to “upload” files by sending a publicly accessible URL to the file. Read on if you’re interested. Otherwise, go and give it a try!

Design rationale

General:

  • Request with Content-Type: application/octet-stream aka “raw binary” as its body, because base64-encoded means 33% more bytes, implying both slower uploads and more memory consumption. Uploading videos (often hundreds of megabytes or even gigabytes) is not really feasible with base64 encoding.
  • Request header Content-Disposition: file; filename="cat.jpg" to name the uploaded file. See the Mozilla docs. This also implies you can only upload one file per request. But of course, a client can issue multiple file upload requests in parallel, to achieve concurrent/batch uploading.
  • The two points above mean we reuse as much as possible from existing HTTP infrastructure.
  • Of course it does not make sense to have a Content-Type: application/octet-stream as the response. Usually, the response is of the same MIME type as the request. File uploads are the sensible exception.
  • This is meant for the raw file upload only; any metadata (for example: source or licensing) cannot be associated in this request: all you can provide is the name and the data for the file. To associate metadata, a second request to “upgrade” the raw file into something richer would be necessary. The performance benefit mentioned above more than makes up for the RTT of a second request in almost all cases.

PHP-specific:

  • php://input because otherwise limited by the PHP memory limit.

Drupal-specific:

  • In the case of Drupal, we know that it always represents files as File entities. They don’t contain metadata (fields), at least not with just Drupal core; it’s the file fields (@FieldType=file or @FieldType=image) that contain the metadata (because the same image may need different captions depending on its use, for example).
  • When a file is uploaded for a field on a bundle on an entity type, a File entity is created with status=false. The response contains the serialized File entity.
  • You then need a second request to make the referencing entity “use” the File entity, which will cause the File entity to get status=true.
  • Validation: Drupal core only has the infrastructure in place to use files in the context of an entity type/bundle’s file field (or derivatives thereof, such as image fields). This is why files can only be uploaded by specifying an entity type ID, bundle ID and field name: that’s the level where we have settings and validation logic in place. While not ideal, it’s pragmatic: first allowing generic file uploads would be a big undertaking and somewhat of a security nightmare.
  • Access control is similar: you need create access for the referencing entity type and field edit access for the file field.
Result

If we combine all these choices, then we end up with a new file_upload @RestResource plugin, which enables clients to upload a file:

  1. by POSTing the file’s contents
  2. to the path /file/upload/{entity_type_id}/{bundle}/{field_name}, which means that we’re uploading a file to be used by the file field of the specified entity type+bundle, and the settings/constraints of that field will be respected.
  3. … don’t forget to include a ?_format URL query argument, this determines what format the response will be in
  4. sending file data as a application/octet-stream binary data stream, that means with a Content-Type: application/octet-stream request header. (This allows uploads of an arbitrary size, including uploads larger than the PHP memory limit.)
  5. and finally, naming the file using the Content-Disposition: file; filename="filename.jpg" header
  6. the five preceding steps result in a successfully uploaded file with status=false — all that remains is to perform a second request to actually start using the file in the referencing entity!
Four years in the making — summarizing 572 comments

From February 2013 until the end of March 2017, issue #1927648 mostly … lingered. On April 3 of 2017, damiankloip posted an initial patch for an approach he’d been working on for a while, thanks to Acquia (my employer) sponsoring his time. Exactly one year later his work is committed to Drupal core. Shaped by the input of dozens of people! Just look at that commit message!

Want to actually read a summary of those 572 comments? I got you covered!

  1. It currently is the fifth longest Drupal core issue of all time! The first page, with ~300 comments, is >1 MB of HTML. ↩︎

  2. Examples: Contentful, Twitter, Dropbox and others↩︎

  • API
  • Acquia
  • Drupal
Categories: Drupal

Another Drop in the Drupal Sea: Migrating from Drupal 6 to Drupal 8

Planet Drupal - 8 April 2018 - 9:31am
Migrating from Drupal 6 to Drupal 8 Marc Sun, 04/08/2018 - 11:31am

Well, I've finally done it! I migrated this blog from Drupal 6 to Drupal 8. I did a test run yesterday with a personal blog of mine and found the process was relatively easy. Both sites are relatively simple.

There are other blog posts about the process as well as documentation on Drupal.org so I won't repeat lots of details.

I'm running Drupal 8.5.1 as of this blog post. I chose to use all of the various migration modules that come with Drupal 8 core, including the two marked as experimental. Once I had them enabled I clicked the link to get to the upgrade form in the UI. One of the sites did have file uploads and all of them were pulled in seamlessly. I had created a backup of the sites/[site-name] directory and placed it in my new Drupal 8 sites directory.

Here are issues I encountered:

  • Administration Menu is (apparently) not properly ported to Drupal 8 and it blew things up on the site yesterday. I had to manually clean things up in the database so that module was not enabled in my Drupal 8 site and clear cache.
  • The taxonomy term reference to the Tags vocabulary needed the field setting updated so that it selected the Tags vocabulary.
  • When I click the user in the Toolbar it does not switch the tray so that it shows View profile, Edit profile and Log out. (That's still an issue as I write this. I haven't investigated it enough to figure out what's going wrong, nor have I filed an issue.)
  • The feed that taxonomy provides for terms has changed slightly. I filed an issue to get Planet Drupal to use the new feed.
  • No views were imported.
  • The pathauto patterns weren't imported.
  • Disqus doesn't handle the migration.
  • Other than those things, I can't say I ran into much of anything else. And, aside from the site blowing up from Administration Menu, there wasn't much that presented a real challenge.

If you are reading this post on Planet Drupal, then you know I'm back up and running!

I'll still need to theme this site again. And I'll need to replace some functionality that was previously provided by Advanced Blog. I haven't yet installed and tested out the Drupal 8 port of Tagadelic.

One more note: I decided to just delete the comments that I had for the Drupal 6 version of this site since I don't want to use the Comment module, preferring to use Disqus instead.

Comments
Categories: Drupal

Video Game Deep Cuts: A WiLD eSports Mario Approaches

Social/Online Games - Gamasutra - 7 April 2018 - 7:31pm

This week's highlights include the current fate of Michel Ancel's WiLD, a 'state of eSports' profile, Super Mario RPG archival interview goodness, & much more. ...

Categories: Game Theory & Design

Madness

New Drupal Modules - 7 April 2018 - 4:30pm

The most merciful thing in the world, I think, is the inability of the human mind to correlate all its contents.
~H.P. Lovecraft

The Madness module provides a way to monitor the insanity of your site's users. It may even induce a little madness of it's own along the way! Among other features, it provides a block to list your users sorted by how mad they've become.

Categories: Drupal

Cfr operations

New Drupal Modules - 7 April 2018 - 12:06pm

Defines an OperationInterface, and exposes Operation objects as plugins via Cfr Plugin API.

Visit admin/operations/cfrop as administrator, and execute any of those operations.

This module can sometimes be a convenient replacement for devel/php, for custom drush commands, or even for hook_update_N().

Or, you can create and execute your operations from drush or hook_update_N() or anywhere.

Categories: Drupal

Basic Page Feature

New Drupal Modules - 7 April 2018 - 11:32am

Basic page of drupal core on Feature.

Provides basic page content type and related configuration. Use basic pages for your static content, such as an ''About us'' page.

Categories: Drupal

Review Roundup

Tabletop Gaming News - 7 April 2018 - 11:00am
As I type up this post ahead of its actual publication time, when you read this, I’ll be hip-deep in my new D&D game. At least, that’s the hope. Session 0 starts at noon, so I gotta finish this up and then head out. But I know how much you all desperately desire these reviews, […]
Categories: Game Theory & Design

Drupal core announcements: Core topic discussions at DrupalCon Nashville

Planet Drupal - 7 April 2018 - 8:51am

DrupalCon Nashville includes a full track of core conversations where you can learn about current topics in Drupal core development, and a week of sprints where you can participate in shaping Drupal's future.

In addition to the core conversations, we have a few meetings on specific topics for future core development. These meetings will be very focused, so contact the listed organizer for each if you are interested in participating. There are also birds-of-a-feather (BoF) sessions, which are open to all attendees without notice.

Also be sure to watch Dries' keynote for ideas about Drupal's future! Check out the extended Dries Q&A session on Thursday as well to get even more questions answered.

Time Topic Organizer Monday, 9 April, 10:00 Configuration validation to support REST and JS Wim Leers Tuesday, 10 April, 10:45 Improving Drupal's evaluator experience (BoF) tedbow Tuesday, 10 April, 15:45 Layout Initiative meeting tim.plunkett Wednesday, 11 April, 10:45 Official local development environment (BoF) tedbow Wednesday, 11 April, 14:15 Media roadmap meeting phenaproxima Friday, 13 April, 09:00 Release cycle changes discussion (only core committers) Gábor Hojtsy Friday, 13 April, 11:00 Automated security updates hestenet
Categories: Drupal

Video Game Deep Cuts: A WiLD eSports Mario Approaches - by Simon Carless

Gamasutra.com Blogs - 7 April 2018 - 6:02am
This week's highlights include the current fate of Michel Ancel's WiLD, a 'state of eSports' profile, Super Mario RPG archival interview goodness, & much more.
Categories: Game Theory & Design

Commerce Guys: Visit the Commerce Saloon at DrupalCon Nashville

Planet Drupal - 6 April 2018 - 11:30pm

Commerce Guys is joining forces with some of our Technology Partners and several contributing agencies to promote Drupal Commerce at DrupalCon Nashville from April 10-12, 2018.

We are colocating our booths to create the Commerce Saloon, your one stop shop to learn all things Drupal Commerce. Our booths will feature jam band instruments, multiple demos (including a new store theme), exclusive swag, and case studies to help you learn how teams are succeeding with Drupal Commerce.

Come try Drupal Commerce 2.x

DrupalCon Nashville is the perfect time to learn what's new by joining our week long sprint at the "Power Up" tables by the Commerce Saloon. We'll be training new contributors and working on the project together using sprint kits powered by DRUD's ddev local development environment.

We prepared the following sessions to help you learn more about Drupal Commerce and its ecosystem:

  • Contributing to Drupal Commerce (for beginners)
    Tuesday, April 10th, 12:00 PM | Commerce Saloon: "Power Up" Table | By: Matt Glaman
  • Drupal Commerce 2.x Update and Roadmap Planning (add it to your conference schedule)
    Tuesday, April 10th, 3:45 PM | Room: 203A | By: Ryan Szrama / Bojan Zivanovic
  • Marketing and Selling the Drupal Commerce Ecosystem (as seen at DrupalCon Vienna)
    Wednesday, April 11th, 10:45 AM | Commerce Saloon: "Power Up" Table | By: Ryan Szrama
  • Decoupled Drupal Commerce / REST APIs (for developers)
    Wednesday, April 11th, 3:45 PM | Commerce Saloon: "Power Up" Table | By: Matt Glaman
  • Subscriptions and Recurring Billing in Commerce 2.x
    Thursday, April 12th, 10:45 AM | Commerce Saloon: "Power Up" Table | By: Bojan Zivanovic

Hear from every Commerce Saloon sponsor

There's a lot to be said about how Drupal Commerce is making merchant and agency teams more productive, and you don't just have to take our word for it. Each Commerce Saloon sponsor has something unique to teach you about succeeding in eCommerce, and we encourage you to seek them and their sessions out:

  • Acro Media (Booth 803) - Test drive Commerce POS at their booth and hear its business case from Becky and Josh! You can also purchase (for free) a limited edition Drupal Commerce t-shirt through Acro Media's demo site.
  • Authorize.Net (Booth 911) - Authorize.Net offers several payment tools that let merchants get paid securely online. We've joined forces to demo Accept.js, their new drop-in solution for PCI compliant payment.
  • Bluespark (Booth 908) - Bluespark contributed significantly to Commerce 2.x development via their Sport Obermeyer project (check out their awesome case study) and have long promoted Drupal Commerce as a hotel booking solution.
  • Commerce Guys (Booth 809) - Stop by for a demo of Belgrade, our new default store theme for Commerce 2.x, or for a demo of, Lean Commerce Reports, our first SaaS product that offers a plug-n-play sales dashboard for Drupal Commerce.
  • Drupal Commerce Technology Partners (Both 811) - This booth features representatives and demos from Avalara and Lockr. Talk to them about tax automation and about eCommerce security respectively.
  • MailChimp (Booth 813) - MailChimp has revitalized their approach to eCommerce email marketing and has a full integration available for Drupal in the MailChimp eCommerce module. Stop by to learn more!
  • Zivtech (Booth 909) - Zivtech has a long history of implementing eCommerce in Drupal, including joining the Drupal Commerce project in late 2009. Talk to them about using Drupal Commerce as a front-end for third party applications.

Finally, be sure to catch Promet Source's showcase session on helping The Corning Museum of Glass migrate from Commerce 1.x to Commerce 2.x and Rick Manelius's session on the dos and don'ts Drupal Commerce project estimation.

Schedule Time to Meet

If you're heading to DrupalCon, we'd love to chat about Drupal Commerce with you. Use our meeting request form to get on our calendar to discuss a particular project or need, or subscribe to our newsletter to be kept in the loop more generally.

Categories: Drupal

Aegir Hosting Tasks Jenkins

New Drupal Modules - 6 April 2018 - 7:33pm

This module allows using Jenkins as a Hosting Task Runner.

Setup

Get jenkins running. The Docker images are nice, or you can install it natively.

Copy the jenkins config from this module to the jenkins home directory.

cp -rf /var/aegir/devmaster-0.x/profiles/devshop/modules/contrib/hosting_task_jenkins/jenkins_home/* /var/jenkins_home

Visit "Manage Jenkins" > "Reload config from disk" button for the changes to take effect.

Categories: Drupal

Dcycle: Fast-track local Drupal 8 core patch development and testing

Planet Drupal - 6 April 2018 - 5:00pm

The process documented process for setting up a local environment and running tests locally is, in my opinion, so complex that it can be a barrier to even determined developers.

For those wishing to locally test and develop core patches, I think it is possible to automate the process down to a few steps and few minutes; here is an example with a core issue, #2273889 Don’t use one language’s plural index formula with another language’s string in the case of untranslated strings using format_plural(), which, at the time of this writing, results in the number 0 being displayed as 1 in certain cases.

Is it possible to start useful local development on this within 10 minutes on a computer with nothing installed except Docker? Let’s try…

Step 1: install Docker

Install and launch Docker. Everything we need, Apache web server, MySql server, Drush, Drupal, will reside on Docker containers, so we won’t need to install anything locally except Docker.

Step 2: launch a dev environment

I have create a project hosted on GitHub which will help you set up everything you need in Docker contains without local dependencies other than Docker, or any manual steps. Set it up by running:

git clone https://github.com/dcycle/drupal8_core_dev_helper.git && \ cd drupal8_core_dev_helper && \ ./scripts/deploy.sh`

This will create everything you need: a webserver container and database container, and your Drupal core code which will be placed in ./drupal8_core_dev_helper/drupal; near the end of the output of ./scripts/deploy.sh, you will see a login link to your development environment. Confirm you can access that local development environment at an address like http://0.0.0.0:SOME-PORT. (The port is random.)

The first time you run this, it will have to download Docker images with Drupal, MySQL, and install everything you need for local development. Future runs will be a lot faster.

See the project’s README for more details.

In your dev environment, you can confirm that the problem exists (provided the issue has not yet been fixed) by following the instructions in the “To reproduce this problem:” section of the issue description on your local development environment.

Any calls to drush can be run on the Docker container like so:

docker-compose exec drupal /bin/bash -c 'drush ...'

For example:

docker-compose exec drupal /bin/bash -c 'drush en locale language -y'

If you want to run drush directly, you can connect to your container like so:

docker-compose exec drupal /bin/bash

This will result in the following prompt on the container:

root@4744431352a1:/var/www/html#

Now you can run drush commands directly on the container:

drush eval "print_r(\Drupal::translation()->formatPlural(0, '1 whatever', '@count whatevers', array(), array('langcode' => 'fr')) . PHP_EOL);"

Because the drupal8_core_dev_helper project also pre-installs devel on your environment, you can also confirm the problem exists by visiting /devel/php and executing:

dpm((string) (\Drupal::translation()->formatPlural(0, '1 whatever', '@count whatevers', array(), array('langcode' => 'fr'))));

Whether you do this by Drush or /devel/php, the result should be the same if the issue has not been resolved: 1 whatever instead of 0 whatevers.

Step 3: get a local version of the patch and apply it

In this example, we’ll look at the patch in comment #32 of our formatPlural issue, referenced above. If the issue has been resolved since this blog post has been written, follow along with another patch.

cd drupal8_core_dev_helper curl https://www.drupal.org/files/issues/2018-04-07/2273889-31-core-8.5.x-plural-index-no-test.patch -O cd ./drupal && patch -p1 < ../2273889-31-core-8.5.x-plural-index-no-test.patch

You have now patched your local version of Drupal. You can try the “0 whatevers” test again and the bug should be fixed.

Running tests

Now the real fun begins… and the “fast-track” ends.

For any patch to be considered for inclusion in Drupal core, it will need to (a) not break existing tests; and (b) provide a test which, without the patch, confirms that the problem exists.

Let’s head back to comment #32 of issue #2273889 and see if our patch is breaking anything. Clicking on “PHP 7 & MySQL 5.5 23,209 pass, 17 fail” will bring us to the test results page, which at first glance seems indecipherable. You’ll notice that our seemingly simple change to the PluralTranslatableMarkup.php file is causing a number of tests to fail: HelpEmptyPageTest, EntityTypeTest…

Let’s start by finding the test which is most likely to be directly related to our change by searching on the test results page for the string “PluralTranslatableMarkupTest” (this is name of the class we changed, with the word Test appended), which shows that it is failing:

Testing Drupal\Tests\Core\StringTranslation\PluralTranslatableMarkupTest .E

We need to figure out where that file resides, by typing:

cd /path/to/drupal8_core_dev_helper/drupal/core find . -name 'PluralTranslatableMarkupTest.php'

This tells us it is at ./tests/Drupal/Tests/Core/StringTranslation/PluralTranslatableMarkupTest.php.

Because we have a predictable Docker container, we can relatively easily run this test locally:

cd /path/to/drupal8_core_dev_helper docker-compose exec drupal /bin/bash -c 'cd core && \ ../vendor/bin/phpunit \ ./tests/Drupal/Tests/Core/StringTranslation/PluralTranslatableMarkupTest.php'

You should now see the test results for only PluralTranslatableMarkupTest:

PHPUnit 6.5.7 by Sebastian Bergmann and contributors. Testing Drupal\Tests\Core\StringTranslation\PluralTranslatableMarkupTest .E 2 / 2 (100%) Time: 16.48 seconds, Memory: 6.00MB There was 1 error: 1) Drupal\Tests\Core\StringTranslation\PluralTranslatableMarkupTest::testPluralTranslatableMarkupSerialization with data set #1 (2, 'plural 2') Error: Call to undefined method Mock_TranslationInterface_4be32af3::getStringTranslation() /var/www/html/core/lib/Drupal/Core/StringTranslation/PluralTranslatableMarkup.php:150 /var/www/html/core/lib/Drupal/Core/StringTranslation/PluralTranslatableMarkup.php:121 /var/www/html/core/tests/Drupal/Tests/Core/StringTranslation/PluralTranslatableMarkupTest.php:31 ERRORS! Tests: 2, Assertions: 1, Errors: 1.

How to fix this, indeed whether this will be fixed, is a whole nother story, a story fraught with dependency injection, mock objects, method stubs… More an adventure, really, than a story. An adventure which deserves to be told, just not right now.

The process documented process for setting up a local environment and running tests locally is, in my opinion, so complex that it can be a barrier to even determined developers.

Categories: Drupal

Steamforged Launches Godtear Kickstarter

Tabletop Gaming News - 6 April 2018 - 3:00pm
I’m a big proponent of “play the figs you want to play.” I mean, I normally pick my options for games starting with how they look, then moving onto how they play. And it can be tough when part of one faction in a game looks good, but part of another one also looks good. […]
Categories: Game Theory & Design

Wyrd Previews Motor Scout For The Other Side

Tabletop Gaming News - 6 April 2018 - 2:00pm
In combat, knowing the location and strength of the enemy is vital. Scouts have been used for thousands of years to find out just that sort of information. While that spot had been held by horse-riding cavalrymen for the longest time, in the motor age, it’s being taken over by vehicles specifically designed for the […]
Categories: Game Theory & Design

Pages

Subscribe to As If Productions aggregator