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

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!

Web Wash: Manage URL Redirects using Redirect module in Drupal 8

27. Februar 2018 - 15:30

The ability to create and maintain redirects on a website is vital for long-term success.

Once your site has a lot of content, you may need to do a content audit. This will require merging or deleting pages which are no longer important. To maintain the traffic from these deleted or merged pages, you'll need to create URL redirects. Now I understand this isn't the most exciting part of site building but it's important to get it right.

The module which will handle all of this is perfectly name; Redirect.

The Redirect module lets you create and manage redirects using a simple user interface. Just define a source and destination and you're good to go. You can also track 404 errors, using a sub-module, so if you have a page indexed in Google with a broken path then it'll be logged and a redirect can be easily created.

Commerce Guys: Drupal Commerce needs API-first and modern JavaScript in Drupal

27. Februar 2018 - 9:05

Drupal core has two initiatives that are helping modernize our platform and make it easier to work with. There is the API-First Initiative and the proposed JavaScript Framework Initiative. While separate, these two initiatives have a big and somewhat overlapping impact. Together they will make Drupal an even greater eCommerce platform and allow us to do more amazing things with Drupal Commerce.

What is API-First, and why should it matter?

The initiative has a simple purpose: make it easy for the data managed by Drupal to be consumed anywhere. A common need driving the initiative is the usage of Drupal with a decoupled frontend — i.e. where a JavaScript library or mobile app is rendering content from Drupal but Drupal itself has no part in the render process.

We have our own hot buzzword in the eCommerce realm: omnichannel. What does omnichannel mean? Well, it’s this idea you’re selling anywhere and everywhere. Your products are controlled in one location and appear on Amazon, Walmart.com Marketplace, Google Merchant Seller, custom mobile apps, in-store kiosks, etc. You manager your products in Drupal and push the relevant data out. The API-First initiative will make it easier to integrate with these kinds of services.

It also expands what Drupal Commerce can be, beyond just a full-stack store. In one recent case study, Running a Billion Dollar Business on Drupal Commerce, Drupal Commerce was used in a micro-service architecture. Drupal Commerce has the data model act as a product information manager, inventory management, an order workflow manager, and more — all the components you expect out of an ERP and tools Drupal Commerce users generally already use. The API-First initiative can make it easier to interface with Drupal and allow Drupal Commerce to serve in these capacities.

Current Drupal Commerce users already implement the RESTful Web Services module and JSON API to accomplish these tasks. I look forward to what can come as Drupal core has better support for exporting internal data for external consumers.

Modernized JavaScript will build a better Drupal Commerce

What was your last online shopping experience like? How did the shopping cart work? Did the checkout refresh itself or specific parts of the page? Did it have fancy loaders and other doodads that let you know it was processing without refreshing?

Drupal has some dated JavaScript. While it has a pretty robust JavaScript API all things considered, it was written by PHP developers for PHP developers. We have Underscore and Backbone in Drupal 8, but they became outdated for the modern web by the time we got to use them.

For an example of where we'd like to be, take a look at the following Add to Cart experience. There’s no page reload, but adding a product to the cart shows a confirmation alert and my cart block increments its quantity. These are interactions we are growing accustomed to and taking for granted, until we have to implement them.

In Drupal Commerce, or Drupal rather, this currently would involve adjusting the add to cart form to support an #ajax call. You'd have to hope that a status message block is present to render the success message, and then you have to make a best guess to target the cart block and change it’s quantity. All of this needs to be done in PHP to build Ajax response commands. It’s possible, but it shouldn’t be so hard.

With the API-First initiative we can begin to build a public facing API for working with carts. Then with modern JavaScript tooling in Drupal we can start to build components with ReactJS to enable these experiences. If ReactJS isn’t your thing, the groundwork is there to use AngularJS or VueJS and reference whatever comes out of the box as an example.

Having an improved Drupal core means an improved Drupal Commerce. These two initiatives let us tackle the frontend user experience and even the backoffice administrative experience.

Check out the other strategic initiatives

There are many initiatives happening, and all of them make an impact. If you have not read about them, I highly advise you check out the Drupal Core Strategic Initiatives page.

OSTraining: How to Create Responsive Off-canvas Menu in Drupal 8

27. Februar 2018 - 7:17

An off-canvas menu is the best way to offer a pleasant experience to those visiting your site from mobile devices. It is rapidly becoming a standard for any website.

In this tutorial, you will learn how to create and configure an off-canvas menu with the "Responsive and off canvas menu" Drupal 8 module.

Oliver Davies: Queuing Private Messages in Drupal 8

27. Februar 2018 - 2:00
Queuing a Message

The module provices a PrivateMessageQueuer service (private_message_queue.queuer) which queues the items via the queue() method.

The method accepts an array of User objects as the messsage recipients, the message body text and another user as the message owner. (I’m currently considering whether to make the owner optional, and default to the current user if one is not specified)

Here is an example:

$recipients = $this->getRecipients(); // An array of User objects. $message = 'Some message text'; $owner = \Drupal::currentUser(); $queuer = \Drupal::service('private_message_queue.queuer'); $queuer->queue($recipients, $message, $owner);

These three pieces of data are then saved as part of the queued item. You can see these by checking the "queue" table in the database or by running drush queue-list.

$ drush queue-list Queue Items Class private_message_queue 19 Drupal\Core\Queue\DatabaseQueue Processing the Queue

The module also provides a PrivateMessageQueue queue worker, which processes the queued items. For each item, it creates a new private message setting the owner and the message body.

It uses the PrivateMessageThread class from the Private Message module to find for an existing thread for the specified recipients, or creates a new thread if one isn't found. The new message is then added to the thread.

The queue is processed on each cron run, so I recommend adding a module like Ultimate Cron so that you can process the queued items frequently (e.g. every 15 minutes) and run the heavier tasks like checking for updates etc less frequently (e.g. once a day).

You can also process the queue manually with Drush using the drush queue-run <queue-name> command - e.g. drush queue-run private_message_queue.

$ drush queue-run private_message_queue Processed 19 items from the private_message_queue queue in 3.34 sec.

Tandem's Drupal Blog: Migrating to a Drupal 8 Date Range

27. Februar 2018 - 2:00
February 27, 2018 Migrating a date range to Drupal 8 is a lot easier now than it was a year ago. Below I will show you how to transform the data to get the date ranges to migrate to Drupal 8 properly. The Situation before us Right now we are using the Migrate Source CSV module to handle the migration. In the CSV that we used, dates were export...

Evolving Web: Install a Specific Version of PHP or Drush on Acquia Dev Desktop

26. Februar 2018 - 22:20

While working on a project with Acquia Dev Desktop (ADD), we needed to run a specific version of PHP which is not included with ADD by default. We started hacking ADD and came up with our own solution. For those in a hurry, you can go directly to the solution.

The Problem

While working for one of our clients, we had to work with some tools which were a part of their workflow. Their websites were hosted on Acquia Cloud so they were using Acquia Dev Desktop (ADD) - Acquia's development stack and cloud client. This tool allows developers to "run and develop Drupal sites locally and to optionally sync them with Acquia Cloud".

At the time of writing this post ADD is was version 2.1 and it supported only up to PHP 7.0.14. At first, we thought it was good enough. But soon we discovered that the cloud servers were running more cutting-edge versions such as PHP 7.1.8. 

The first issue came when we had to update our Composer packages. Running composer from different environments running different versions of PHP may result in each environment downloading a different version of the same package. A workaround is to always have the same environment run the composer update. However, we needed to ensure that the environment with the oldest version of PHP was able to run all the updated libraries. For example, the latest doctrine/common libraries require PHP ~7.1, so using ADD 2 with PHP 7.0.14 we couldn't run it.

Another issue arose when we decided to update to Drupal 8.4.x. According to an issue on drupal.org, Drupal 8.4.x requires Drush 8.1.12+, but ADD 2 ships with Drush 8.1.10.

Facing such issues, we asked Google, "how to add a version of PHP to Acquia Dev Desktop?" No good results came up so we decided to start hacking ADD and ultimately found a solution.

Adding a specific version of PHP to Acquia Dev Desktop

Our solution worked on a Mac, but we believe it should work somewhat similarly on Windows.

Step 1: Install the required version of PHP

Install the desired PHP version with Brew, in our situation it was PHP 7.1.8_20:

$ brew install homebrew/php/php71Step 2: Copy PHP files into Acquia Dev Desktop

Stop ADD if it's running and copy the PHP files into the Acquia Dev Desktop directories:

$ cp -r /usr/local/Cellar/php71/7.1.8_20/ /Applications/DevDesktop​/php7_1 $ cp /usr/local/etc/php/7.1/php.ini /Applications/DevDesktop​​/php7_1/bin/php.ini

Note: We tried to create a symlink to prevent file duplication but it didn't work, so we ended simply copying the files into ADD, respecting its directories nomenclature and structure.

Step 3: Make Acquia Dev Desktop detect the new version of PHP

Edit /Applications/DevDesktop/Acquia Dev Desktop.app/Contents/MacOS/static.ini and after the last contiguous line under [php/4] add the following lines:

[php/5] id=php7_1 executablePath=php7_1/bin/php cgiExecutablePath=php7_1/bin/php-cgi configPath=/Applications/DevDesktop/php7_1/bin/php.ini

Note: If you are using Finder to navigate to the file, you may have to right click on the Acquia Dev Desktop application icon to see its content.

Step 4: Configure Acquia Dev Desktop

Open the ADD Preferences and select the Config tab. Now, in the Default PHP Version, select the one we just added. Make sure you select PHP mode Fast CGI and have PHP use the php.ini we previously copied into ADD in Step 2. Back in the ADD Preferences main window, in the left panel select the site you are working on, and then in Default PHP Version select the desired version. Then, click Ok and restart Apache.

Step 5: Configure Drush to use the same PHP version

To configure ADD's Drush to use the same PHP version, edit /Applications/DevDesktop/tools/drush and replace the following:

# Before [ -z "$PHP_ID" ] && PHP_ID=php5_5     # After export PHP_ID="php7_1"Step 6: Update Acquia Dev Desktop's version of Drush

To udpate Acquia Dev Desktop's Drush, edit /Applications/DevDesktop/tools/composer.json and make the following change:

// Before "drush/drush": "8.1.10" // After "drush/drush": "^8.1.12"

Note: Drupal 8.4.x requires Drush 8.1.12+.

Now, in the terminal, go to the same directory as composer.json and run this command to finish:

composer update --optimize-autoloader

Et voilà! We have just installed a custom version of PHP on Acquia Dev Desktop. Feel free to share your experiences in the comments below to help other fellow readers.

+ more awesome articles by Evolving Web

Evolving Web: Install a Specific Version of PHP on Acquia Dev Desktop

26. Februar 2018 - 22:20

While working on a project with Acquia Dev Desktop (ADD), we needed to run a specific version of PHP which is not included with ADD by default. We started hacking ADD and came up with our own solution. For those in a hurry, you can go directly to the solution.

The Problem

While working for one of our clients, we had to work with some tools which were a part of their workflow. Their websites were hosted on Acquia Cloud so they were using Acquia Dev Desktop (ADD) - Acquia's development stack and cloud client. This tool allows developers to "run and develop Drupal sites locally and to optionally sync them with Acquia Cloud".

At the time of writing this post ADD is was version 2.1 and it supported only up to PHP 7.0.14. At first, we thought it was good enough. But soon we discovered that the cloud servers were running more cutting-edge versions such as PHP 7.1.8. 

The first issue came when we had to update our Composer packages. Running composer from different environments running different versions of PHP may result in each environment downloading a different version of the same package. A workaround is to always have the same environment run the composer update. However, we needed to ensure that the environment with the oldest version of PHP was able to run all the updated libraries. For example, the latest doctrine/common libraries require PHP ~7.1, so using ADD 2 with PHP 7.0.14 we couldn't run it.

Another issue arose when we decided to update to Drupal 8.4.x. According to an issue on drupal.org, Drupal 8.4.x requires Drush 8.1.12+, but ADD 2 ships with Drush 8.1.10.

Facing such issues, we asked Google, "how to add a version of PHP to Acquia Dev Desktop?" No good results came up so we decided to start hacking ADD and ultimately found a solution.

Adding a specific version of PHP to Acquia Dev Desktop

Our solution worked on a Mac, but we believe it should work somewhat similarly on Windows.

Step 1: Install the required version of PHP

Install the desired PHP version with Brew, in our situation it was PHP 7.1.8_20:

$ brew install homebrew/php/php71Step 2: Copy PHP files into Acquia Dev Desktop

Stop ADD if it's running and copy the PHP files into the Acquia Dev Desktop directories:

$ cp -r /usr/local/Cellar/php71/7.1.8_20/ /Applications/DevDesktop​/php7_1 $ cp /usr/local/etc/php/7.1/php.ini /Applications/DevDesktop​​/php7_1/bin/php.ini

Note: We tried to create a symlink to prevent file duplication but it didn't work, so we ended simply copying the files into ADD, respecting its directories nomenclature and structure.

Step 3: Make Acquia Dev Desktop detect the new version of PHP

Edit /Applications/DevDesktop/Acquia Dev Desktop.app/Contents/MacOS/static.ini and after the last contiguous line under [php/4] add the following lines:

[php/5] id=php7_1 executablePath=php7_1/bin/php cgiExecutablePath=php7_1/bin/php-cgi configPath=/Applications/DevDesktop/php7_1/bin/php.ini

Note: If you are using Finder to navigate to the file, you may have to right click on the Acquia Dev Desktop application icon to see its content.

Step 4: Configure Acquia Dev Desktop

Open the ADD Preferences and select the Config tab. Now, in the Default PHP Version, select the one we just added. Make sure you select PHP mode Fast CGI and have PHP use the php.ini we previously copied into ADD in Step 2. Back in the ADD Preferences main window, in the left panel select the site you are working on, and then in Default PHP Version select the desired version. Then, click Ok and restart Apache.

Step 5: Configure Drush to use the same PHP version

To configure ADD's Drush to use the same PHP version, edit /Applications/DevDesktop/tools/drush and replace the following:

# Before [ -z "$PHP_ID" ] && PHP_ID=php5_5     # After export PHP_ID="php7_1"Step 6: Update Acquia Dev Desktop's version of Drush

To udpate Acquia Dev Desktop's Drush, edit /Applications/DevDesktop/tools/composer.json and make the following change:

// Before "drush/drush": "8.1.10" // After "drush/drush": "^8.1.12"

Note: Drupal 8.4.x requires Drush 8.1.12+.

Now, in the terminal, go to the same directory as composer.json and run this command to finish:

composer update --optimize-autoloader

Et voilà! We have just installed a custom version of PHP on Acquia Dev Desktop. Feel free to share your experiences in the comments below to help other fellow readers.

+ more awesome articles by Evolving Web