Å·±¦ÓéÀÖ

Last month at , I was honoured to receive the , named after one of Drupal’s most kindhearted and prolific contributors, who we lost far too soon to ALS back in 2015. (If you were not lucky enough to know Aaron, you can read more about him through many others� words in his )

I am tremendously grateful to so, SO many people who have mentored and encouraged me along this journey, from all the way back when I was a wee Google Summer of Code student in 2005 trying to figure out what on earth a “hook� was. :D Each and every time I became excited and passionate about a new way to help the project—joining ALL of the teams (Documentation, Webmasters, Security, etc.), becoming a Drupal core maintainer, joining the Drupal Association Board, improving contribution tools and processes, driving user experience improvements and quality assurance efforts, scaling the governance of the project, etc.—folks would rally to help set me up for success, and assist in ripping blockers out of the way.

The Drupal community really is something incredibly special. There’s an innate desire to enthusiastically share knowledge, to celebrate the wins of others, and to jump in and help where help is needed. We’ve forged long-standing friendships (and at least a couple of marriages! :D), we’ve had many, many laughs (and also a few cries), and we’ve all come together from all over the world to build something truly amazing. Come for the Code, stay for the Community, indeed. :) So an immense THANK YOU to each and every one of you who contributes every day to making this community so truly awesome. (That word gets overused a lot, especially by me ;), but in this case it is extremely apt. <3)

Incidentally, a few people have also asked how I did not have this award before. First, I was a founding member of the , so receiving it back then would’ve been a supreme conflict of interest. :P Additionally, much of my community work over the years has also been sponsored by and , so that it could have a bigger impact, and this was a *very* unique privilege that most other community contributors do not have. The list of previous winners includes such community luminaries as , , , and more. I’m *very* happy they all got the spotlight before me. :)

While these days I'm making community happen over at , I'm still very much involved in the Drupal community, and it was GREAT to see so many friendly faces at DrupalCon! :D Thank you SO much again for this incredible honour. <3

°Õ²¹²µ²õ:Ìý

What the what?!

Sad Drupal is Sad. :'(

Well, might as well get right down to it... I've made the incredibly difficult decision to leave , and my employment there officially ended last week. :'(

Some important notes about this:

This is in no way a negative reflection on Acquia. I have worked with SO many amazing people there in the past 10 years(!), and have endless gratitude for all of the challenges, opportunities, learning, and laughs. The leadership team has a solid strategy, and the effort everyone there puts into achieving it every day is inspiring.This is in no way a negative reflection on Drupal. In my time here, I've seen Drupal through its youthful toddler years, to its surly teenage years, and now Drupal's all grown up, with a nice, stable apartment downtown. :) Drupal is and remains an amazingly powerful, flexible solution for building every single type of application one can dream of, with an incredibly strong and vibrant community behind it.What this is about is about an opportunity that came up to take lessons learned from Drupal and apply them more broadly to (hopefully) make an even bigger (more on that below).10 years sure is a long time�

It sure is! Here are some fun Drupal facts that help illustrate key achievements of Acquia's Drupal Acceleration Team [DAT] (née [OCTO]) over the years, and hopefully provide some insight into the areas of investment Acquia has made and continues to make in Drupal.

IMPORTANT NOTE: The folks explicitly called out below are former co-workers who work / have worked at Acquia, since this post is in some ways a "farewell" to them, and an opportunity to celebrate their often unsung efforts. This is unfortunately NOT able to be a comprehensive list of ALL of the amazing people working on various initiatives, because that list would be far, far too long and I'd invariably miss someone. :( Suffice it to say, however, that none of the items listed below would be possible without hard work, input, funding, and help from literally thousands of other people across the wider Drupal community!

Did you know? Back in 2011:

Authoring Experience and Strategic Initiatives

Eat your heart out, WordPress! :D
Drupal's default content creation experience was hand-typing HTML tags into a text box. Yes, I'm serious. :P Since then, Acquia contributed incredible new authoring functionality to Drupal 8 via the (WYSIWYG in core, In-Place Editing, Responsive Layouts, Mobile-Friendly Toolbar) and to Drupal 9 via contributions to the , , and initiatives, as well as work on to allow taking Drupal's content authoring experience to the next level. , , , , , , , , , , , alongside countless others from the wider Drupal community, drove these key improvements.Although these are the primary initiatives we've dedicated engineering resources to, DAT *also* plays a key coordinating/mentorship/advocacy role across ALL of the , from Initiative Coordinator Coordinator to awesome folks like , and @Leah Magee providing their communication, project management, and organizational prowess behind the scenes to bolster the efforts of others in the community.Strategic Initiatives themselves are also something pioneered by the OCTO/DAT team; prior to that, core development was very much "scratch your own itch," which tended to heavily favour developer improvements. With the advent of strategic initiatives we use data-driven analysis and look at overall market factors to determine a small subset of efforts that are of strategic importance to the project, while still enabling grassroots-lead to thrive. HUGE props to who takes on the bulk of the work in communicating these big shifts in a respectful and sensitive way via the Driesnote every time.Eas[y|ier] Upgrades

Tale as old as tiiiiiiime...
Drupal 7 had just come out, and the first initiative of the day was to help the community . (Sound familiar? ;)) (R.I.P.) was key to this effort, with a world-class team focusing on the biggest, gnarliest modules first. We then repeated that initiative for , for , and, because @Gábor Hojtsy is such an *amazing* overachiever, have already started it for as well! and deserve shout-outs for doing a huge ton of Drupal 7 > 8 and Drupal 8 > 9 (respectively) porting in their initial Acquia assignments!To assist with these efforts, OCTO/DAT has also developed numerous pieces of tooling over the years to help make upgrades easier, including: (originally an Acquia Hackathon project!), an automated code analysis/porting tool for Drupal 7 -> D8/9 code which @phenaproxima rocked the crap out of as an intern back in the day!, a dashboard of your contributed modules' porting status that gives you a dynamic "todo" list for major upgrades, which the team has shepherded over the years from 's original efforts back in the day!Predictability/Reliability

Three words to strike fear into any Drupal site admin.
In 2011, Drupal releases took the philosophy of "it's ready when it's ready," which made them basically impossible to plan around. Even security releases came out on an unpredictable, as-needed basis, so running a Drupal site required CONSTANT VIGILANCE. :P OCTO/DAT worked with the to develop the system we all know today, and also with core contributors to develop the that Drupal 8+ uses. Major kudos go to for making sure those trains run on time, and that they start any fires when they reach the station! :DAnother Drupal release philosophy from 2011 was "we'll break your code, not your data". OCTO/DAT has done extensive work, alongside other major community contributors, to enact various policies that ensure from Drupal 8 onward.And, for the poor souls still stuck on Drupal 7, DAT developed , which provides a variety of features to make the D7 > D9 migration go more smoothly (building off the Drupal Core Migrate API pioneered by and ), in the process contributing hundreds of upstream migration improvements to the community! Cheers to the fabulous @Emily Lanois for taking this project on going forward from a Product Management perspective, to for the vision, and to , , and for building it in the first place, along with numerous other members of Acquia's Drupal Cloud and associated teams!Governance

I don't have a pithy caption here; this is actually sound advice.
Back in 2011, Drupal was very much a "do-ocracy" which meant that it pretended it didn't have a governance structure, which mostly meant that if you weren't already neck-deep in the community to know who everyone was, you were completely in the dark as to which people held key decision making powers. :P We held a alongside OSCON with mindful community members, as well as various luminaries from other open source projects, and developed an explicit, scalable for the Drupal Association, for Drupal Core, and for the Drupal Community. Much of that framework exists to this day, and others have evolved as project needs have changed. deserves some props here as he's always incredibly thoughtful of structural changes within Drupal and their longer term ramifications.Sustainability

The delicate balance...
Back in 2011, if you needed a Drupal 7 committer, it was down to either or me. Over the years, we've built this up to a team of , including different specializations in Product Management, Framework Management, Frontend Framework Management, and Release Management. We've also brought onboard a Core Team Facilitator () to help with coordinating efforts of the team itself.Another major initiative that falls under this is the , to encourage organizations to donate time back to the project and create more .In partnership with the Drupal Association, we created the grants program to bash through the final critical bugs holding Drupal 8.0 from release. The core committer team was in charge of disbursing $125,000 in the form of bug bounties, and directly resulted in Drupal 8.0 shipping in 2015 (without it, who knows :\).

I'm sure I'm forgetting a million and a half other things that happened over the years, but hopefully this helps paint a picture for those who are newer to the company of how far Drupal has come, and the role Acquia has helped play in that growth.

What's next?

Webchick is going Web Scale! ;)

Starting today, I'm going back to my community building roots at as Principal Community Manager on the Community Team, focusing on initiatives such as building out an open source contributor program and further awesome-ifying the MongoDB Champions program.

What drew me to this opportunity is:

MongoDB has focused from the outset on , which is a value I believe in strongly, even since before my time in Drupal. I really appreciate that they take a strong, developer-centered view of how databases ought to work, and that they've tackled so many of the hard problems up-front.Because MongoDB is a technology that is used by tons of other projects, languages, frameworks, etc. it seems like a really great opportunity to both take some of the lessons learned from Drupal over the years and apply them to other communities, while also being able to get a broader perspective from other communities and bring those back into Drupal!The people. While it's really (really!) scary to think about starting out in a new place with new faces, I had the opportunity to interview with folks from a wide cross-section of the company. Every single person I spoke with fully embodied their . Every single person was passionate, genuine, kind, and determined to make a huge difference. In a lot of cases speaking to folks felt like speaking to a friend you've had for years.MongoDB has also been a tremendous ally to Drupal (speaking of 10+ years :)), putting funding and time into efforts such as Drupal 7's database abstraction layer, the , and more.From being prompted for pronouns on the initial application form, to a variety of , to , MongoDB takes their commitment to Diversity and Inclusion more seriously than just about any other tech company I've seen. Colour me impressed!AND, to top it off, they're going to continue to give me dedicated time to work on Drupal as well! :O

Our new chihuahua puppy Arthur wearing the MongoDB Pride bandana, more or less like a cape. :D

So, fret not! I'll still be around in the Drupal community, hopefully with a broadened perspective and bringing in some new ideas and energy along the way! :)

Sheesh, what's the TL;DR here?!

So, in short:

I no longer work at , but want to sincerely thank everyone there for 10+ years of important work, learning opportunities, amazing friends, and of course laughs.A LOT has changed in over the last 10+ years, and up above you can view a tiny sampling of it.I'm starting a new position at today as Principal Community Manager, and am really excited! (And also nervous, but hey. ;))I'll still see you Drupal folk around in and the . :)MOST importantly, we now have a puppy. ;)

One last thing: If we've worked together over the years in a Drupal community capacity and if you're up for it, I would be hugely appreciative of a . And I'll do my best to reciprocate! :)

°Õ²¹²µ²õ:Ìý

Background

These days, my life is , which means I often need to run Drupal 7 and Drupal 9 sites side-by-side simultaneously to compare the results.

The problem?

The latest version of , Drush 10, only works on Drupal versions 8.4+. To use Drush on Drupal 7 sites, you need an older version, Drush 8. And both of them use the command drush. Tricksy...

There are various Drupal-knowledgeable local development environments, such as , , , and that handle this complexity for you, which is super handy. However, the rest of my team uses a local development environment on Mac OS X, so I needed to figure out how to do this by hand.

I made a if there was an existing tutorial on how to do this, and since I couldn't find one, here it is. :) Hopefully this helps others, as well! (Thanks to those who responded, pointing me in the right direction!)

1. Installing Drush 8 for your Drupal 7 sites

are the installation docs for Drush 8. While the recommended way to install all versions of Drush is to pull it in as a local dependency (we'll go through that route in a sec), almost 0% of Drupal 7 sites are installed with Composer (and mine certainly weren't :P), since Composer was not even a "thing" back then. This means you typically need to install it instead globally, so it's available to all D7 sites on your computer.

To do this:

1. Go to and download the latest Drush 8 release's "drush.phar" file (as of this writing, 8.4.1).

2. Test that it's working by attempting to run it with PHP:

$ php PATH_TO_DRUSH/drush.phar --version

Drush Version : 8.4.1

3. Since it's super annoying to type php PATH_TO_DRUSH/drush.phar all the time, make it executable and move it somewhere in your $PATH.

cd PATH_TO_DRUSH

chmod +x drush.phar

sudo mv drush.phar /usr/local/bin/drush

Now you can execute with just drush [whatever] from within a given Drupal 7 site's docroot. Perfect!

2. Installing Drush 10 for your Drupal 8/9 sites

Well. Perfect except for the not-so-minor detail that despite Drush 8 working surprisingly well for not being supported in Drupal 8.4+, it is nevertheless not supported in Drupal 8.4+. Also, there are newer, useful commands in Drush 10 that are not available in Drush 8, such as drush config:satus.

So! Let's fix this by adding Drush 10 to our Drupal 9 site. has the installation instructions.

The "best practice" way to do this is in Drupal 9, since the code base has already been "Composer-fied" out of the box (thanks, !) is to add Drush in as a dependency:

cd PATH_TO/drupal9

composer require drush/drush

Check to make sure it's working:

drush --version

Drush Commandline Tool 10.3.4

Move back to your Drupal 7 directory and you should see:

drush --version

Drush Version : 8.4.1

Wicked!

3. That's it. Don't do anything else. ;)

I figured I would need to finish things off, but it appears that Drush 8 has some basic launch-like capabilities in it, because it automatically switches from one to the other seamlessly. Nifty!

And in fact, if you do install Drush launcher, Drush 8 won't work anymore. (Womp, womp.) Which brings us to...

Troubleshooting

It says "command not found" when I type "drush"
That probably means that the place you moved Drush 8 to is not in your $PATH. Try echo $PATH and move it to somewhere in that list, or add your desired location to $PATH in ~/.bash_profile
It says "mv: rename drush.phar to /usr/local/bin/drush: No such file or directory," but /usr/local/bin exists!
Don't forget to chmod it first.
When I run "drush" from within Drupal 7, it says "The Drush launcher could not find a Drupal site to operate on."
Ah, you skipped the tutorial and installed . ;) Following those steps will blow away your Drush 8 installation, which also lives at /usr/local/bin/drush. You can either re-do the steps above to use Drush 8, and thus kill your Drush Launcher (Drush 8 seems to have basic Drush Launcher capabilities, which is nice), or you can and then add Drush 8 as a dependency, just as you did with Drush 10, with:



composer require drush/drush:~8





°Õ²¹²µ²õ:Ìý

Wow, it's been awhile since I blogged, apparently. :P This is not a proper blog, but rather a random smattering of notes I'd rather not lose. Maybe it's helpful to others as well!

---

Today, my daughter's teacher sent around some resources to facilitate home schooling over the next while. Here are the steps I went through to take my iPad (which I won at gay bingo in a unicorn onesie back in the day lol) to my kiddo's iPad.

I did not want to just wipe the thing and start over, because my daughter has several games on there, and she would be utterly devastated to lose all of her progress.

At the same time, I don't really want her having access to all my photos and iMessages, particularly the ones discussing things like Easter logistics. ;)

So here are the steps I took, and they will perhaps be helpful to you as well!

Register their own Apple ID

This one's pretty straight-forward, but it's necessary for later steps:

1. Get them an email address. There are lots of ways to do this, is popular.

2. Register it at Fudge the birth year. :P

Log out as you, log in as them

Go to Settings > click your name > click Sign out.

If applicable, you'll need to enter your password to turn off "Find my iPad" (you can turn it back on again under their account instead).

It warns you it's going to delete data off this iPad. That's fine, and what you want. The problem is, it doesn't go nearly far enough...

Delete your iMessages

If you go to iMessage, you'll still see all of your messages there. Horror of horrors. :P

Sign in as them instead.

You'd expect the messages to now be gone. You would be wrong.

According to , iMessages are stored per-device. This seems to be true based on my experience, though I have to admit I lost several years off my life trying this. :P

Anyway, at the conversation tab, click "Select" in the upper-right corner, then check all of them, and then click Delete. Scariest few minutes of your life. You might want to practice with very old conversations that you don't care too much about.

If you don't want them on iMessage at all, go to Settings > iMessage, and turn off the iMessage setting altogether.

Delete your Photos

Photos, on the other hand, do sync to all your devices by default. You need to turn off that behaviour.

Settings > Photos, turn off "iCloud Photos". This will disconnect the device from the iCloud backend.

Now, in the next scariest few minutes of your life, go to Photos, click Select, and drag all around deleting everything in sight.

Also go into "Albums", click "Edit" and delete your custom ones of those, too.

Now, are your photos deleted? No they are not! You now need to go to Albums > Recently Deleted, select them and THEN delete them, and they're gone for good.

Making web pages look like apps

I know my name is webchick and all, but the interface for the web is really bad. Typing in complicated addresses with weird punctuation. Not the easiest thing for a 1st grader.

So to work around this, note that you can navigate to any web page, click Share > Add to Home, and it will create an icon (based on the favicon) that looks just like an app. Hooray!

°Õ²¹²µ²õ:Ìý

Helloooooooo #DrupalCon!

If you're looking for something to work on at the tomorrow, come to the sprint! :D

We'll be spending the day to get them ready for Drupal 9.

For a great overview about , along with helpful tutorial videos, see .

Here's how you can participate! (Whether in-person or remotely!)

Pull up the getting started info at and get set up with the tool to check your code for deprecations.
Join the channel on .
Check the list of issues tagged (or use your own module!)
Fix 'em and upload a patch! There are tips and tricks on the most common ones at , and the list of have the full details for any given change.

If you're a module developer who would like to "opt in" to having your module reviewed / patched by a new contributor at the sprint, please create (or find an existing) issue with the tags!

Want to see the progress? Here's a !

°Õ²¹²µ²õ:Ìý

For in mid-May, I'll be giving a talk entitled "Tales of Drupal Past: Origin Stories of Drupal Contributors." My goal is to feature folks from the Drupal community and share their stories of coming into Drupal, with the goal to help inform and inspire others about our community, coming from a wide range of diverse perspectives/backgrounds.

How about... YOU? What were you doing before Drupal? How'd you get your start? What are you doing now? How has Drupal changed/impacted your life?

I would really appreciate any responses, whether in the comments here, on your own blogs, and/or on social media (with the , please). (Especially if you're based in Eastern Europe, I would love to hear from you!)

I can share mine, as a start... (Feel free to make yours shorter than this, however! :))

I first encountered Drupal because I'm one of those people who runs around "viewing-source" on websites I visit to see what's ticking under the hood. I first saw Drupal in the source of , where fans of the Firefox web browser crowd-sourced marketing/promotion materials/events, and ran across it sometime later (2005) in the list of mentoring organizations.

I was a huge fan of FLOSS/open source for many years prior to this (first installed Linux in 1995 when Debian fit on like 7 floppy disks, lol), but always believed I was not "smart" enough nor "skilled" enough to actually participate in an open source project. GSoC was important for breaking down this belief, because I surmised that if it was for students, they probably expected we didn't know everything yet.

So, I applied. And somewhat miraculously, got accepted (thanks, !) and assigned a mentor (thanks, !). Thankfully, there is not a single shred of any of my original code left in these days, but it's kind of rad that it's still kicking around out there almost 14 years later! :)

Once I got on "this" side of my imaginary "you must be THIS smart to contribute" wall, I began to realize that...

Making change in an open source project is truly a collaborative process, with many different people and many different skills (dev, testing, ux, a11y, design, dev, security, promotion) all putting forth what they know to arrive at the optimal solution.
There are no rockstar experts sitting about barfing out perfect code. ;) In fact, I've reviewed code from most of the "Drupal rockstars" you know, and they're all pretty crap the first time through. ;) (Very much including myself!)
If you can demonstrate through your words/actions that you are one of the "helpers," (versus someone complaining/trying to get other people to do work for you for free/etc.) you will get near INFINITE amount of patience and mentorship and other support from the community. (Because there are not many "helpers" out there relative to the amount of users and complainers.)

So, I began to throw myself into contributing wherever I could: core and contrib development, patch reviews, QA, Drupal.org webmaster stuff, security team, UX team, Drupal Association, core committer, etc. (Note: This was highly unsustainable, and I do not necessarily recommend this course of action, LOL. ;))

These days, I am hugely fortunate to be paid full-time to work on Drupal by , as part of their Drupal Acceleration Team. My main focus is in supporting, unblocking, and accelerating community efforts around Drupal's , as well as my role as a product manager on the core committer team (setting roadmaps, keeping an eye on what our competitors are up to, and brutally-but-kindly-as-possible WebchickTestCase-ing unsuspecting patches :P).

Over the course of my time with Drupal, I've gained an incredible amount... learning new things every day, numerous friendships-that-feel-like-extended-family (some of literally a decade or more), travel to all corners of the globe, hearing and taking in numerous diverse ideas and perspectives, and more. Thank you so much to everyone who makes this possible.

°Õ²¹²µ²õ:Ìý

Greetings, folks! As we head into (the week of July 18), here's a run-down of the various initiatives, and a hit-list of what they're trying to accomplish in the next two weeks. Patch reviews, testing, design, docs, and many more skills are very welcomed!

A couple of caveats here:

1) This is my own personal best understanding of where this stuff is all at, based on reading issue comments, attending meetings, overhearing things from other people who attended meetings, catching the odd Slack snippet of conversation, carrier piegon, etc. And therefore may not be 100% accurate, or even 80% accurate � there's a lot going on! (please clarify in the comments if you see any errors/omissions)

2) Just because something is listed here, there is absolutely no guarantee that it gets reviewed + (truly) RTBCed + committed in time for feature freeze and makes it into 8.6. As you can see, there are lots of issues in the list below, and we're all doing our best to stay on top of them. Worst-case, there's always 8.7. :)

3) This post gets into nitty-gritty "technical audience" details; if you're interested in a more broad overview of initiatives and their aims for 8.6 and beyond, there's the on Drupal.org. I was also recently on a to that effect.

OK, here we go! These are listed in alphabetical order.

This initiative has some lofty goals indeed, to , and to meet modern standards/best practices. While there's a ton of work actively going on in these areas right now, most of the fruit won't bear until 8.7 or later. If you're planning/able to go, come join the sprint next week at !

For 8.6, one of the big accomplishments of this initiative was introducing testing framework to core, which allows us to test JavaScript code with (wait for it)... JavaScript (what a concept!). This will be critical in ensuring that the -ified components work as expected, and our existing JavaScript-rich functionality continues to work solidly as we expand on dynamic functionality in the UI.

Here are the issues this team has surfaced as important for 8.6:

Make Nightwatch testing more generally useful

Add login/logout commands to nightwatch []
Create nightwatch command to install modules []

Fix long-standing issues in the JavaScript system

Seriously, check out the five-digit node IDs on these bad boys! :P

ajax.js insert command sometimes wraps content in a div, potentially producing invalid HTML and other bugs []
Provide a common API for displaying JavaScript messages []

Bring JS code up to modern standards

Use Prettier for formatting core JavaScript []

This team's 8.6 goals are two-fold: 1) , and 2) attempting to .

TONS of work has been going on in the to fix a number of outstanding issues to make it core-worthy. So even if this module doesn't make it in time for 8.6, the entire ecosystem will benefit throughout 8.6's lifecycle by using a much more robust and well-tested contributed module. Additionally, a long-standing gap of has been added. Huzzah!

For the remainder of 8.6, the team would like to focus on the following:

Unblockers to API-First in general

Add DateTimeNormalizer+TimestampNormalizer, deprecate TimestampItemNormalizer: @DataType-level normalizers are reusable by JSON API []
@DataType=map cannot be normalized, affects @FieldType=link, @FieldType=map []

Unblockers to REST

EntityResource should add _entity_access requirement to REST routes []
PATCHing entities validates the entire entity, also unmodified fields, so unmodified fields can throw validation errors []

Unblockers to JSON API

These are all issues in the , which help unblock "Add experimental JSON API module []" for core.

[PP-1] Work around core's ill-designed @FieldType-level TimestampItemNormalizer normalization until #2926508 lands []
JSON API indicates it supports POST/PATCH/DELETE of config entity types, but that's impossible []
Needs Issue: Module name conflict between contrib/core (what happens when we bring a same-named contrib module to core that sites are actively using?)
[>=8.5] Remove JSON API's "file URL" field work-around now that Drupal core 8.5 fixed it [] - Fixed!

/

These two initiatives overlap in that we're aiming to build the automatic update functionality around improving core's underlying Composer support.

The Composer team has compiled an excellent for how to provide Composer support without jeopardizing the site builder experience. Most of that work will take place in 8.7.

However, one of the pre-requisites for Composer to work well, is . Support for this would also be tremendously helpful to contrib module authors and site builders, regardless if they use Composer to manage their dependencies or not.

Unblockers to semver for contrib

Core version key in module's .info.yml doesn't respect core semantic versioning []
Module version dependency in .info.yml is ineffective for patch releases []

This team spent most of the 8.6 cycle forming, brainstorming , and prioritizing those efforts. The hope is for a roadmap to get published after the sprint next week at .

One major win in 8.6 is the ability to , which is part of the aim to (basically, moving the capabilities of the into core.)

Unblockers of install from existing configuration

Install a site from config if the config directory is set in settings.php []

The Documentation initiative has a lot on the go right now, from , to , and finally . None of these have a particular deadline around 8.6, because they're happening independently of core.

On the core side, there's work being done on a new experimental module for and this work has an 8.6 deadline.

New topic-based core help system

Refactor using a plugin system []
Add experimental module for Help Topics []

For the to happen, we need to make several adjustments to core's Update Status module, which currently makes several hard-coded assumptions about the last minor release of Drupal expiring immediately once a new minor release is available.

Update Status Improvements

If the next minor version of core has a security release, status still says "Security update required!" even if the site is on an equivalent, secure release already []
Status report should indicate next minor release date (needs issue)
(other issues TBD)

The Layout team has been hard at work improving upon the experimental Layout Builder functionality that was added to 8.5. The main goal of the team for 8.6 is to gather real-world testing feedback from end users, which they are accomplishing by adding Layout Builder to a new branch of the . Doing this has uncovered a few holes in the implementation relative to what's possible in contrib right now, and filling those gaps is the focus of the remaining 8.6 time for the team.

Layout Builder gaps

Allow the inline creation of non-reusable Custom Blocks in the layout builder []
Add a validation constraint to check if an entity has a field []
Determine if Layout Builder should replace entity_view_display for all Entity Types []
No ability to control "extra fields" with Layout Builder []
Allow Custom blocks to be set as non-reusable adding access restriction based on where it was used. []

Integration with other subsysytems/modules

[PP-1] LayoutBuilderEntityViewDisplay::getRuntimeSections() does not delegate to plugins []
Add EntityContextDefinition for the 80% use case []
[meta] Decide how Layout Builder should function with Content Moderation and Workspaces modules []
Layout Builder does not respect translations []
Track Layout override revisions on entities which support revisioning []

Media has made tremendous strides in 8.6, including and a .

Next, we need to integrate that media library into the node form, and ideally allow people to add from there as well in a more streamlined fashion.

Blockers to media awesomeness

Create a field widget for the Media library module []
(needs issue) Mark Media Library as beta
[PP-1] Allow media to be uploaded with the Media Library field widget []
Any AJAX call disregards machine name verification when AJAX is used and leads to a fatal error []
Provide a media library display for "Remote video" []

The goal of this initiative for 8.6 is to which means marking the experimental Migrate Drupal + Migrate UI modules stable. This was also the goal for 8.5. What's making it tricky is multilingual migrations, which are themselves tricky because there are a multitude of ways one might have set up multilingual functionality prior to it being included in core in Drupal 8, which introduces lots of edge cases around making IDs line up and whatnot.

The team is taking a two-pronged approach here:

1) Attempt to close all of the remaining .

2) Worst-case, , so that the rest of the system that works for 80%+ of sites can be marked stable.

Make Migrate Stable

[policy, no patch] Mark Migrate Drupal as stable []
[policy, no patch] Mark Migrate Drupal UI as stable []
[META] Multilingual migrations meta issue []
Experimental migrate_drupal_multilingual module []

The Umami profile was committed (albeit marked hidden) in 8.5, and major efforts have been going on to remove all of the "beta blockers" preventing it from being visible in the UI. The last of these—Install profile in settings.php and mismatch check makes re-installs of Drupal hard []—just landed earlier this week!

From here to 8.6, the team is working on stability and accessibility improvements.

Umami awesomesauceness

Un-hide Umami in 8.5 to vastly improve Drupal's evaluator experience []
Improve Umami demo's support for managing field display settings []
Improve Umami Demo's header layout and responsive behaviour []
Umami missing some Media "plumbing" found in Standard profile []

Last, but certainly not least, is the Workflow initiative, which aims to add the contributed module to core in 8.6 to facilitate content staging and full-site previews. The , but must be brought up to "beta" level stability to remain in the tagged + shipped release.

Because Workspaces can only stage content that's revisionable, there's also a parallel effort to add revision-ability to more types of data in Drupal core.

Blockers to Workspaces Stability

WI: Workspace module roadmap []
Add workspace UI in top dialog []
Remove the automatic entity update system []

MOAR revisionable thingies

Convert taxonomy terms to be revisionable []
Convert custom menu links to be revisionable []
Convert comments to be revisionable []

Anything else?

Whew! That's QUITE a lot. Are there any issues out there that we're missing that you feel are mission-critical to get into Drupal 8.6? Feel free to suggest them, with the caveat that the longer the list is, the more distributed the community's and core committers' focus is.

Thanks for reading!

°Õ²¹²µ²õ:Ìý

In recent weeks, I've seen a whole lot of FUD regarding the , and what it is they do or don't do. While I no longer serve in the CWG (I stepped down from all "extra-curricular" Drupal activities back in 2015 to focus on my family), most of the portrayals I've read are misinformed at best and completely inaccurate at worst. So, as an ex-member, who was uninvolved in recent events and therefore can perhaps speak more freely(?), I’d like to try and clear up a few misconceptions I've seen.

Some have characterized the CWG as some nebulous dark secret court of frothing SJW activists, gleefully acting as judge/jury/executioner, deliberately seeking out “bad apples" in the community to oust, laughing malevolently all the way. This is patently false, and nothing could be further from the truth.

In reality, barring "flash point" incidents like the most recent one, it’s a pretty mundane gig. It mostly involves watching for something to be brought across your "desk" via an , then trying your best as an unpaid volunteer—appointed based on your demonstrated ability to stay neutral and diplomatic in a crisis—to help empower people in the community to solve their own problems.

This takes different forms. A lot of the times it’s simply giving people a safe place to post concerns where they know they’ll be looked at seriously. The CWG provides someone to speak to who will genuinely listen to your concerns, and will give both parties a chance to speak and feel heard. If the situation escalates, the CWG will sometimes suggest neutral third-parties to help mediate, or in the “bigger� cases, get directly involved with mediation themselves. And while the CWG is empowered to oust people from the community in extreme circumstances, a) to-date, they have only done so once, following a at DrupalCon, and b) barring "extreme" circumstances such as that, it is only done after a last, *last* resort. All of this is laid out in the Conflict Resolution Policy and Process:

If an individual has multiple, *multiple* complaints against them, in many cases driving others to either leave the community entirely or dramatically reduce their involvement in the project, and if every other attempt to resolve the situation has failed, which includes private mediation, one-on-one mentoring, sterner warnings, etc. then as a last-ditch effort something like an is developed. This is summarized as:

"The aim of an action plan is to find a path forward that avoids additional harm to the community. Drafting an action plan should help people recognise what triggers these incidents and help them learn to respond differently by using alternative approaches to problem-solving.

However, the action plan may also serve as a "final warning." If further complaints come to the CWG, further action may be necessary. As a group, our authority derives from Dries, and when necessary, we also consult Dries and involve him in the process."

The template includes a summary of complaints (all of which have been already vetted by the CWG for validity), the impact the person's actions have had on members of the community, and a clearly outlined set of steps to perform to prevent future complaints (e.g. if you're feeling frustrated, WALK AWAY instead of engaging in online battles in the heat of the moment). The intent is to wake the person up a bit, to help them understand that their actions — regardless of how justified they feel they are in having taken them — have consequences, often on people they care about, and to give them a clear path to re-engage with the community in a constructive and healthy way.

The CWG will bend over backwards to help people not get to that point, *especially* if they have an extensive contribution record. At a certain point though, if a “body trail� develops of people leaving the community because of an individual's conduct, it becomes something that needs to be addressed, especially if you sit on a governing body with the mandate to keep the community healthy. This is the situation that happened with chx, whose self-ban from the community was widely publicized, and which keeps getting brought up in the context of recent events as somehow related, which it is not.

Some people might respond to this with "Well, then contributors should just grow a thicker skin." That's certainly one approach. However, you lose a lot of great contributors that way (and indeed, we already have), as well as a lot of new blood into your project. I've previously documented . Had I not been "contractually obligated" to remain because of Google Summer of Code, that likely would've been my last 5 minutes in the Drupal community, as well. And there are 1000s of other contributors out there like "past webchick." Food for thought.

So thanks, CWG, for doing your part of the thankless and difficult job that is ensuring that the Drupal community remains a respectful and collaborative place for all of us to do awesome things.

°Õ²¹²µ²õ:Ìý

I have a friend looking for subsidized housing in and around Vancouver. keeps listings at but the data is all shackled up in PDF files as simple lists. There's no easy way to visualize where these properties are located within the city, and no easy way to search/filter for places that, for example, allow pets.

So, in a fit of insomnia, I decided to try a late night nerd project: creating a handy map of this data from a spreadsheet. in all of its glory. ;)

Step 1: Getting your data into Google Sheets

If you're exceedingly fortunate, your data will be in some sort of nice, machine-readable CSV format and you simply import it and off you go. Or, you could be exceedingly unfortunate like me, and have all your data encoded in a . Whee! :P

So I'll freely admit, I ended up totally cheating here and spent 2 hours on a massive copy/paste job. :P But before I resorted to that, I did explore some other options like (a Composer-friendly PHP library which has API functions for converting PDFs to text, and hey they use Drupal! :)) as well as , which lets you draw boundary boxes around tabular data in a PDF and it will attempt to automatically convert them to CSV for you (it got really close, and presumably in a correctly formatted PDF would've worked great).

Anyway, so step 1 is you need a Google Sheet with address data in it. Here's a copy of mine: More or less, I just created dedicated columns for all the things in the PDF, with two exceptions:

In the PDF, "Development name and location" are one field; I've split them apart so that the development name part (e.g. Orchard Heights) and the address part (e.g. 5538 Chaffey Ave) are separate.
I've also added columns for city and province, to help Google Maps figure out where these addresses are located more easily.

You could also cram all of this into one field, but it can be nice to have them split out, and the Google Maps tools allow for that.

Anyway, assuming you're done with this step, you have a Google Sheet with one or more columns containing location data. Good for you!

Step 2: Importing data into a custom map

Log into Google, then go to and navigate to Your Places > Maps > and click "Create Map". Or, just click this:

In the box in the upper left, where it says "Untitled layer", click "Import".

Go to the "Google Drive" tab and select the Sheet you made earlier.

Now, it will ask you two questions. The first is to choose columns from where to get your location data. In my case, this is Location, City, and Province.

Next, it will ask which column to use as the name of the markers when they're clicked. In my case, I chose "Development Name."

And... boom! Just look at your perdy map! :D

Step #3: Getting all fan-say

So we have our visualization, and that's super. But it's still incredibly tedious to go through each marker and figure out which ones allow pets and which don't.

So instead, let's make the markers different colours (green/red), based on whether or not the place is a possible candidate.

To do this, I added a "Candidate?" column to the spreadsheet, with a simple algorithm:

=IF(O2 >= 1, "Y", "N")

In other words, if the "Number of Pets" column is at least 1, give this column a value of "Y". Otherwise, give it a value of "N".

You can also "nest" IF statements, like so, to mark only places that allow pets and also allow wheelchair access as candidates:

=IF(O2 >= 1, IF(L2 ="Y", IF(U2 = "Y", "Y", "N"), "N")

Repeat the nesting for each condition.

Once you have this column, you can do something kind of cool. (Btw, you'll need to delete and re-add the layer in Google Maps each time you update the source data... sad panda.)

In the upper left, click where it says "Uniform style" and change "Group places by" to your "Candidate?" column:

The two options will automatically be colour-coded according to whether they're "Y" or "N" (colour assignments are seemingly random, so you may need to tweak the colours so they're more obvious).

Now click "Preview" to check out your new, more awesomer perdy map! :D

Yay! In (hopefully) only a few minutes of work, and using totally free (as in beer, sadly not as in freedom) tools, you can have your own data-driven Google Map. :) Yeehaw!

°Õ²¹²µ²õ:Ìý

My Twitter timeline has been blowing up with news about Greece's decision to turn down a referendum that would accept debt relief coupled with severe austerity measures. I could find article after article after article explaining why voting "no" on this referendum was a terrible idea. However, since 61% of a country can rarely agree on their favourite kind of ice cream, let alone something with this level of economic magnitude, I was curious to learn what the "other side" of the story was.

So I posted the following to Twitter:

"Lots of sources saying horrible things about #GreeceReferendum outcome. Having trouble finding some that rationalize the "Oxi" vote. Links?"

Having read all of them (this took awhile :)), here's my best stab at a summary:

Many cite the Euro as the major cause. The claim is that the Euro as a currency doesn’t really work across a set of countries with as diverse economic situations as Europe. There are some standard ways to respond to economic collapse—for example, devaluing the currency to make exports/tourism cheaper—but Euro zone countries like Greece cannot do this because that would also devalue the currency in wealthier nations, such as Germany. /HT This piece /HT argues the same. /HT goes so far as to suggest that a "Grexit" (Greece leaving the Euro zone) is actually the best of all the bad options now.
And while North America has always had the concept of "have"/"have not" states/provinces, with the better off subsidizing the less so, Canada and the United States are each their own countries ("Americans first, Oregonians second"). The Euro zone, in contrast, is comprised of individual countries, with a strong sense of nationalism ("Germans first, Europeans second"). See /HT for an argument that it doesn't need to be this way.
The Greek government already took a bailout in 2010 which came with some stiff austerity conditions in terms of cutting salaries, jobs, and pensions. And unfortunately, this did not have the desired effect; GDP plummeted, unemployment skyrocketed. So more of the same medicine that is viewed by many to have caused the economic crisis in the first place did not seem sensible. /HT gets way into this, including this absolutely horrifying graph:

Also for those who like a shorter read, this is also played out in dramatic fashion in this /HT
This new deal imposed even harsher restrictions which . /HT
Additionally, most of the money loaned to "Greece" never actually went there. It went instead to bolster the banks (including German and French banks) that gave Greece the bad loans. See /HT
There was also speculation among many that the proposal put forward "troika" (European Commission, European Central Bank (ECB), and International Monetary Fund (IMF)) was actually a thinly-veiled attempt to overthrow the democratically elected, far-left "Syriza" party that has been in power in Greece since January. A "yes" vote (in support of the troika's deal) would've spelled doom for the government's stated anti-austerity platform, and shown alignment with the big banks. /HT spells out this dilemma. /HT echoes this speculation.
Several articles also express suspicion that those protesting on the "yes" side seemed a little too uniform, and a little too cashmere-covered (smacking of political/economic elite, oligarchs, and their brethren), versus the "no" side being more reminiscent of a true grassroots movement. The "yes" side strongly pushed a fear/apocalypse agenda, which was viewed cynically as serving the interests of the big banks and rest of Europe, versus Greeks themselves (in particular, impoverishing the elderly even further was seen by many as impossible to bear). /HT and /HT go into this discrepancy.
Others bring up the history of WWI and WWII and point out the hypocrisy in that Germany, France, UK, and other nations were in the same boat as Greece and had their debt restructured, rather than facing the severe austerity measures Greece is faced with today. There are similarities drawn between the economic conditions of the early 1900s with that of the post-2008 financial crisis that argue for a similar EU-wide look at debt relief. See /HT

TL;DR Greece has "been there, done that" with very large sums of money with very large strings attached, and they've only seen things get worse for their country (and that large sum of money largely flowing out of Greece and into other European economies). The Euro doesn't provide enough flexibility for countries in Greece's predicament to do textbook recovery measures, making already bad economic situations worse. The deal proposed by the creditors was seen by some as a way to force power out of Greeks' hands and into banks' and other European countries' hands, which particularly didn't play well in the birthplace of democracy. There's also a hope that a "no" vote will provide Greece's elected government with a stronger negotiating position with the banks (though this definitely remains to be seen; the troika has much more incentive to make an example of Greece than work with them at this point, or they could see this pattern spread throughout the EU).

The More You Know� Thanks so much to everyone who responded! Hope this summary is helpful, and also that I didn't screw it up too badly. :)

°Õ²¹²µ²õ:Ìý