Inhalt abgleichen
Drupal.org - aggregated feeds in category Planet Drupal
Aktualisiert: vor 1 Minute 36 Sekunden

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

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.