Inhalt abgleichen
Drupal.org - aggregated feeds in category Planet Drupal
Aktualisiert: vor 5 Minuten 16 Sekunden

Jeff Potts: Quick look at Acquia Reservoir, a Headless Drupal Distribution

2. März 2018 - 23:00

Drupal is a very popular open source Web Content Management system. One of its key characteristics is that it owns both the back-end repository where content is stored and the front-end where content is rendered. In CMS parlance this is typically called a “coupled” CMS because the front-end and the back-end are coupled together.

Historically, the coupled nature of Drupal was a benefit most of the time because it facilitated a fast time-to-market. In many cases, customers could just install Drupal, define their content types, install or develop a theme, and they had a web site up-and-running that made it easy for non-technical content editors to manage the content of that web site.

But as architectural styles have shifted to “API-first” and Single Page Applications (SPAs) written in client-side frameworks like Angular and React and with many clients finding themselves distributing content to multiple channels beyond web, having a CMS that wants to own the front-end becomes more of a burden than a benefit, hence the rise of the “headless” or “de-coupled” CMS. Multiple SaaS vendors have sprung up over the last few years, creating a Content-as-a-Service market which I’ve blogged about before.

Drupal has been able to expose its content and other operations via a RESTful API for quite a while. But in those early days it was not quite as simple as it could be. If you have a team, for example, that just wants to model some content types, give their editors a nice interface for managing instances of those types, and then write a front-end that fetches that content via JSON, you still had to know a fair amount about Drupal to get everything working.

Last summer, Acquia, a company that provides enterprise support for Drupal headed up by Drupal founder, Dries Buytaert, released a new distribution of Drupal called Reservoir that implements the “headless CMS” use case. Reservoir is Drupal, but most of the pieces that concern the front-end have been removed. Reservoir also ships with a JSON API module that exposes your content in a standard way.

I was curious to see how well this worked so I grabbed the Reservoir Docker image and fired it up.

The first thing I did was create a few content types. Article is a demo type provided out-of-the-box. I added Job Posting and Team Member, two types you’d find on just about any corporate web site.

My Team Member type is simple. It has a Body field, which is HTML text, and a Headshot field, which is an image. My Job Posting type has a plain text Body field, a Date field for when the job was posted, and a Status field which has a constrained list of values (Open and Closed).

With my types in place I started creating content…

Something that jumped out at me here was that there is no way to search, filter, or sort content. That’s not going to work very well as the number of content items grows. I can hear my Drupal friends saying, “There’s a module for that!”, but that seems like something that should be out-of-the-box.

Next, I jumped over to the API tab and saw that there are RESTful endpoints for each of my content types that allow me to fetch a list of nodes of a given type, specific nodes, and the relationships a node has to other nodes in the repository. POST, PATCH, and DELETE methods are also supported, so this is not just a read-only API.

Reservoir uses OAuth to secure the API, so to actually test it out, I grabbed the “Demo app” client UUID, then went into Postman and did a POST against the /oauth/token endpoint. That returned an access token and a refresh token. I grabbed the access token and stuck it in the authorization header for future requests.

Here’s an example response for a specific “team member” object.

My first observation is that the JSON is pretty verbose for such a simple object. If I were to use this today I’d probably write a Spring Boot app that simplifies the API responses further. As a front-end developer, I’d really prefer for the JSON that comes back to be much more succinct. The front-end may not need to know about the node’s revision history, for example.

Another reason I might want my front-end to call a simplified API layer rather than call Drupal directly is to aggregate multiple calls. For example, in the response above, you’ll notice that the team member’s headshot is returned as part of a relationship. You can’t get the URL to the headshot from the Team Member JSON.

If you follow the field_headshot “related” link, you’ll get the JSON object representing the headshot:

?

The related headshot JSON shown above has the actual URL to the headshot image. It’s not the end of the world to have to make two HTTP calls for every team member, but as a front-end developer, I’d prefer to get a team member object that has exactly what I need in a single response.

One of the things that might help improve this is support for GraphQL. Reservoir says it plans to support GraphQL, but in the version that ships on the Docker image, if you try to enable it, you get a message that it is still under development. There is a GraphQL Drupal module so I’m sure this is coming to Reservoir soon.

Many of my clients are predominantly Java shops–they are often reluctant to adopt technology that would require new additions to their toolchain, like PHP. And they don’t always have an interest in hiring or developing Drupal talent. Containers running highly-specialized Drupal distributions, like Reservoir, could eventually make both of these concerns less of an issue.

In addition to Acquia Reservoir, there is another de-coupled Drupal Distribution called Contenta, so if you like the idea of running headless Drupal, you might take a look at both and see which is a better fit.

Mediacurrent: Friday 5: 5 Ways to Secure Your Drupal Site

2. März 2018 - 18:23

Happy Friday Everyone! On the eve of the Drupal Drive-in, happening tomorrow in Charolette North Carolina, we welcome Mark Shropshire to the show to talk about his favorite topic, Drupal Security!
 

orkjerns blogg: Updating to Drupal 8.5 with composer

2. März 2018 - 14:03
Updating to Drupal 8.5 with composer admin Fri, 03/02/2018 - 12:03

If you are like me, you might have already started planning the upgrade to Drupal 8.5, now that the first release candidate is out. It's awesome by the way, among other things, thanks to the incredible work done with layout builder. And if you are more like me, you are managing your sites with composer. Then, depending on the rest of your project, you might (also like me), have encountered some initial problems upgrading to Drupal 8.5

Having hit my fair share of composer oddities with running the Violinist.io composer monitor and upgrade service, I wanted to compile a couple of error messages along with solutions, to the folks struggling with this out there.

Installation request for webflo/drupal-core-require-dev (locked at 8.4.5, required as ~8.4) -> satisfiable by webflo/drupal-core-require-dev[8.4.5].

If you have installed an out of the box version of https://github.com/drupal-composer/drupal-project, this might be an error message you encounter. Full error message, for reference:

./composer.json has been updated > DrupalProject\composer\ScriptHandler::checkComposerVersion Loading composer repositories with package information Updating dependencies (including require-dev) Your requirements could not be resolved to an installable set of packages. Problem 1 - webflo/drupal-core-require-dev 8.4.5 requires drupal/core 8.4.5 -> satisfiable by drupal/core[8.4.5] but these conflict with your requirements or minimum-stability. - webflo/drupal-core-require-dev 8.4.5 requires drupal/core 8.4.5 -> satisfiable by drupal/core[8.4.5] but these conflict with your requirements or minimum-stability. - webflo/drupal-core-require-dev 8.4.5 requires drupal/core 8.4.5 -> satisfiable by drupal/core[8.4.5] but these conflict with your requirements or minimum-stability. - Installation request for webflo/drupal-core-require-dev (locked at 8.4.5, required as ~8.4) -> satisfiable by webflo/drupal-core-require-dev[8.4.5]. Installation failed, reverting ./composer.json to its original content.

The reason this fails is that the project you have created is depending on the dev packages for drupal core, which are tied to a specific version of core. So to update core, we also need to update the dev packages for core.

The solution to this is pretty simple:
Open your composer.json file and replace the lines for drupal/core and webflo/drupal-core-require-dev with the following:

"drupal/core": "~8.5" // ...and "webflo/drupal-core-require-dev": "~8.5"

Afterwards you can go ahead and run:

composer update drupal/core webflo/drupal-core-require-dev --with-dependencies Installation request for symfony/config (locked at v3.2.14) -> satisfiable by symfony/config[v3.2.14].

This probably comes from the fact that you also have some other packages depending on this specific Symfony package in your project. Like drush or drupal console. Here is a full error message, for reference:

Loading composer repositories with package information Updating dependencies (including require-dev) Your requirements could not be resolved to an installable set of packages. Problem 1 - Conclusion: don't install drupal/core 8.5.0-rc1 - Conclusion: don't install drupal/core 8.5.0-beta1 - Conclusion: don't install drupal/core 8.5.0-alpha1 - Conclusion: don't install drupal/core 8.6.x-dev - Conclusion: remove symfony/config v3.2.14 - Installation request for drupal/core ~8.5 -> satisfiable by drupal/core[8.5.0-alpha1, 8.5.0-beta1, 8.5.0-rc1, 8.5.x-dev, 8.6.x-dev]. - Conclusion: don't install symfony/config v3.2.14 - drupal/core 8.5.x-dev requires symfony/dependency-injection ~3.4.0 -> satisfiable by symfony/dependency-injection[3.4.x-dev, v3.4.0, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2, v3.4.1, v3.4.2, v3.4.3, v3.4.4]. - symfony/dependency-injection 3.4.x-dev conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.0 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.0-BETA1 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.0-BETA2 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.0-BETA3 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.0-BETA4 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.0-RC1 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.0-RC2 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.1 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.2 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.3 conflicts with symfony/config[v3.2.14]. - symfony/dependency-injection v3.4.4 conflicts with symfony/config[v3.2.14]. - Installation request for symfony/config (locked at v3.2.14) -> satisfiable by symfony/config[v3.2.14].

The solution here is to indicate you also want to update this package, even if it's not specifically required. So if the failing command was the following:

composer update drupal/core --with-dependencies

Go ahead and change it to this:

composer update drupal/core symfony/config --with-dependencies

If you have other error messages, I would be glad to help out with a solution, and post the result here.

Credits

Thanks to zaporylie for looking into this with me, and to Berdir for pointing out the fact that core is not the package that requires symfony/config.

Let's finish this post with an animated gif of a composer

Wim Leers: API-First Drupal: what's new in 8.5?

2. März 2018 - 13:11

Now that Drupal 8’s REST API 1 has reached the next level of maturity, I think a concise blog post summarizing the most important API-First Initiative improvements for every minor release is going to help a lot of developers. Drupal 8.5.0 will be released next week and the RC was tagged last week. So, let’s get right to it!

The REST API made a big step forward with the 5th minor release of Drupal 8 — I hope you’ll like these improvements :)

Thanks to everyone who contributed!

  1. text fields’ computed processed property exposed #2626924

    No more need to re-implement this in consumers nor work-arounds.

    "body":{ "value":"<p>Hi!</p><script>alert('foo')</script>", "format":"basic_html" }

    "body":{ "value":"<p>Hi!</p><script>alert('foo')</script>", "format":"basic_html", "processed":"<p>Hi!</p>" }
  2. uri field on File gained a computed url property #2825487

    "uri":{"value":"public://cat.png"} ⬇ "uri":{"url":"/files/cat.png","value":"public://cat.png"}

  3. Term POSTing requires non-admin permission #1848686

    administer taxonomy permission ⬇ create terms in %vocabulary% permission

    Analogously for PATCH and DELETE: you need edit terms in %vocabulary% and delete terms in %vocabulary%, respectively.

  4. Vocabulary GETting requires non-admin permission #2808217

    administer taxonomy permission ⬇ access taxonomy overview permission

  5. GET → decode → modify field → encode → PATCH → 403 200 #2824851

    You can now GET a response, modifying the bits you want to change, and then sending exactly that, without needing to remove fields you’re not allowed to modify. Any fields that you’re not allowed to modify can still be sent without resulting in a 403 response, as long as you send exactly the same values. Drupal’s REST API now implements the robustness principle.

  6. 4xx GET responses cacheable: more scalable + faster #2765959

    Valuable for use cases where you have many (for example a million) anonymous consumers hitting the same URL. Because the response is not cacheable, it can also not be cached by a reverse proxy in front of it. Meaning that we’ll have hundreds of thousands of requests hitting origin, which can bring down the origin server.

  7. Comprehensive integration tests + test coverage test coverage

    This massively reduces the risk of REST API regressions/changes/BC breaks making it into a Drupal 8 release. It allows us to improve things faster, because we can be confident that most regressions will be detected. That even includes the support for XML serialization, for the handful of you who are using that! We take backwards compatibility serious.
    Even better: we have test coverage test coverage: tests that ensure we have integration tests for every entity type that Drupal core’s stable modules ship with!
    Details at API-First Drupal — really!. Getting to this point took more than a year and required fixing bugs in many other parts of Drupal!

Want more nuance and detail? See the REST: top priorities for Drupal 8.5.x issue on drupal.org.

Are you curious what we’re working on for Drupal 8.6? Want to follow along? Click the follow button at REST: top priorities for Drupal 8.6.x — whenever things on the list are completed (or when the list gets longer), a comment gets posted. It’s the best way to follow along closely!2

The other thing that we’re working on for 8.6 besides the REST API is getting the JSON API module polished to core-worthiness. All of the above improvements help JSON API either directly or indirectly! More about that in a future blog post.

Was this helpful? Let me know in the comments!

Thanks to Ted for reviewing a draft of this blog post! And sorry for not changing the title to API First Drupal in 8.5.0: Amazing progress because of tedbow’s work on setInternal properties!!!!!!!!! even though that would’ve been totally accurate :D

For reference, historical data:

  1. This consists of the REST and Serialization modules. ↩︎

  2. ~50 comments per six months — so very little noise. ↩︎

  • API
  • Acquia
  • Drupal

OPTASY: From Drush Clear Cache to... Rebuilding Cache in Drupal 8: What's the Difference?

2. März 2018 - 12:45
From Drush Clear Cache to... Rebuilding Cache in Drupal 8: What's the Difference? radu.simileanu Fri, 03/02/2018 - 10:45 From "remorsefully clearing all Drupal cache using Drush, to actually... rebuilding them in Drupal 8? Why the change? How will the new “cache-rebuild” concept impact your Drupal development process? All your troubleshooting and site updating sessions?

Hook 42: Hook 42 in the Windy City!

1. März 2018 - 19:37

We are excited to have Adam Bergstein joining our team as Vice President of Engineering! Better yet? He’ll be speaking at the upcoming Midwest Drupal Camp in Chicago about his journey from engineer to technical leader.

MidCamp is March 8th - 11th, 2018 at DePaul University Lincoln Park Campus, Chicago.

Acquia Developer Center Blog: The Web Is Changing: Introducing Experience Express

1. März 2018 - 18:17

At no point in the history of digital content has there ever been such a dizzying proliferation of devices in our lives, and experiences we encounter and consume. Long the most critical element of an organization’s digital presence, the website is increasingly treated as just a single facet in a kaleidoscope of content channels and form factors. Many of today’s users, in the course of acquiring content or data, never touch a desktop web browser at all.

Tags: acquia drupal planet

Deeson: Talking security at DrupalCamp London 2018

1. März 2018 - 15:48

We’re strong believers that contributing to open source and sharing what we’ve learnt benefits both our agency and the wider community. It’s one of the reasons we offer our team paid conference tickets and support for public speaking.

In particular, we've been key supporters of the European Drupal community since 2007, with the largest team of Acquia certified developers in Europe. We're proud to be in the top 30 of companies contributing to the project globally.

On 3rd March 2018, I’ll be speaking at DrupalCamp London – an event which our own Tim Deeson helped co-found in 2013. It brings together Drupal developers of all levels and from all over Europe to engage in learning and discussion about the project.

Effortless security updates for your Drupal sites.

The title of my session is Warden - Helping Drupal Agencies Sleep at Night. It’s critical to keep your sites up to date with the latest security releases. But it’s a time consuming task to check each site manually. We built Warden to solve this problem.

Warden is an open source solution that allows in-house development teams and agencies to keep track of the status of multiple Drupal sites hosted on different platforms. I’ll explain how Warden makes managing the security of all your sites much more manageable.

This session is for you if you:

  • have a large number of sites hosted with multiple hosting companies that you need to keep track of.
  • have sites that may need security updates but you don’t have the time to investigate.
  • wish there was a central dashboard reporting which of your sites needed security updates applied.

I’ll demonstrate how Warden works and show you how easy it is to see which sites need security updates, saving your team time to focus on other important work. I’ll also discuss best practice for site security and the importance of making sure that all your developers are aware of it.

Come and talk to us.

Quite a few of us from the development team will be at DrupalCamp London this year. Look out for our Technical Director John Ennew, and ask him about job opportunities at Deeson. We’re currently hiring for several roles across the tech chapter, including developers at all levels and development managers.

There are lots of reasons we’re a great agency to work for, including:

  • Flexible and remote working.
  • Paid time to contribute to open source.
  • Transparent pay scales and a fair pay guarantee.
  • £500 annual personal budget for hardware, software or accessories.
  • Mandatory 5 week paid sabbatical every 5 years.

Check out our careers page for more, and don’t forget to follow us on Twitter @deesonlabs for updates throughout DrupalCamp London. We’ll see you back here next week with our highlights!

Specbee: Why Is Drupal CMS a Key To Success For Enterprise Websites In 2018?

1. März 2018 - 15:20

Do you know how much enterprise companies spend on their website annually? What makes their website great? I mean there is obviously the high traffic, better bounce rates and over the top numbers, but is that all?

Drupal Europe: It’s your turn

1. März 2018 - 13:16

We are organizing the biggest Drupal event in Europe in 2018 with a group of community volunteers in collaboration with the Drupal eV (German Drupal Association) and the Drupal Europe Foundation. We’d like to update you on our progress and turn to you for input.

Mark your calendars for September 10–14, 2018 when Drupal Europe will be held in the beautiful Darmstadtium in Darmstadt, Germany. This is a great venue for the conference and only a 20 minutes’ drive from Frankfurt Airport. We just had our second walkthrough last week discussing details with the venue and were impressed.

Photo by Baddy Breidert @baddysonjaBuy your Early Supporter ticket now!

We are now selling Early supporter tickets for 380 EUR (including VAT). Only 300 of these tickets are available, and only for a limited time. Buy now at https://www.drupaleurope.org/#tickets

A new logo

Thanks to all designers we worked with who came up with such great ideas for our branding! We are delighted to release our final logo proudly crafted by sixeleven. Drupal Europe stickers (pictured here) will be available at various Drupal events where our team shows up in the coming months.

Latest on the conference schedule

We are continually looking at how to structure the biggest Drupal event in Europe, and based on exploratory discussions with community members, we believe we are on the right track.

First of all we strongly believe contribution is at the heart of the Drupal project. Figures show that over 44% of Drupal contributors are in Europe. Therefore, in our programme we want to give you more time to contribute by making both Monday and Friday contribution days (formerly called sprints). Mentors will be available on both days to help those new to Drupal contribution.

We are structuring the rest of the event between Tuesday and Thursday on the successful summit model that has worked well at the start of DrupalCons and other regional events. Topics will include government, education, publishing, technology, and community. We are looking for sponsors for each to make possible to put them on.

And the great news is that your single Drupal Europe ticket will give you access to all these workshops, panels and discussions.

We want to hear from you

Although we have plenty of ideas, we realize that this is your conference.

DrupalCON Amsterdam Group photo

Please help us understand you, our audience, better by completing our survey. It should only take 8 minutes or so and still give us lots of valuable insight. While not all questions are mandatory, we added a few open questions to get to know you better.

Thank you, and please share our survey with all your Drupal friends and colleagues to help us make Drupal Europe a success.

See you in September!

Lullabot: The Simplest Path to a Drupal Local Environment

28. Februar 2018 - 18:17

After my article about Drupal Development Environments, we had some discussions about the differences junior developers see when using Drupal and PHP applications locally, compared to React and other front-end tools. Someone mentioned how easy it was for them to get started by running yarn serve in a React project, and I was curious how close to that we could get for Drupal.

To make this a fair comparison, I’m not including managing MySQL databases and the like. Most React apps don’t use a database directly, and if you do need to run backend services locally, the complexity goes way up. In between writing and publishing this article, Stranger in a familiar land: Comparing the novice's first impression of Drupal to other PHP frameworks was published, which constrained itself to using the Drupal GUI installer. I think this guide shows that we can run Drupal locally in very few steps as long as we don't force ourselves to use a GUI.

I also wanted to see what the “new laptop” experience was like. I’ve been migrating my macOS setup between computers for nearly 15 years (if only Windows worked as well!), and it’s easy to forget what exactly is built in and what I’ve added over time. So, I installed a fresh copy of High Sierra in VirtualBox to ensure none of my terminal or Homebrew customizations were giving me a leg up.

Installing Composer

We need Composer to install Drush. Change to the drupal directory in the terminal (cd drupal), and run the Composer installation instructions to download composer.

When composer is done, you will have a composer.phar file in your Drupal directory.

undefined Installing Drush and Drupal

Drush is what will let us easily run Drupal using the built-in PHP webserver. It’s also required to do the initial site installation. Pull Drush into your Drupal site by running:

$ composer require drush/drush

This will not only pull in Drush, but it will also install all of the other libraries Drush needs at the same time.

Once Drush is installed, we have to use it to install Drupal. Drupal does have a graphical installer, but Drush won’t run the PHP webserver unless Drupal is already installed. The most important parameter is the database URL, which tells Drupal what database server to use and how to connect to it. We’re going to use SQLite, which is a simple single-file database. We don’t want the database file itself to be accessible from the web server (in case it’s ever exposed to respond to external requests), so we tell Drupal to put the database in a directory above our Drupal document root.

$ vendor/bin/drush site-install --db-url=sqlite://../drupal.sqlite

undefined

When the installation is done, Drush will tell you the administrator password. If you ever forget it, you can reset it by generating a login link with drush user-login.

Running the Drupal Web Server

To start the web server, use the run-server command:

$ vendor/bin/drush run-server

By default, the server will listen on http://127.0.0.1:8888. Run vendor/bin/drush help run-server to see how to change these and other defaults.

Finally, open that URL in a browser. You should see the Drupal 8 home page and be able to log in with the administrator account shown earlier. Press CTRL-C in the terminal to shut down the web server.

undefined

The default macOS PHP configuration is pretty good, though it sets a very low limit of 2MB for uploaded files. If you need to raise it, copy /etc/php.ini.default to /etc/php.ini with:

sudo cp /etc/php.ini.default /etc/php.ini

Then, edit it with sudo nano /etc/php.ini to change settings as you see fit. You will need to restart the Drush web server after changing this file.

Bonus: Installing Git and Cloning Drupal

I like to use git even for basic testing because I can run git status at any time to see what files I’ve changed or added. I opened the Terminal and ran the git clone command copied from the Drupal project page.

$ git clone --branch 8.5.x https://git.drupal.org/project/drupal.git

The first run of this command prompts to install the developer tools:

undefined

After they install, you need to rerun the git command again (which is accessible by pressing the up arrow on your keyboard).

When this initial clone is done, you will have a Drupal 8.5.x checkout in a folder called “drupal,” and you can go back to the earlier steps to install and run Drupal.

Next Steps

Now that you have a running Drupal 8 site, it’s easy to try out contributed modules or new experimental modules without worrying about breaking a real site. It’s easy to run a “clean” instance of Drupal 8 later, by reinstalling the current site with drush site-install, or by creating a new Drupal git clone separate from the first one. And, if you are evaluating Drupal and decide to use it for a real website, you can set up a better development environment without having to learn Composer and Drush at the same time.

Drupal blog: Three ways we can improve Drupal's evaluator experience

28. Februar 2018 - 17:41

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

Last week, Matthew Grasmick stepped into the shoes of a developer who has no Drupal experience, and attempted to get a new "Hello world!" site up and running using four different PHP frameworks: WordPress, Laravel, Symfony and Drupal. He shared his experience in a transparent blog post. In addition to detailing the inefficiencies in Drupal's download process and end-user documentation, Matt also shows that out of the four frameworks, Drupal required the most steps to get installed.

While it is sobering to read, I'm glad Matthew brought this problem to the forefront. Having a good evaluator experience is critical as it has a direct impact on adoption rates. A lot goes into a successful evaluator experience: from learning what Drupal is, to understanding how it works, getting it installed and getting your first piece of content published.

So how can we make some very necessary improvements to Drupal's evaluator experience?

I like to think of the evaluator experience as a conversion funnel, similar to the purchase funnel developed in 1898 by E. St. Elmo Lewis. It maps an end-user journey from the moment a product attracts the user's attention to the point of use. It's useful to visualize the process as a funnel, because it helps us better understand where the roadblocks are and where to focus our efforts. For example, we know that more than 13 million people visited Drupal.org in 2017 (top of the funnel) and that approximately 75,000 new Drupal 8 websites launched in production (bottom of the funnel). A very large number of evaluators were lost as they moved down the conversion funnel. It would be good to better understand what goes on in between.

As you can see from the image above, the Drupal Association plays an important role at the top of the funnel; from educating people about Drupal, to providing a streamlined download experience on Drupal.org, to helping users find themes and modules, and much more.

The Drupal Association could do more to simplify the evaluator experience. For example, I like the idea of the Drupal Association offering and promoting a hosted, one-click trial service. This could be built by extending a service like Simplytest.me into a hosted evaluation service, especially when combined with the upcoming Umami installation profile. (The existing "Try Drupal" program could evolve into a "Try hosting platforms" program. This could help resolve the expectation mismatch with the current "Try Drupal" program, which is currently more focused on showcasing hosting offerings than providing a seamless Drupal evaluation experience.)

The good news is that the Drupal Association recognizes the same needs, and in the past months, we have been working together on plans to improve Drupal's conversional funnel. The Drupal Association will share its 2018 execution plans in the upcoming weeks. As you'll see, the plans address some of the pain points for evaluators (though not necessarily through a hosted trial service, as that could take significant engineering and infrastructure resources).

The Documentation Working Group also plays a very important role in this process. After reading Matthew's post, I reached out to Joe Shindelar, who is a member of the Drupal Documentation Working Group. He explained that the Documentation Working Group has not been meeting regularly nor coordinating initiatives for some time.

It is time to rethink our approach around Drupal's documentation. Adam Hoenich, a long-time Drupal contributor, recommends that documentation becomes a full-fledged core initiative, including the addition of a Documentation Maintainer to the Core Committer team. His proposal includes blocking commits to Drupal on documentation.

I've no doubt that we have to evolve our governance model surrounding documentation. It's hard to write world-class documentation by committee without good governance and Adam's recommendations are compelling. Drupal's API documentation, for example, is governed by the Core Committers; while there is always room for improvement, it's really well-maintained. Some of you might remember that we had an official Documentation Maintainer role in the past, filled by Jennifer Hodgdon. Reinstating this position could bring documentation back into clearer focus and provide the necessary governance. I also suspect that a stronger emphasis on coordination, governance and recognition for documentation work, would inspire more contributors to help.

Last but not least, this also affects the Drupal (Core) Contributors. Evaluators often spend hours trying to get their web server configured, PHP installed or their database setup. As a community, we could help alleviate this pain by deciding to have a single, recommended default installation environment. For example, we could maintain and promote a Docker container (including an official docker-compose.yml) that ships with the latest version of Drupal. It would simplify many of our documentation efforts, and eliminate many roadblocks from the evaluation process.

To narrow down my recommendations, I would propose the following three steps:

  1. A single, recommended default installation environment (e.g. Docker container) for evaluators or developers taking their first steps in Drupal development.
  2. Infrastructure budget and engineering resources for the Drupal Association so they can offer a true hosted "Try Drupal" service.
  3. A Documentation Maintainer who can focus on end-user documentation, is a member of the Core Committer team and is responsible for defining the scope of what should be documented. Given the amount of work this position would entail, it would be ideal if this person could be at least partially funded.

Of course, there are many other solutions, but these are the areas I'd focus on. As always, success depends on our ability to align on solutions, coordinate all the work, and allocate the time and money to implement the necessary improvements. If you think you can help with any of the proposed steps, please let us know in the comments, and we'll help you get involved.

Hook 42: Using Lando for Drupal 8 Core Issue Patch Testing

28. Februar 2018 - 4:54

Drupal thrives with love and care from the community. We help move the Drupal project forward by mentoring, sharing knowledge, helping with drupal.org (d.o) issues, and more. If you want to help in the d.o issue queues, you are very welcome! While there are many ways to help, one important piece is reviewing and testing code patches.

Drupalize.Me: Symfony 4 and Drupal

27. Februar 2018 - 23:30

Kristof De Jaeger: Webmention.io integration for Drupal 8

27. Februar 2018 - 21:10

I've had my site for quite some time now, the internet archive goes way back to 2002 even! To be fair, most of the content until 2007 wasn't that interesting (not sure what makes me think it is nowadays though, but okay ... ), but it was mostly the primary source of well .. me :). Apart from that, I also use Twitter, but I want to turn this around and let my site be the primary source. The IndieWeb movement is something I only recently discovered, but somehow, the philosophy was in my mind for the last few weeks, and I am not the only one that is talking about it.

So, as a first small step, to figure out who links to my content, I created a simple Drupal 8 module that can receive and store webmentions and pingbacks from Webmention.io. The source is available at https://github.com/swentel/webmention_io. I'll move this drupal.org at some point once it gets into a more polished state, but it also depends on further iterations of getting more interaction feedback to my site.

Update: The repository has already moved to https://github.com/swentel/indieweb - sorry in case you were using it already :) The module allows you to receive webmentions, send webmentions to brid.gy which will look for the microformats added by the module on content and images.

https://brid.gy/ is polling Twitter and forwarding those mentions to this site, and currently likes are being exposed, which is very cool! See the sweet magic happening right here.

Drupal Association blog: Drupal Association 2018 Execution Plan

27. Februar 2018 - 19:41
The 2018 Goal: Growing Drupal Adoption

Drupal 8 is now more than two years old and data shows that it is prefered over Drupal 7. As Dries pointed out in his blog post, Drupal 8 is on the upswing. To lean into this growth, the Drupal Association’s primary goal in 2018 is to accelerate Drupal adoption through our channels: Drupal.org and DrupalCon and other community programs.

Levers for Growing Adoption

One might think that growing adoption is purely a marketing effort, but in fact it is much more. It requires nurturing the entire Drupal customer life cycle.

The Drupal Association primarily serves developers in the community and specifically those contributing time, talent, and treasure. To nurture Drupal adoption and to further step into our mission: to unite the open source community to help them build and promote the software, we need to pull the lense back and think more broadly, without reducing our support for the developer community.

When someone engages with a digital experience created with Drupal, like a cancer patient seeking specific information on the Memorial Sloan-Kettering Cancer Center website or a concerned citizen of the City of London who needs community services information, that experience occurs because many types of personas worked together to create it - from decision maker to builders to marketers. To grow and ensure the longevity of Drupal digital experiences, we need to serve all of those personas.

The adoption journey consists of influencers and decision makers, who are either technical or marketing evaluators working at an end-user organization like a hospital or they are working at a service provider like a digital agency. The technical and marketing evaluators have unique ways of assessing software and we need to make it easy for each one to understand why they should choose Drupal and how to take the next step.

The user journey includes many personas ranging from the digital team who builds something amazing with Drupal to the trainers who teach the marketing department how to use the solution to the content editors and marketing campaign managers creating engagement and conversions with their visitors. Each persona needs to be a power user. Knowing how to easily make the biggest impact with Drupal helps them be heroes at work. Drupal is an extraordinarily powerful platform capable of many things, but adoption won’t grow if users misunderstand Drupal’s power and choose not to continue using it. To avoid this, we need to improve in two areas: total cost of ownership and ease of use.

The community journey includes many types of contributors: coders, camp organizers, mentors, and more. All roles are important for growing and strengthening the community while it innovates the software. The Drupal Association wants to foster a healthy, inclusive community that is focused on moving the project forward in supportive and productive ways. We want to find ways to provide more support and recognition for each community role.

Drupal Association’s 2018 Execution Plan

As you can see, growing Drupal adoption and retaining our users requires a focus on many more personas than we currently focus on today. We certainly have our work cut out for us. Given how broad this focus is, our 2018 execution plan includes near-term, high impact projects that fit within the capacity of our 17 person organization. It also takes into account that the channels we can improve are Drupal.org, DrupalCon, and our other community programs. When selecting the projects, we also kept in mind that while the Drupal Association is moving through its financial turnaround towards long term sustainability, we are not done yet, so we need to be mindful of budget constraints.

Focus areas of our 2018 execution plan

Accelerate the adoption journey of ambitious digital experiences including API-first solutions

  • by inspiring & informing evaluators with case studies and other resources to help convert them into users
  • by improving Drupal (the product) to improve total cost of ownership (TCO) and ease of use

Strengthen the user journey: Continue to delight existing users and help them expand Drupal usage

Support community health

  • foster diversity and inclusion with the DrupalCon diversity speaker program
  • expand the personas we serve and increase global support
  • strengthen connection between Dries Buytaert as the Project Lead and the community at large, on and off of Drupal.org
  • support governance improvements

Build a stronger foundation of support for the Drupal Association

  • ensure organizational and financial health
  • ensure staff satisfaction
  • create better understanding, collaboration between DA & community

Let’s take a closer look at the work we will do for each of these focus areas.

#1) Accelerate the adoption journey

Understand. To begin this work, we first need to understand how Drupal is adopted and who are the decision-making personas throughout Drupal’s customer lifecycle. We also need to understand the adoption journey for both the technical and marketing evaluator so that we can provide the best paths for them to choose Drupal. These insights will inform how we evolve our programs: Drupal.org and DrupalCon.

Drupal.org Front Page - This part of the website is where evaluators learn about Drupal and take the next step toward choosing the software and / or an agency to work with. 93% of our traffic is anonymous, so the first step is knowing who is coming to this page. We will conduct user research and study other software website’s evaluator experiences to determine best practices. Then, we will revamp the Drupal.org front page to better serve evaluators, using an iterative process.

By DrupalCon Nashville, we will roll out our first revamp (an MVP), which will streamline the evaluation path and provide content that helps them move to the next stage. Due to the Association’s lack of marketing and design resources, all Drupal promotional content will be curated from the community. To get to a fully redesigned front page experience, we will need to fundraise for design enhancement. If we find that we need original promotional content on the site, we will need to fundraise for these assets as well.

Drupal.org Tools & Services - Improving Drupal’s total cost of ownership and ease of use will help grow adoption and the Drupal Association can uniquely help with new tools.

  • Total Cost of Ownership - the Drupal Association will work with Drupal core maintainers and other community members to kick off the auto-updates initiative, which will help customers especially in the mid-market. This project will take more than a year and will require funding for sprints. We anticipate re-launching the Drupal 8 Accelerate fundraising campaign to support this effort.
  • East of use - As Dries mentioned at DrupalCon Vienna, many site builders feel left behind with Drupal 8 since they often do not have command line access and are not using tools like Composer. The Drupal Association has proposed building a tool for site builders with the help of Drupal core maintainers and others. Helping this segment will contribute to Drupal 8’s growth.

DrupalCon - While DrupalCon Nashville is largely a Drupal user and community event, we are serving the evaluator by adding in more programming that amplifies the power of Drupal’s digital experiences including API-first solutions.

  • Digital Experience Case Studies - Attendees coming for business and technical content will be inspired as they learn from experts how Drupal solutions were created and have made an impact for organizations like Weather.com, Symenatic, ACLU, and the U.S. Courts. Case studies are found in almost all tracks and specifically in the Ambitious Digital Experience Track.
  • API-first - We offer a new Decoupled Summit for peers to spend one day together discussing best practices for building API-first solutions. Attendees can be further inspired with decoupled case studies as well as sessions in the Horizons Track that shows how to push the boundaries with API-first. Plus, there are many sessions as well as training and labs, teaching attendees how to build decoupled solutions.

After DrupalCon Nashville, the team will strategize to holistically redesign DrupalCon so it better serves the personas within the Drupal customer lifecycle.

Strengthen the User Journey

Understand. A million organizations use Drupal, but we don’t know who they all are. By working with Drupal core maintainers, we will use Project Updates to gain insight into Drupal’s customer base. We will use this insight to better understand things like which sectors are best served or which modules are most used - all of which can better inform the Project and Drupal Association programs.

DrupalCon - As mentioned, DrupalCon Nashville is a user and community event, which has traditionally focused on the “Builder Persona” as well as the Drupal Business Owner Persona. This year, we expand to serve a few more user personas by offering the Technical Leadership Track and the Content Editor Track.

Support Community Health

One of Drupal’s top unique differentiators is our large, global, passionate community. As the Drupal Association and community come together to work on initiatives related to Drupal.org, DrupalCon and other Drupal Association programs, we want to help the community thrive by focusing in the following areas:

Inclusion - Drupal and our community is better when we include everyone to move Drupal forward in a positive and productive way. A diverse community results in great things. The Drupal Association wants to promote inclusivity by serving more personas, acting more globally, and expanding our DrupalCon speaker diversity initiative.

Expanding who we serve:

  • Persona - as we better understand how to serve our currently under-served personas like content editors and marketing managers, we also need to find a way to bring them into our community. An example of a question that we will ask in the course of this work is “how do camps run campaigns to attract Drupal evaluators?" Imagine if we had content editors in our community to help run these kinds of camp campaigns?
  • Global - our programs need to scale globally. That is why we are evaluating a new operational model for DrupalCon, starting in Europe. If we find that we can successfully license DrupalCon to a European entity, then we will use this model in other parts of the world, giving all community members the chance to experience the magic of DrupalCon. We are also looking at other existing programs like the camp fiscal sponsorship program. We are evaluating if Open Collective can support more countries than what we can currently support - for camps, project maintainers, and other community initiatives. Additionally, the Drupal Association Board is discussing how to meet the community's request for more global representation on the board through the community elected positions. Stay tuned get ready for the 2018 community board elections this summer!
  • DrupalCon speaker diversity - The DrupalCon team continued prioritizing speaker diversity to expand the speaker line up with high quality speakers from under-represented groups. Building off the initiative created last year where 33% of speakers were from under-represented groups, the track chairs worked hard to recruit diverse speakers and the Drupal Association contributed scholarships to help them attend the event. Of the speakers slated to speak at DrupalCon Nashville, 40% of them self-selected that they identify with an underrepresented group.
  • Contributors - We launched the contribution credit system a few years ago. The algorithm first rewarded code contributors. Last year we expanded it to recognize and reward Drupal Supporting Partners and those who contribute case studies. This year, we are working on a solution so we can finally credit camp organizers who put in so many hours to create special events around the world that move the project forward. How are we doing this? With OATH. Camps asked for Drupal.org user profile data so community members don’t have to create yet another Drupal-related profile page when they sign up for a camp. OATH allows us to push this information to camps and create a better experience for the camp attendee. Plus, this integration will also pull in information about the camp organizers into Drupal.org, allowing us to give them credit.

Creating a stronger connection between the Project Lead and the community - As one of the largest open source projects, it can be hard to scale relationships with one another - especially with the founder of the project, Dries Buytaert. We will foster more interaction between Dries and the community through roundtable discussions held virtually and at various Drupal events starting at DrupalCon Nashville. It is a chance to focus on important topics and have a discussion which fosters insight, understanding and moves the project forward in positive, productive ways.

Support Community Governance - Last year the community held many discussions on how to evolve community governance and came up with next steps. The Drupal Association looks forward to the release of the project’s shared values that will inform all of us as we work together on important community guidelines like the Drupal Code of Conduct.

Providing clarity within Drupal Association channels: Drupal.org and DrupalCon. In response to the community discussions, the Drupal Association will provide the community with more clarity on what is expected behavior in general and for leaders and what are the consequences of unacceptable behavior. We have already updated the DrupalCon Speaker Agreement and DrupalCon Code of Conduct with the help from many in the community. We will also update the Drupal.org Terms of Service in a similar fashion.

Improved Developer Tooling. Last year we worked with several community members to evaluate developer tooling. We published a detailed analysis of our findings and of our prototype work with three key options: GitHub, GitLab, and BitBucket (read more here). At the time of posting, there were a few key blockers to some of the options - but this situation is changing rapidly. If we find that blockers are removed and we have capacity this year, we will start the migration - and, of course, we will communicate to the community before we do anything.

Drupal Association Support

The Drupal Association can never achieve its mission without the support of the community and support comes in several forms: time, talent, and treasure. We are ever grateful for the thousands who contribute countless hours who move the Drupal project forward.

Financial Support
The Drupal Association is making strides with its financial turnaround (2017 details coming soon. It’s positive news) and we will continue to focus on sustainability in 2018. Financial success means we need to meet our KPIs: 10% Net Margin % and 15% cash reserve.

Reaching those KPIs will require a mix of focus:

  • Continue showing value to our funders: DrupalCon attendees and sponsors, members and Supporters, digital advertisers and sponsors, and Drupal job posters
  • Launching the Drupal 8 Accelerate fundraising program for key initiatives like Auto-updates
  • Identifying sponsored work for the engineering team to solve a common pain point
  • Creating a value add service for Drupal that can be monetized
Community Support

In addition to financial support, the Drupal Association wants to grow its ambassadorship. We will build a stronger relationship with the community through improved engagement and communication efforts especially through the help of our new Community Liaison.

Staff Support

Additionally, we want to focus on a thriving staff, who are supported and empowered to do great mission-driven work for the community in a sustainable way. We use OfficeVibe as one of the ways to monitor team health and our goal is to remain above our agreed upon healthy targets. 

Reduce compliance risk

Operationally, we want to reduce the Drupal Association’s risk so that nothing impacts the community programs like keeping Drupal.org online. While we do many things to reduce risk like hold event insurance, this year we are specifically focusing on having:

  • All drupal.org subsites GDPR ready by May 1, 2018
  • All commerce sites updated for reduced PCI scope by May 1, 2018, to ease the effort of maintaining compliance
Execution Plan Dashboard

Similar to last year, we use an execution plan dashboard to breakdown our projects and assign metrics and milestones to them. You can find the 2018 execution plan here.

We provide progress updates in the public board meetings and the board packet includes a full report. We release the board packet with the execution dashboard after each board meeting via a blog and we post board packets and other board relate materials here

Follow Drupal Association blogs related to board meetings if you would like to see how we are doing against our plan.

We are excited to serve the community and work with many of you in 2018. It's amazing what we can accomplish together.

Acro Media: Quickbooks Enterprise Integration in Drupal Commerce 2

27. Februar 2018 - 18:30
Background

When I was tasked with integrating Quickbooks accounting software with an existing Commerce 2.x installation, instead of asking questions a normal Drupal developer would, I was asking myself one question, what exactly is Quickbooks? Though I’m a bit embarrassed, I’m not going to shy away from admitting that I have not ever had an opportunity to explore or be exposed to the Quickbooks accounting software. So, doing an integration first required me to do some research on Quickbooks.

For the unaware (which I doubt there are any), Quickbooks is an accounting software used by businesses to manage sales and expenses and keep track of daily business transactions. It’s often used to invoice customers, pay bills, generate reports, and for tax filing purposes. This fully-developed software takes care of all the different aspects of accounting. Thus, quite a few small to medium-scale businesses use Quickbooks because it makes life easy for them. However, if you’re doing business online, the process becomes a little trickier.

For a lot of customers who have an online store, a big pain for them is syncing their sale transactions like order, customer, tax and payment data into Quickbooks for bookkeeping. Basically, how do you transfer over your online transactions to Quickbooks?

We’ve had customers in the past who just assign a staff to sit and enter the days transactions, manually, at the end of each day. When you have hundreds of orders a day, especially, like during the holidays, this can be a huge headache. Not only are you wasting time and money by entering the duplicate data but you’re also exposing yourself to human errors. Because, at the end of the day, all this data is used for filing taxes, generating invoices, re-ordering products, etc., and any error in the data can wreak havoc.

So, out of this dilemma, quite a few Drupal modules came up which paved the way to integrating Commerce/Ubercart transactions into Quickbooks. But most of them are for Drupal 7. How do we integrate a Drupal 8 site running Commerce 2.x into Quickbooks? Essentially, that was my task. It was an excellent learning experience and I’m hoping that I can shed some light on the procedure for syncing your commerce data into Quickbooks.

Setup Drupal Commerce 2 to sync with Quickbooks Enterprise

Our job today will be trying to integrate a Drupal 8 Commerce 2 installation with Quickbooks Desktop. Before we start, I’d like to thank everyone who created the commerce_qb_webconnect module for all their awesome work and especially, Lucas Hedding (heddn), for supporting me in this endeavor.

Essentially, commerce_qb_webconnect, under the hood, uses migrate to export from D8 to a SOAP service destination. This also means that we have more flexibility, because any of the means to work and interact with a migration lets us interact and alter the exported details of a Quickbooks export as well.

The initial setup is as follows (I’m assuming that you already have been using Quickbooks Enterprise Desktop):

  1. Download and install Quickbooks Enterprise Desktop (we used the 2017 Retail version)
    • Note: Quickbooks Desktop, currently, only works on the Windows operating system. Also, be very careful about which version you are purchasing. Make sure you select the correct country version based on where you’re doing business because each version is fitted to a specific country and its tax system, and unfortunately, you cannot just switch countries in the software.
    • Setup all your accounting details on Quickbooks
    • Go to Payments and click on the PMT. Method select list and add the following payment methods depending on the payment gateways enabled on your site (these are the gateways on my test site):
      - Example
      - Default
  2. Download and install Quickbooks Web Connector 2.2.0.80
  3. Download the Drupal module commerce_qb_webconnect

    $ composer require drupal/commerce_qb_webconnectAt the time of this writing, the module has an 8.x-2.0 alpha version out and it contains most of the functionality required to get the commerce data into Quickbooks.

  4. Go to your Drupal installation
    • Note: If it's a local installation, make sure the url of the site starts with http://localhost (yes it has to have the words localhost, it’s hardcoded). Else, if it's a public site, you have to make sure it has an https certificate.
  5. Go to /admin/people and add the password for **quickbooks_user ** in Drupal and note that password as we’ll be using it in the Web Connector application.
  6. Go to /admin/commerce/config/commerce_quickbooks_enterprise/qwc and make sure your config looks like this:



  7. Now, Download QWC file (click that button).
  8. Open Quickbooks Web Connector and click on 'Add an application' and upload the .qwc file.
  9. Click 'Yes' to all the prompts and your file should be successfully added.
  10. Now, go to /admin/commerce/config/commerce_quickbooks_enterprise/quickbooksadmin and add the following configs and leave everything else as it is:



  11. Make sure to replace the Income, COGS, and Assets accounts with the appropriate ones matching your accounting information.
Syncing the Data with Quickbooks Enterprise
  1. Assuming you have create some products on your site, add a product to the cart, finish checkout and complete the order.
  2. Go to /admin/reports/dblog and notice you'll see messages like: "Added Invoice Order to export queue!"
  3. Now, go to the Web Connector and select the application we just uploaded with the .qwc file and hit 'Update Selected'. Make sure you enter the same password that we saved earlier (See setup step 5) for the password field.



  4. The order (invoice/sales receipt), product, payment, and customer will automatically be imported to your Quickbooks Desktop.
  5. Check Quickbooks Desktop to verify they have been added by clicking on 'Customer' and finding the name on the order there and then 'Recent Transactions' and then, Invoice/Sales Receipt. You can see the product in the 'Item' section. You can see the payment in the 'Payment' section by clicking on the 'Received From' select list and selecting the name on the order.



    And voila! If everything worked, you should see all the details from the new transaction synced in your Quickbooks Enterprise Desktop. The need for wasting time and money on manual entry and chances of user errors all vanish by integrating Quickbooks with your online Drupal 8 Commerce 2 store(s).
More from Acro Media Need a hand?

Would you like Quickbooks integrated into your Drupal Commerce website, but need a hand doing it? We've done it many times and would love to help.

Dries Buytaert: Three ways we can improve Drupal's evaluator experience

27. Februar 2018 - 17:41

Last week, Matthew Grasmick stepped into the shoes of a developer who has no Drupal experience, and attempted to get a new "Hello world!" site up and running using four different PHP frameworks: WordPress, Laravel, Symfony and Drupal. He shared his experience in a transparent blog post. In addition to detailing the inefficiencies in Drupal's download process and end-user documentation, Matt also shows that out of the four frameworks, Drupal required the most steps to get installed.

While it is sobering to read, I'm glad Matthew brought this problem to the forefront. Having a good evaluator experience is critical as it has a direct impact on adoption rates. A lot goes into a successful evaluator experience: from learning what Drupal is, to understanding how it works, getting it installed and getting your first piece of content published.

So how can we make some very necessary improvements to Drupal's evaluator experience?

I like to think of the evaluator experience as a conversion funnel, similar to the purchase funnel developed in 1898 by E. St. Elmo Lewis. It maps an end-user journey from the moment a product attracts the user's attention to the point of use. It's useful to visualize the process as a funnel, because it helps us better understand where the roadblocks are and where to focus our efforts. For example, we know that more than 13 million people visited Drupal.org in 2017 (top of the funnel) and that approximately 75,000 new Drupal 8 websites launched in production (bottom of the funnel). A very large number of evaluators were lost as they moved down the conversion funnel. It would be good to better understand what goes on in between.

As you can see from the image above, the Drupal Association plays an important role at the top of the funnel; from educating people about Drupal, to providing a streamlined download experience on Drupal.org, to helping users find themes and modules, and much more.

The Drupal Association could do more to simplify the evaluator experience. For example, I like the idea of the Drupal Association offering and promoting a hosted, one-click trial service. This could be built by extending a service like Simplytest.me into a hosted evaluation service, especially when combined with the upcoming Umami installation profile. (The existing "Try Drupal" program could evolve into a "Try hosting platforms" program. This could help resolve the expectation mismatch with the current "Try Drupal" program, which is currently more focused on showcasing hosting offerings than providing a seamless Drupal evaluation experience.)

The good news is that the Drupal Association recognizes the same needs, and in the past months, we have been working together on plans to improve Drupal's conversional funnel. The Drupal Association will share its 2018 execution plans in the upcoming weeks. As you'll see, the plans address some of the pain points for evaluators (though not necessarily through a hosted trial service, as that could take significant engineering and infrastructure resources).

The Documentation Working Group also plays a very important role in this process. After reading Matthew's post, I reached out to Joe Shindelar, who is a member of the Drupal Documentation Working Group. He explained that the Documentation Working Group has not been meeting regularly nor coordinating initiatives for some time.

It is time to rethink our approach around Drupal's documentation. Adam Hoenich, a long-time Drupal contributor, recommends that documentation becomes a full-fledged core initiative, including the addition of a Documentation Maintainer to the Core Committer team. His proposal includes blocking commits to Drupal on documentation.

I've no doubt that we have to evolve our governance model surrounding documentation. It's hard to write world-class documentation by committee without good governance and Adam's recommendations are compelling. Drupal's API documentation, for example, is governed by the Core Committers; while there is always room for improvement, it's really well-maintained. Some of you might remember that we had an official Documentation Maintainer role in the past, filled by Jennifer Hodgdon. Reinstating this position could bring documentation back into clearer focus and provide the necessary governance. I also suspect that a stronger emphasis on coordination, governance and recognition for documentation work, would inspire more contributors to help.

Last but not least, this also affects the Drupal (Core) Contributors. Evaluators often spend hours trying to get their web server configured, PHP installed or their database setup. As a community, we could help elevate this pain by deciding to have a single, recommended default installation environment. For example, we could maintain and promote a Docker container (including an official docker-compose.yml) that ships with the latest version of Drupal. It would simplify many of our documentation efforts, and eliminate many roadblocks from the evaluation process.

To narrow down my recommendations, I would propose the following three steps:

  1. A single, recommended default installation environment (e.g. Docker container) for evaluators or developers taking their first steps in Drupal development.
  2. Infrastructure budget and engineering resources for the Drupal Association so they can offer a true hosted "Try Drupal" service.
  3. A Documentation Maintainer who can focus on end-user documentation, is a member of the Core Committer team and is responsible for defining the scope of what should be documented. Given the amount of work this position would entail, it would be ideal if this person could be at least partially funded.
Of course, there are many other solutions, but these are the areas I'd focus on. As always, success depends on our ability to align on solutions, coordinate all the work, and allocate the time and money to implement the necessary improvements. If you think you can help with any of the proposed steps, please let us know in the comments, and we'll help you get involved.

Chromatic: Daily Drupal Backups with Jenkins in Five Lines

27. Februar 2018 - 16:00

It's important to keep databases (and other non-version-controlled content) regularly backed up to a remote location. By combining a little bash, Amazon's aws-cli library, and Jenkins (or cron!), we can set up fully automated daily database backups in only five lines of code!