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

Drupal.org blog: Drupal Association Technology Partner JetBrains offers free PhpStorm licenses for contributors

26. Februar 2018 - 21:16

We are happy to announce today that JetBrains is continuing their support of the Drupal Association and the Drupal project in a new way:

  • JetBrains is offering any contributor on Drupal.org with more than 35 contribution credits in the past year a free PhpStorm license.

It has been part of JetBrains mission to give back to key contributors in the open source world, and we're grateful that they want to offer this opportunity as a benefit for Drupal.org contribution credits.

To receive the free PhpStorm Open Source license, please fill out this open source license request form. Be sure to include a link to your profile on Drupal.org, as it will be checked to ensure you meet the 35 contributions threshold. You can read more about PhpStorm and the Open Source support program by JetBrains.

Many thanks to JetBrains, we’re excited for their continued partnership.

Jeff Geerling's Blog: What do you use to build and develop Drupal sites?

26. Februar 2018 - 17:28

tl;dr: Go complete the Drupal Local Development Survey, and we'll present the results (among other things) at MidCamp in a couple weeks!

Local development for Drupal is a subject I've invested a lot of time into. At the start of my Drupal journey, I used to use MAMP, then MAMP Pro, then a native *AMP installation. Then when I learned about Vagrant I started building Vagrant-based environments with shell scripts. Then I learned Ansible and started using Vagrant and Ansible. And then I learned Docker and used Ansible, Docker, and sometimes Vagrant!

Everyone's journey is different—but one thing most of us can agree on is: it ain't easy finding a way to run Drupal on your local workstation if you've never done it before.

Should you use MAMP/WAMP/XAMPP? Should you use Acquia Dev Desktop? Should you use Docker or Vagrant and build your own environment? Should you use a packaged solution like Drupal VM or Lando? And then how will you manage your codebase? How will you build a theme?

2bits: Optimizing Drupal Views: Query Time and Rendering Time

26. Februar 2018 - 16:56

A recent client performance assessment consulting project showed that on their site, the main page that logged in users would browse is slow. Tuning the server for memory and disk throughput helped somewhat, but did not fully eliminate the issue.

Looking at the page, it was a view, and the total time was around 2.75 seconds.

The main query was not efficient, with lots of left joins, and lots of filtering criteria:

SELECT node.nid AS nid,
... AS ...
... AS ...
'node' AS field_data_field_aaa_node_entity_type,
'node' AS field_data_field_bbb_node_entity_type,
'node' AS field_data_field_ccc_node_entity_type,
... AS ...
FROM node
INNER JOIN ... ON node.uid = ...
LEFT JOIN ... ON ... = ...  AND ... = ...
LEFT JOIN ... ON ... = ... AND (... = '12'
OR ... = '11'
OR ... = '15'
OR ... = '24')
WHERE (( (node.status = '1')
AND (node.type IN ('something'))
AND (... <> '0')
AND ((... <> '1') )
AND ((... = '4'))
AND (... IS NULL ) ))
ORDER  BY  ... DESC
LIMIT  51   OFFSET 0

That caused the first pass to sift through over 24,000 rows, while using both file sort and temporary tables. Both operations are disk intensive.

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: ...
   partitions: NULL
         type: range
possible_keys: PRIMARY,...
          key: rid
      key_len: 8
          ref: NULL
         rows: 24039
     filtered: 100.00
        Extra: Using where; Using index; Using temporary; Using filesort
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: ...
   partitions: NULL
         type: eq_ref
possible_keys: PRIMARY,status
          key: PRIMARY
      key_len: 4
          ref: test43....
         rows: 1
     filtered: 50.00
        Extra: Using where
*************************** 3. row ***************************
           id: 1
  select_type: SIMPLE
        table: node
   partitions: NULL
         type: ref
possible_keys: uid,status,type,node_status_type
          key: uid
      key_len: 4
          ref: test43....
         rows: 5
     filtered: 12.18
        Extra: Using index condition; Using where
*************************** 4. row ***************************
           id: 1
  select_type: SIMPLE
        table: ...
   partitions: NULL
         type: ref
possible_keys: PRIMARY,...
          key: PRIMARY
      key_len: 4
          ref: test43....
         rows: 2
     filtered: 54.50
        Extra: Using where; Not exists; Using index

But here is the puzzle: this query took 250 to 450 milliseconds at most.

Where did the rest of the 2,750 milliseconds go?

To find out, we use xhprof, the profiler for PHP.

In the screenshot below, you can see that the total page processing time (Total Inc. Wall Time, top right) is 2,732 milliseconds.

Out of that, 85% is in database queries (252 total queries, totaling 2,326 milliseconds, Excl.Wall Time).

What are these queries?

They are queries to other tables in the database to retrieve fields for each row.

For example, if you have a product view, with certain criteria, the result still has to get the product name, its price, its image, ...etc.

All these queries add up, specially when you are loading 50 of them. The time needed to retrieve each field, and rendering it for output is multiplied by the number of rows retrieved.

So, how do you mitigate that overhead? There are several ways:

  • Reduce the number of rows returned by the view. For example, instead of 50, make it 25. That would half the number of queries (and processing) needed to produce the page.
  • If the query is the same for all logged in users, then enable views caching (under Advanced when you edit the view), and enable both Query Result and Rendered Output caching. Use time based caching, for as long as practical to your site (e.g. if you add products or change prices only once a day, then you can cache the results for 20 hours or more).
  • Use a fast caching layer, such as the memcache module, instead of the default database caching, which will be slow for a site with many logged in users.
  • Use View Lite Pager to eliminate COUNT queries from being performed.
  • Consider alternate approaches to views, such as Apache Solr Faceted Search, which has much better performance than MySQL based solutions, because they do build an efficient index.

By implementing all the above for the client in question, except the last one, we were able to bring the view page from 2,730 milliseconds, down to 700-800 milliseconds of response time.

Scalability was much better, with the same server could handle more logged in users.

Contents: Tags: 

DrupalEasy: DrupalEasy Podcast 206 - Heather Rodriguez - Previewing the "Being Human" track at DrupalCon Nashville

26. Februar 2018 - 15:06

Direct .mp3 file download.

Heather Rodriguez, (hrodrig), Solutions Analyst for Digital Services Georgia and track chair for DrupalCon Nashville's "Being Human" track joins Mike Anello to talk about some of the sessions accepted for the track, why the track is important, and heavy metal music.

Interview Drupal News DrupalEasy News Sponsors
  • Drupal Aid - Drupal support and maintenance services. Get unlimited support, monthly maintenance, and unlimited small jobs starting at $99/mo.
  • WebEnabled.com - devPanel.
Follow us on Twitter Subscribe

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

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

Tim Millwood: Deprecation fails when testing Drupal 8

26. Februar 2018 - 10:57
Deprecation fails when testing Drupal 8

With each release of Drupal 8 more and more things are being deprecated, which is awesome. It shows innovation, forward thinking, and a thought for backwards compatibility. However throwing notices or warnings when deprecated code is used can cause tests to fail. We already counter this a little by adding to phpunit.xml.dist in core.

To quote the Symfony documentation:

By using the weak_vendors value, deprecations that are triggered outside the vendors directory will make the test suite fail, while deprecations triggered from a library inside it will not, giving you the best of both worlds.

This shows that deprecations within Drupal will still cause test fails, to combat that simply update the SYMFONY_DEPRECATIONS_HELPER setting to "weak" or "disabled", which would ignore the deprecations or disable the deprecation helper.

However if you're testing with run-test.sh this will interfere with the settings in your phpunit.xml file and use always use weak_vendors unless you have the suppress-deprecations argument set. Therefore use run-tests.sh --suppress-deprecations and the SYMFONY_DEPRECATIONS_HELPER setting will be set to "disabled". See the simpletest_script_run_one_test() function in run-tests.sh for more context.

Hopefully this helps, we found this really useful when testing Drupal modules with Travis, where we needed tests passing for Drupal 8.4 and 8.5.

timmillwood Mon, 26/02/2018 - 08:57 Tags drupal planet drupal-planet drupal drupal8 drupal 8 testing drupal testing Add new comment

Dries Buytaert: Posting my phone's battery status to my site

26. Februar 2018 - 3:56

Earlier this month, I uninstalled Facebook from my phone. I also made a commitment to own my own content and to share shorter notes on my site. Since then, I shared my POSSE plan and I already posted several shorter notes.

One thing that I like about Facebook and Twitter is how easy it is to share quick updates, especially from my phone. If I'm going to be serious about POSSE, having a good iOS application that removes friction from the publishing process is important.

I always wanted to learn some iOS development, so I decided to jump in and start building a basic iOS application to post notes and photos directly to my site. I've already made some progress; so far my iOS application shares the state of my phone battery at https://dri.es/status. This is what it looks like:

This was inspired by Aaron Parecki, who not only tracks his phone battery but also tracks his sleep, his health patterns and his diet. Talk about owning your own data and liking tacos!

Sharing the state of my phone's battery might sound silly but it's a first step towards being able to publish notes and photos from my phone. To post the state of my phone's battery on my Drupal site, my iOS application reads my battery status, wraps it in a JSON object and sends it to a new REST endpoint on my Drupal site. It took less than 100 lines of code to accomplish this. More importantly, it uses the same web services approach as posting notes and photos will.

In an unexpected turn of events (yes, unnecessary scope creep), I decided it would be neat to keep my status page up-to-date with real-time battery information. In good tradition, the scope creep ended up consuming most of my time. Sending periodic battery updates turned out to be difficult because when a user is not actively using an iOS application, iOS suspends the application. This means that the applications can't listen to battery events nor send data using web services. This makes sense: suspending the application helps improve battery life, and allows iOS to devote more system resources to the active application in the foreground.

The old Linux hacker in me wasn't going to be stopped though; I wanted my application to keep sending regular updates, even when it's not the active application. It turns out iOS makes a few exceptions and allows certain categories of applications – navigation, music and VOIP applications – to keep running in the background. For example, Waze continues to provide navigation instructions and Spotify will play music even when they are not the active application running in the foreground.

You guessed it; the solution was to turn my note-posting-turned-battery application into a navigation application. This requires the application to listen to location update events from my phone's GPS. Doing so prevents the application from being suspended. As a bonus, I can use my location information for future use cases such as geotagging posts.

This navigation hack works really well, but the bad news is that my application drains my phone battery rather quickly. The good news is that I can easily instruct Drupal to send me email notifications to remind me to charge my phone.

Scope creep aside, it's been fun to work with Drupal 8's built-in REST API and to learn some iOS application development. Now I can post my phone's battery on my site, posting notes or photos shouldn't be much more difficult. I'm guessing that a "minimum viable implementation" will require no more than another 100 lines of code and four hours of my time. My current thinking is to go ahead with that so I can start posting from my phone. That gives me more time to evaluate if I want to use the Micropub standard (probably) and the Indigenous iOS application (depends) instead of building and maintaining my own.

aleksip.net: Improving Drupal’s minor version upgrade experience

25. Februar 2018 - 20:43
Twice a year the new Drupal upgrade model makes me both excited about new features and worried about the possibility that the sites I maintain will break. I think there are some ways how the upgrade experience could be made better.

Spinning Code: Using Composer for Drupal Modules and Private Bitbucket Repos

25. Februar 2018 - 20:07

The next installment in my ongoing set of posts to create a public record for things I couldn’t learn in one Google search is a process for using composer to track a Drupal 8 module in a private repository.

It’s pretty common for Drupal agencies to have a small collection of modules they have built in-house and use on nearly all client site, or to have a module built for one client that has many sites. We are all becoming adept at managing our projects with Composer, but the vast majority of resources are focused on managing publicly available code via packagist. But there are times the kinds of internally shared modules cannot be made fully public (for example they may contain IP belonging to the client). We have one such client that needs a module deployed to dozens of sites, and so I sat down a few weeks ago to figure out a solution.

We use Bitbucket for our private repositories, I am sure there is a similar solution using GitHub, but I haven’t worked out its details.

  1. Create private repo for module on Bitbucket.
  2. Clone that repo locally, and structure it to match Drupal.org’s conventions (this probably isn’t required, but should allow your module to blend into the rest of the project more smoothly).
  3. Create Oauth token for your account in Bitbucket. Make sure to include a dumy callback URL; you can literally use http://www.example.com. If you see references to auth.json, don’t worry about that part yet.
  4. Add a composer.json file to the module’s repo (it only requires module name, type, and the branch alias, but it’s good to include the rest): { "name": "client/client_private_module", "type": "drupal-module", "description": "A very important module to our very important client.", "keywords": ["Drupal"], "homepage": "https://www.bitbucket.org/great_agency/client_private_module", "license": "proprietary", "minimum-stability": "dev", "extra": { "branch-alias": { "8.x-1.x": "1.x-dev" } }, "require": { "drupal/diff": "~1.0", } },
  5. Add reference to project composer.json repositories section: { "type": "package", "package": { "name": "client/client_private_module", "version": "dev", "type": "drupal-module", "dist": { "url": "https://www.bitbucket.org/great_agency/client_private_module/get/8.x-1.x.zip", "type": "zip" } } }
  6. Now just run composer require client/client_private_module, and provide the oauth creds from step 3 (note: the first time you do this composer will create the needed ~/.composer/auth.json)

Ryan Szrama: When Drupal friends become family

24. Februar 2018 - 22:31

Many of my longest friendships were born in the Drupal community. I’ve been attending DrupalCons, Drupal Camps, and other events since DrupalCon Barcelona 2007 and centered most of my professional life around contributing to the project as a developer and a teacher. In 2010 that included serving as a mentor in the Google Summer of Code program for a new contributor who wanted to work on Drupal Commerce’s affiliate module, bojanz.

Bojan Živanović and I got to know each other that summer through many IRC chats and coding sessions. After he completed his project successfully, we met at DrupalCon Copenhagen and celebrated at McDonald's. I sure knew how to treat a friend!

I later convinced him to join Commerce Guys’s development team based in Paris. He served on our client services team before diving head first into Commerce Kickstart 2.x development and then creating a whole suite of modules to support usage based billing for subscription services like Platform.sh.

Around DrupalCon Austin in 2014, it appeared Bojan's mission with Commerce Guys might be complete. However, I saw an opportunity for him to develop further as a leader in our company and community. I was already busy leading client services with our U.S. team and then with acquiring and refocusing Commerce Guys around Drupal Commerce. It made perfect sense to me to appoint him to be project lead for Commerce 2.x.

That decision has served Commerce Guys and Drupal Commerce well over the last several years. Bojan brought renewed vigor to the project and discipline around competitive research and automated test coverage that far exceeded my own. He's also proven to be an able mentor in his own right, helping dozens of contributors and whole agency teams learn Drupal 8 development in general and Commerce 2.x development in particular.

Today is Bojan's birthday, and reflecting on our almost 8 years of friendship has obviously made me sentimental. At our first meeting in Copenhagen, my daughter Éowyn was just taking her first steps and wouldn't ever remember meeting Bojan. Today she sees him regularly during company Zoom calls and his occasional visit to our home in Greenville, SC. He's not just some random person from daddy's work, he's Uncle Bojan and a trusted friend.

We're all wishing you a happy birthday, Bojan, and we're grateful for your years of contribution and leadership in our midst. I'll have to hit the 2.x queue this evening to send you a birthday present disguised as a patch.

Matt Grasmick: Stranger in a familiar land: Comparing the novice's first impression of Drupal to other PHP frameworks

23. Februar 2018 - 17:37

Drupal 8 adoption is flagging. Why? I tried to lay my biases and assumptions aside and set out to find the answer. What I found suprised me.

I decided to perform an experiment. Placing myself (as much as possible) in the shoes of a senior developer without any Drupal experience, I attempted to get a new "Hello World" site up and running in four different PHP frameworks: Wordpress, Laravel, Symfony, and Drupal.

I set a few ground rules for myself:

  • Start at square 1. Google "Drupal" (or Wordpress, etc.).
  • Use only information found organically via my Google search and subsequent clicks.
  • Take the path of least resistance. In other words, choose the easy way when more than one option exists.
  • Avoid the command line when possible.
Measurements:
  • Time required.
  • Number of clicks in web browser.
  • Number of CLI commands run.

I do not claim that this…

more

Dries Buytaert: A Drupal distribution configurator

23. Februar 2018 - 0:11

Today, Commerce Guys shared a new initiative for Drupal Commerce. They launched a "Drupal Commerce distribution configurator": a web-based UI that generates a composer.json file to build a version of Drupal Commerce that is tailored to an evaluator's needs. The ability to visually configure your own distribution or demo is appealing. I like the idea of a distribution configurator for at least three reasons: (1) its development could lead to improvements to Drupal's Composer-based workflow, which would benefit all of Drupal, (2) it could help make distributions easier to build and maintain, which is something I'm passionate about, and last but not least, (3) it could grow into a more polished Drupal evaluator tool.

OSTraining: How to Use the New Media Module Features in Drupal

22. Februar 2018 - 22:35

Since the release of Drupal 8.4 in late 2017, Drupal has contained new media handling features.

For many years, Drupal has shipped with almost no media handling. This was the most commonly requested feature whenever we did Drupal training.

In this tutorial, we'll walk you through how to use Drupal's new media options. We'll update this post as soon as Drupal 8.5 is available.

Elevated Third: WATCH E3 Takeaways: Drupal 8 Works for SaaS

22. Februar 2018 - 21:29
WATCH E3 Takeaways: Drupal 8 Works for SaaS WATCH E3 Takeaways: Drupal 8 Works for SaaS Zach Ettelman Thu, 02/22/2018 - 12:29

In this edition of E3 Takeaways Business Development Strategist, Zach, talks Drupal 8 and why its flexible workflows, ability to integrate, and internationalization suite of modules work so well for the SaaS industry.

 

 

Hello there, I'm Zach Ettelman, Business Development Strategist here at Elevated Third. Today I'm going to talk about why Drupal is a good fit for software as a service companies. 

 

Takeaway #1: The old adage "content is king" is not dead and that means companies are still having to create a ton of content. With so many content cooks in the kitchen that means there are many approval layers to even get the smallest piece of content onto your site. Thanks to Drupal's content authorization workflow, we can personalize and customize it to meet the needs of your team. 

 

Takeaway #2: In today's digital world, virtually every SaaS organization is serving an international audience. Thanks to Drupal 8's internationalization suite of modules, we can now translate and localize content based on where the product's services are available for your offerings. 

 

Takeaway #3: SaaS companies leverage a multitude of tools in their digital arsenal to get daily business operations done, including CRM, marketing automation tools, and inventory management tools. Drupal 8 specifically is built API first making it easy to handle all these third-party integrations. Thanks to contributed modules and custom modules, we can keep up with your daily business operations and connect them to your digital website. 

Need more about Drupal 8? Download our D8 whitepaper. 

Download asset

Hook 42: January Accessibility (A11Y) Talks

22. Februar 2018 - 20:42

In January, we were happy to have Ashley Bischoff as our guest speaker. Ashley talked about embracing plain language for better accessibility. Ashley is an accessibility expert and copy editor for The Paciello Group.

Writing reports and documentation is nothing new for many of us — we write them all the time. But even though we may do our best to write clearly, those who receive our reports and documentation might not be as familiar with accessibility as we are.

At the end of the day, no matter how technically correct a document may be, our words won't do much good if those who are reading them can't understand what we're trying to say. But writing isn't a black box — there are straightforward techniques that we can use to help ensure that our writing remains accessible.

 

OSTraining: Check Out the New Page Builder in Drupal 8.5!

22. Februar 2018 - 20:42

The Release Candiate version of Drupal 8.5 was released today.

At this point we can see the final features that will be in the official release of 8.5 on March 7.

In this blog post, I'll give you an introduction to 3 of the main new features you can look forward to in 8.5.

This is "Day 1" post giving my quick reactions. We'll improve and expand on this post in the days before the final release.

Drupal blog: Drupal 8.5.0-rc1 is available for testing

22. Februar 2018 - 20:28

The first release candidate for the upcoming Drupal 8.5.0 release is now available for testing. Drupal 8.5.0 is expected to be released March 7.

Download Drupal-8.5.0-rc1

8.5.x makes the Media module available for all, improves migrations significantly, stabilizes the Content Moderation and Settings Tray modules, serves dynamic pages faster with BigPipe enabled by default, and introduces the new experimental Layout Builder module. The release includes several very important fixes for workflows of content translations and supports PHP 7.2. Finally, 8.5.0-rc1 also includes the same security updates that are provided in 8.4.5.

What does this mean to me? For Drupal 8 site owners

Drupal 8.4.5, a security update and the final release of the 8.4.x series, has also been released this week. 8.4.x sites should update immediately to 8.4.5, but going forward, 8.4.x will receive no further releases following 8.5.0, and sites should prepare to update from 8.4.x to 8.5.x in order to continue getting bug and security fixes. Use update.php to update your 8.4.x sites to the 8.5.x series, just as you would to update from (e.g.) 8.4.2 to 8.4.3. You can use this release candidate to test the update. (Always back up your data before updating sites, and do not test updates in production.)

If you're an early tester who is already running 8.5.0-alpha1 or 8.5.0-beta1, you should update to 8.5.0-rc1 immediately. 8.5.0-rc1 includes security fixes (the same fixes that were released in Drupal 8.4.5).

Site owners should also take note of the fact that Drupal 8's support for PHP 5 will end in one year, in March 2019. PHP 7.2 is now the best recommended PHP version to use with Drupal 8.

For module and theme authors

Drupal 8.5.x is backwards-compatible with 8.4.x. However, it does include internal API changes and API changes to experimental modules, so some minor updates may be required. Review the change records for 8.5.x, and test modules and themes with the release candidate now.

For translators

Some text changes were made since Drupal 8.4.0. Localize.drupal.org automatically offers these new and modified strings for translation. Strings are frozen with the release candidate, so translators can now update translations.

For core developers

All outstanding issues filed against 8.4.x were automatically migrated to 8.5.x. Future bug reports should be targeted against the 8.5.x branch. 8.6.x will remain open for new development during the 8.5.x release candidate phase. The 8.5.x branch will be subject to release candidate restrictions, with only critical fixes and certain other limited changes allowed.

Your bug reports help make Drupal better!

Release candidates are a chance to identify bugs for the upcoming release, so help us by searching the issue queue for any bugs you find, and filing a new issue if your bug has not been reported yet.

Aten Design Group: Capturing Webhooks in Drupal 8

22. Februar 2018 - 18:45

When using traditional APIs your application is typically requesting or pulling data from an external service, requiring a request for fresh data if you want to see recent changes. When using webhooks, that process is reversed: data is pushed from an external service in real-time keeping your application more up to date and your project running more efficiently. Here are a few examples:

  • Facebook - Receive an alert anytime a message is read
  • Stripe - Get alerted anytime a transaction comes through
  • Eventbrite - Get alerted if an event is created or updated

This of course is not an exhaustive list; you'll need to check the application you are integrating with to see if they are implementing webhooks. A Google search like "Stripe Webhooks" is a good first step.

Implementing a webhook in your application requires defining a URL to which your webhook can push data. Once defined, the URL is added to the application providing the webhook. In Drupal 8, controllers are a straightforward way to define a path. See the complete code for an example.

When the webhook is fired it hits the defined URL with applicable data. The data that comes from a webhook is called the payload. The payload is often a JSON object, but be sure to check the application’s documentation to see exactly what you should be expecting. Capturing the payload is straightforward using the Request object available in a controller like this:

public function capture(Request $request) { $payload = $request->getContent(); }

If your payload is empty, you can always try some vanilla PHP:

$payload = file_get_contents("php://input"); Inspecting the Payload

Debugging webhooks can be a bit challenging if you are developing locally because your local environment typically does not have a public URL. Further, some webhooks require that the receiving URL implement SSL, which can also present challenges locally. The following options can help you navigate debugging webhooks locally.

Easiest

When capturing the payload, you can log it in Drupal. This option requires pushing your code up to a publicly available URL (a dev or staging environment).

$this->logger->debug('<pre>@payload</pre>', ['@payload' => $payload]);

Once you know what the payload looks like, you can copy it, modify it and make your own fake webhook calls locally using Postman. Feel free to checkout the importable Postman example in the repo.

Most Flexible

There is a utility called ngrok that allows you to expose your local environment with a publicly available URL; if you anticipate a lot of debugging it is probably worth the time to set up. Once ngrok is in place, you use the same logging method as above or use XDEBUG or something similar to inspect the payload. Ngrok will give you a unique, public URL which you can register, but which forwards to a server you have running on localhost. You can even use it with a local server that uses vhosts, such as yoursite.test with the command:

ngrok http -host-header=rewrite yoursite.test:80 Capturing and Processing the Payload

I'm a big fan of Drupal's queue system. It allows quick storage of just about anything (including JSON objects) and a defined way to process it later on a CRON run.

In your controller, when the payload comes in, immediately add the payload to your defined queue rather than processing it right away. This will make sure it is always running as efficiently as possible. You can of course process it right away if you choose to do so and skip the rest of this post.

$this->queue->createItem($payload);

Later when the queue runs, you can process the payload and do what you need to do, like create a node. Here is an example from the queue plugin (see ProcessPayloadQueueWorker.php for the full code):

public function processItem($data) { // Decode the JSON that was captured. $decode = Json::decode($data); // Pull out applicable values. // You may want to do more validation! $nodeValues = [ 'type' => 'machine_name_here', 'status' => 1, 'title' => $decode['title'], 'field_custom_field' => $decode['something'], ];   // Create a node. $storage = $this->entityTypeManager->getStorage('node'); $node = $storage->create($nodeValues); $node->save(); }

Once a queue is processed on CRON, the item is removed from the queue. Check out Queue UI module for easy debugging.

Security

As when building any web application, security should be a major consideration. While not an exhaustive list, here are a few things you can do to help make sure your webhook stays secure.

  • Check your service's webhook documentation to see what authentication protocols they provide.
  • Create your own token that only your application and the webhook service know about. If that is not included, do not accept the request. See the authorize method in the controller.
  • Instead of processing the payload and turning it into a node, consider doing an API call back to the service using the ID from payload and requesting the data to ensure its authenticity.
  • You should consider sanitizing content coming from the payload.

Once you implement a Webhook, you'll be hooked! Here's all the code packaged up.

There are of course Drupal contrib modules around webhooks. I encourage you to check them out, but if you have specific use cases or complex needs, rolling your own is probably the way to go.

Commerce Guys: What's the plan for Commerce Kickstart on Drupal 8?

22. Februar 2018 - 10:28

When Commerce Guys raised $5m in 2012 to grow Drupal Commerce and its ecosystem, we invested a big chunk of it in improving our user experience for both customers and administrators. With competing platforms like Shopify and Magento really coming into their own, we knew it was essential to provide a solid out-of-the-box experience. While Drupal Commerce was and is truly unique as an eCommerce framework natively extending and deeply integrated into a CMS, it turns out "flexibility" doesn't pitch nearly as well as a polished demo.

Investing in Drupal Commerce adoption

The product we developed to address that need is Commerce Kickstart, by far the most popular Drupal distribution ever built. I named it such to underscore the fact that we intended it to be an accelerator, both for Drupal Commerce's own adoption but also for newcomers wondering how to demo and develop with the software. At its height, we supported over 13,000 sites reporting in to drupal.org, and we continue to see new sites launch with it to this day.

Building the distribution proved to be a fantastic learning experience. The project drove improvements that worked their way into many contributed modules and Drupal core itself (e.g. contributions to Views, VBO, Entity Reference, Inline Entity Form). Its broad appeal also gave us a platform to invite Technology Partners to invest in the community in a way that Drupal hadn't seen before, many of whom continue to invest in Drupal today (e.g. Authorize.Net, PayPal, Avalara).

It was a ton of work, but Bojan, Jonathan, and their team accomplished everything we set out to do and more. With the release of Commerce 2.0 last fall, we now find ourselves regularly fielding the question, "What's the plan for Commerce Kickstart on Drupal 8?" The reality is, porting Commerce Kickstart as it is to Drupal 8 would be both too costly for our team today and a poor strategy for the way the Drupal market is developing. We're doing something new again.

Accelerating adoption today

Another frequent question we field is, "Why does Drupal Commerce require Composer?" Composer is often highlighted as a barrier to Drupal 8 adoption, and I can understand why. I always felt the same way about drush. I had a UI; why did I need a CLI? I had my process and never had to battle the command line to make sure drush worked, was up to date, and did what I expected. I always felt that way ... until I buckled down and learned it. Now I can't imagine using Drupal without it.

I felt the same about Composer at first, but I was determined to learn how to use it as I learned Drupal 8 and modern PHP in general. I know I'm not the only person suffering from tool fatigue (cf. Dries ; ), so we're doing what we can to help you ease into using Composer on your own terms.

We started by releasing Ludwig last summer, a Drupal project that lets you manage Composer dependencies similarly to the familiar Libraries module. We also expanded and documented a Composer project template that lets you create a new Commerce 2.x site with composer create-project, and we then began planning how to let users customize a project template via the browser while prototyping a GUI for Composer.

With today's release of the new CommerceKickstart.com, developed in partnership with Acro Media (thanks to Shawn McCabe, Mike Hubbard, et al), we're taking the next step!

Commerce Kickstart for Drupal 8

What you'll find there is that Commerce Kickstart has been reimagined for Drupal 8 rather than rebuilt on Drupal 8. The quickest way to get up and running with Drupal Commerce today is not through a distribution as it was 6 years ago, it's through Composer. This is the tool for modern PHP developers, and we see prioritizing Composer while also making it simpler to use as essential to growing Drupal Commerce adoption both from without and within the Drupal community.

While still in its infancy, CommerceKickstart.com presents a form that lets you construct a Composer JSON file ready-made to support Commerce 2.x and the contributed modules you specify. Module categories include payment and shipping providers, product catalog and search tools, data migration, and more. As with Commerce Kickstart 2.x, it features Technology Partners whose modules we have integrated into Commerce 2.x, and we expect the selection to continue expand.

Future plans for the tool include clarifying and improving the tool's usability, adding additional modules and Technology Partners, and evolving it to continue to lower the barrier to entry for new Composer users. If you give it a whirl, we'd love to hear your ideas as well in the Commerce Kickstart issue queue.

Appnovation Technologies: Simple website approach using a Headless CMS: Part 3

22. Februar 2018 - 10:00
Simple website approach using a Headless CMS: Part 3 This is the last post of my quick Headless journey, in the first one I approached the concept of Headless and presented some solutions like Drupal, GraphCMS, Contentful and Cockpit CMS. In the second one, I extended those concepts by detailing Cockpit CMS, mostly due to the simplicity of the admin interface and the way that we de...

Roy Scholten: Idea: a data & content modelling UX sprint

22. Februar 2018 - 3:19
22 Feb 2018 Idea: a data & content modelling UX sprint

During this weeks UX meeting we explored what it would mean to redesign the core Field UI. It’s definately in need of an update.

Currently all mashed together in a couple of tabs on Field UI:

  • Data modelling – Define data types and storage formats for individual fields & their relationships
  • Content modelling – Compiling individual fields into appropriate content (entity) types and configuring the input form for creating content items
  • Display modelling – Configuring different ways to display these created content items

One of the first steps towards a new and improved user interface for Field UI would be to unbraid these different types of tasks. Take it apart and put it together again in more user friendly ways.

Would be nice to kick this off with some kind of (virtual) UX design sprint, no?

Tags Drupal content modeling drupalplanet