Inhalt abgleichen
Drupal.org - aggregated feeds in category Planet Drupal
Aktualisiert: vor 9 Stunden 11 Minuten

Dries Buytaert: Drupal helps rescue ultra marathon runner

vor 14 Stunden 38 Minuten

I'm frequently sent examples of how Drupal has changed the lives of developers, business owners and end users. Recently, I received a very different story of how Drupal had helped in a rescue operation that saved a man's life.

The Snowdonia Ultra Marathon website

In early 2018, Race Director Mike Jones was looking to build a new website for the Ultra-Trail Snowdonia ultra marathon. He reached out to a good friend and developer, Rob Edwards, to lead the development of the website.

© Ultra-trail Snowdonia and No Limits Photography

Rob chose Drupal for its flexibility and extensibility. As an organization supported heavily by volunteers, open source also fit the Snowdonia team's belief in community.

The resulting website, https://apexrunning.co/, included a custom-built timing module. This module allowed volunteers to register each runner and their time at every aid stop.

A runner goes missing

Rob attended the first day of Ultra-Trail Snowdonia to ensure the website ran smoothly. He also monitored the runners at the end of the race to certify they were all accounted for.

Monitoring the system into the early hours of the morning, Rob noticed one runner, after successfully completing checkpoints one and two, hadn't passed through the third checkpoint.

© Ultra-trail Snowdonia and No Limits Photography

Each runner carried a mobile phone with them for emergencies. Mike attempted to make contact with the runner via phone to ensure he was safe. However, this specific area was known for its poor signal and the connection was too weak to get through.

After some more time eagerly watching the live updates, it was clear the runner hadn't reached checkpoint four and more likely hadn't ever made it past checkpoint three. The Ogwen Mountain Rescue were called to action.

Due to the terrain and temperature, searching for the lost runner on foot would be too slow. Instead, the mountain rescue volunteers used a helicopter to scan the area and locate the runner.

How Drupal came to rescue

The area covered by runners in an ultra marathon like this one is vast. The custom-built timing module helped rescuers narrow down the search area; they knew the runner passed the second checkpoint but never made it to the third.

After following the fluorescent orange markers in the area pinpointed by the Drupal website, the team quickly found the individual. He had fallen and become too injured to carry on. A mild case of hypothermia had set in. The runner was airlifted to the hospital for appropriate care. The good news: the runner survived.

Without Drupal, it might have taken much longer to notify anyone that a runner had gone missing, and there would have been no way to tell when he had dropped off.

NFC and GPS devices are now being explored for these ultra marathon runners to carry with them to provide location data as an extra safety precaution. The Drupal system will be used alongside these devices for more accurate time readings, and Rob is looking into an API to pull this additional data into the Drupal website.

Stories about Drupal having an impact on organizations and individuals, or even helping out in emergencies, drive my sense of purpose. Feel free to keep sending them my way!

Special thanks to Rob Edwards, Poppy Heap (CTI Digital) and Paul Johnson (CTI Digital) for their help with this blog post.

Lullabot: Why Programmers Should Read Good Fiction

6. Februar 2019 - 23:17

If you are a programmer looking to improve your professional craft, there are many resources toward which you will be tempted to turn. Books and classes on programming languages, design patterns, performance, testing, and algorithms are some obvious places to look. Many are worth your time and investment.

Agaric Collective: Pass variables without escaping nor sanitizing to t() in Drupal 8

6. Februar 2019 - 19:12

In Drupal 7 it was useful to do things like this: 

function mymodule_content() { $links[] = l('Google', 'http://www.google.com'); $links[] = l('Yahoo', 'http://www.yahoo.com'); return t('Links: !types', array('!types' => implode(', ', $links))); }

In this case, we are using the exclamation mark to pass the $links into our string but unfortunately, Drupal 8 doesn't have this option in the FormattableMarkup::placeholderFormat(), the good news is that even without this there is a way to accomplish the same thing. 

Read more and discuss at agaric.coop.

Mass.gov Digital Services: Introducing Drupal Test Traits

6. Februar 2019 - 16:34
Mass.gov dev team releases open source project

The Mass.gov development team is proud to release a new open source project, Drupal Test Traits (DTT). DTT enables you to run PHPUnit tests against your Drupal web site, without wiping your database after each test class. That is, you test with your usual content-filled database, not an empty one. We hope lots of Drupal sites will use DTT and contribute back their improvements. Thanks to PreviousNext and Phase2 for being early adopters.

Mass.gov is a large, content-centric site. Most of our tests click around and assert that content is laid out properly, the corresponding icons are showing, etc. In order to best verify this, we need the Mass.gov database; testing on an empty site won’t suffice. The traditional tool for testing a site using an existing database is Behat. So we used Behat for over a year and found it getting more and more awkward. Behat is great for facilitating conversations between business managers and developers. Those are useful conversations, but many organizations are like ours — we don’t write product specs in Gherkin. In fact, we don’t do anything in Gherkin beside Behat.

Meanwhile, the test framework inside Drupal core improved a lot in the last couple of years (mea culpa). Before Drupal Test Traits, this framework was impossible to use without wiping the site’s database after each test. DTT lets you keep your database and still test using the features of Drupal’s BrowserTestBase and friends. See DrupalTrait::setUp() for details (the bootstrap is inspired by Drush, a different open source project that I maintain).

Zakim Bridge at Night, North End Boston. Photo by David Fox.Using DTT in a Testhttps://medium.com/media/cbe46617878edbc55bbf67c573fbc46a/href
  • Our test cases extend ExistingSiteBase, a convenience class from DTT that imports all the test traits. We will eventually create our own base class and import the traits there.
  • Notice calls to $this->createNode(). This convenience method wraps Drupal’s method of the same name. DTT deletes each created node during tearDown().
  • Note how we call Vocabulary::load(). This is an important point — the full Drupal and Mink APIs are available during a test. The abstraction of Behat is happily removed. Writing test classes more resembles writing module code.
More Featureshttps://medium.com/media/7c921cc06be32c3b0944aef1d597e853/hrefMisc
  • See the DTT repo for details on how to install and run tests
  • Typically, one does not run tests against a live web site. Tests can fail and leave sites in a “dirty” state so it’s helpful to occasionally refresh to a pristine database.

If you have questions or comments about DTT, please comment below or submit issues/PRs in our repository.

More from Moshe: Our modern development environment at Mass.gov

Interested in a career in civic tech? Find job openings at Digital Services.
Follow us on Twitter | Collaborate with us on GitHub | Visit our site

Introducing Drupal Test Traits was originally published in MA Digital Services on Medium, where people are continuing the conversation by highlighting and responding to this story.

DrupalCon News: How to become a DrupalCon Mentor

6. Februar 2019 - 14:35

The backbone of every DrupalCon is the community of people who come together at the event, and in particular the involvement of community volunteers who collectively influence and shape the experiences of others in attendance. In short, Mentors!  

 

OPTASY: How to Send Richly Formatted HTML Emails in Drupal 8: Deliver the Experiences that Your Customers Expect in 2019

6. Februar 2019 - 14:07
How to Send Richly Formatted HTML Emails in Drupal 8: Deliver the Experiences that Your Customers Expect in 2019 adriana.cacoveanu Wed, 02/06/2019 - 12:07

API first, responsive Bartik, headless and decoupled Drupal, Layout Builder, React admin UI... Drupal's evolved tremendously over these 18 years! Yet: the emails that we send out via its otherwise robust email sending system aren't different from those we used to send a... decade ago. And customers expect rich experiences outside your Drupal website or app. While website administrators expect to be enabled to easily manage, via the admin UI, their email content templates. So: how do you send HTML emails in Drupal 8?

Without relying on external services, of course...

And who could blame customers for expecting 2019-specific user experiences? Experiences that HTML-enabled emails deliver through their great features.

Commerce Guys: Eliminating barriers to Drupal Commerce growth

6. Februar 2019 - 3:52

At the end of 2018, Dries Buytaert, creator of Drupal, asked folks involved with the project to share their thoughts on what's "holding Drupal back." His prompt came on the heels of two great blog posts related to his company Acquia's growth strategy and lessons he's learned and applied from Amazon's growth strategy. I didn’t beat his third post on overcoming Drupal’s obstacles to the punch, but the series did prompt me to think long and hard about the barriers we face as maintainers and leaders of the Commerce project within the Drupal ecosystem.

For the entirety of our existence, Commerce Guys has focused on building and promoting Drupal as an eCommerce platform, first through Ubercart and then Drupal Commerce. While eCommerce is a huge industry, our reach within the community has only averaged around 5% of all Drupal sites. Given the diverse and varied types of users Drupal serves, I consider this relatively low number unsurprising. (A certain percentage will also choose to integrate third party shopping cart systems, but historically that’s always been a fraction of the number of Drupal sites using our native solutions.)

It’s tempting to be fatalistic about Drupal Commerce’s growth and accept that our growth rate will be pegged to Drupal’s own growth rate so long as our relative percentage holds. It actually is an important baseline to acknowledge - our success is tied to Drupal’s success, and so we prioritize contributing to initiatives that help improve Drupal’s core APIs, make it easier to maintain and upgrade, and attract new audiences through API-first / JavaScript initiatives. However, I think we can and should do better than just waiting for growth to happen upon us.

Why should I think we can do better?

After Dries’s posts last year I compared our usage statistics for Commerce 2.x (on Drupal 8) to our usage statistics for Commerce 1.x (on Drupal 7) at the same point in its life-cycle. What I saw convinced me we have plenty of room to grow:

  • In 2013, Drupal Commerce 1.x grew from 23,224 to 33,989 sites.
  • These numbers represent growing from 4.02% to 4.50% of all Drupal 7 sites.
  • Our average growth rate that year was 3.89% month over month; Drupal’s own growth rate was 2.72%.
  • In 2018, Drupal Commerce 2.x grew from 3,097 to 6,980 sites.
  • These numbers represent growing from 1.41% to 2.85% of all Drupal 8 sites.
  • Our average growth rate last year was 8.65% month over month; Drupal’s own growth rate was 1.23%.

Just based on those numbers, even though Commerce 2.x grew over twice as fast last year as Commerce 1.x did in a similar timeframe in its life-cycle, we still represent only half of the relative number of Drupal sites we did back then. We can double our user base on Drupal 8 without challenging our historical average representation at all. That’s good news!

Our growth rate right now is fantastic, especially compared to Drupal's own. There are likely a variety of factors at play here, but I think it boils down to some combination of recognized maturity, excellent word of mouth from a steady stream of case studies, and our contributed module ecosystem stabilizing to a point that Drupal 7 / Commerce 1.x sites are finally porting to Drupal 8 / Commerce 2.x. As our 2.x project lead recently observed, we’re now up to over 250 contributed modules on drupal.org and maintain a community support Slack channel with over 1,000 participants.

Eliminating barriers to growth in 2019

In order for us to keep up and even accelerate our rate of growth, Commerce Guys has been working hard to identify our barriers to growth and develop solutions to them. As a small team playing in a large market (against very well-funded competitors), we can only do so much … but every bit of progress on any of the following fronts will help.

1. Features and integrations

The biggest barrier to growth has historically been our under-developed contributed module and integration ecosystem. Ecosystem development is incredibly important - agencies don’t often have the expertise or confidence to develop new features or integrations themselves. Our major competitors (Magento, Shopify, et al) all have massive ecosystems that third-party software vendors take the initiative to join while our own ecosystem remains dependent on our own team or the core of our development community to expand.

2. Developer support and education

It’s tempting to point to performance and scalability as another barrier to growth, but we see poorly performing Drupal Commerce sites as a symptom of another issue - lack of exposure by the average Drupal developer to best practices for scaling sites with a large amount of authenticated (or otherwise cache-breaking) traffic. We know that we can scale Drupal Commerce to support 10,000+ transactions per hour and thousands of concurrent users, but we also know that otherwise capable Drupal teams struggle at a fraction of that scale. In other words, it’s not a capabilities gap, it’s a knowledge gap, and we’re to blame for not sharing what we've learned with our userbase.

3. Reaching our core audience

Finally, we’re hardly communicating to the market at all about why they should be choosing Drupal Commerce. Our websites are aging, and organizations who do decide upon Drupal are often confused about what sort of support, if any, we might offer them if they choose to adopt our software. We understand how our solution differs from other major players in the market and where it should be seriously evaluated (e.g. cross-border commerce, digital product sales, subscription billing), but we aren’t doing enough to demonstrate our capabilities or provide a vision for why merchants will be better off using Drupal Commerce than a competing application.

We certainly have our work cut out for us in 2019, but we’re encouraged by last year’s growth and the support of our friends and champions within the Drupal community. We believe we can work to eliminate these barriers to growth while building a sustainable business that allows us to grow without compromising our values. In reverse order, the basic roadmap we’re targeting to address those known-blockers above will be:

  1. Relaunch our company and project websites to more clearly communicate who we are, what our software can do, and how we support eCommerce teams to build with confidence on Drupal.
  2. Standardize our consulting efforts and support retainers into concrete, documented offerings that anyone can understand.
  3. Coordinate our development roadmap with more agency and technology partners to ensure essential contributed modules receive the attention they deserve and our integration roster continues to grow.

We'll be encoding our expertise into productized solutions that allow us to grow a team focused on ensuring eCommerce sites built with Drupal are optimized for stability, security, and scalability. We've always valued the impact we have on the Drupal community even as a small team, and we believe addressing these issues will afford us the opportunity to grow, broaden our impact, and grow Drupal itself as a result.

Jacob Rockowitz: Webform 8.x-5.x stable release plan

5. Februar 2019 - 17:38

Looking back

Three years ago on Christmas day, I tagged the first alpha of the YAML Form module, which became the Webform module for Drupal 8. Looking back, it has been a great learning experience building and maintaining the Webform module. Looking forward, I want to make sure the Webform module is as stable as possible while still trying to smooth out any rough edges around accessibility and user experience. Everyone should feel that the Webform module is a stable, supported, and maintained part of Drupal's ecosystem of contributed modules. To help organizations and individuals understand what to expect from a stable release of the Webform module, it’s worth defining some general goals.

Setting goals

The goals of this blog post and the overall stability of the Webform module are to…

  • Define the ongoing stable release cycle.

  • Document what to expect from stable releases.

  • Encourage the growth of Webform add-ons and integrations.

Tagging releases

For the past three years, I've been tagging a new release at the beginning of each month. Frequently monthly releases were quickly followed up with a hotfix release to address unexpected regressions. Regressions happen because the Webform module is a feature-rich application with maybe not enough test coverage and definitely not enough eyeballs reviewing the code. Quality assurance is a challenge for open source projects; reviewing code for free is not as much fun as writing it. Even Drupal core needs help with improving the reliability of minor updates.

For example, Webform 8.x-5.1 was released at the...Read More

ComputerMinds.co.uk: A/B Testing with ABJS module

5. Februar 2019 - 15:00

ABJS is a contrib Drupal module, and, without any requirements or ties to paid services, is as low cost as you can get. As we’ll see, it’s pretty basic but it really lets you get down to building your own understanding of how A/B testing works. The beauty of ABJS is in its simplicity. The settings pages are fairly self-explanatory, which is really helpful. Let’s set up a basic A/B test to show how things work.

Setting up our first experience

In our test, we’re going to split the site 50:50 in order to test an alternate homepage design. Go to /admin/config/user-interface/abjs and get a feel for things. See the tabs across the top? The best way to set up a new test is to work backwards. That’s because your Tests will need to reference your Conditions and Experiences - and you’ll need to create them before you can use them.

First up, create an Experience. Experiences make the actual A’s and B’s of your A/B tests. Go to the Experiences tab. Give your experience a very clear and helpful name. Our first one will be our normal homepage experience. Making a ‘normal’ experience allows us to explicitly log our page views for our analytics.

The Javascript we set up for our site looks like this:

if (typeof(ga) !== "undefined") { ga('set', 'dimension1', 'normal'); } window.Drupal = window.Drupal || { 'settings': {}, 'behaviors': {}, 'locale': {} }; window.Drupal.behaviors.abtesting = { attach: function(context, settings) { jQuery('#request-a-quote-form').on('submit', function() { ga('send', 'event','Productfinder', 'ID search', 'Homepage'); }); } }

1. We came to the Drupal Behavior format after realising that the ABJS scripts in the header would run before the Google Analytics scripts, and we would need the GA script to run before we could log our analytics. You could probably do this another way if you wanted, but this is easy enough to copy and paste for now.

2. Set our custom GA dimension.

3. This ends up happening before Drupal is actually ready to accept and execute behaviors, hence the very careful creation/copy of the window.Drupal variable.

4. Add a submit handler to our form, which will send an event to GA. This is the thing we’re trying to measure. Hopefully our alternate version of the page will result in more clicks on this button, and we’ll be able to track those in GA.

If you copy & paste the above, you'll want to make your tweaks:

1. Change the first call to ga() in line 2 to be a dimension you’ve set up in Google Analytics (Go do that now! Their support articles are really good, so I won’t explain that here).

2. Set the value for that call to be the value you want (‘normal’ may well be fine).

3. Change the event values in the final call to ga() to send the event values you want or need. They don’t need to be fancy, just unique - you just need to be able to track them in GA. Now, go create an “Alternate homepage experience” experience.

Set up your Alternate Experience

This is the Experience for the change / difference you're wanting to test.

Copy the JS from your ‘Normal’ experience, and tweak it to:

1. Have a different value for your GA dimension

2. Make an actual change to your page. Put this after the jQuery/ga call.

Now go create your condition(s).

All your experience Javascript will be added to every page, so this is where you make sure that you’re only running things where and when you really want to. Again, you write up some Javascript; it will return a Boolean value indicating to ABJS whether you want your test to be run. In our example, we’re just testing the homepage. So we’ll just do this:

return (window.location.pathname == "/");

Don't forget to set a helpful and clear name for your Condition, so it's easy to select later.


Test time!

At last, you can now go set up your Test.

1. Give your test a name. Make it helpful, so that you know which test does what when you have multiple tests later :) Perhaps name it after the change you’re making in your alternate test.

2. Select your two experiences in the two select boxes. Don’t let the fraction field confuse you - this is just the proportion of people you want to be diverted to each of your two experiences. This can be super helpful if you want, for example, to test something on a small proportion of users. For us doing our small, low-cost A/B test on our small client’s site, we want to maximise our data. So we’re doing 50:50 - this means fractions of 0.5 and 0.5 You can have multiple experiences here, which is pretty neat. So if you want to test multiple variations of your homepage, you can! Go for it!

3. Double check your Javascript :) Go execute it in the browser console or something, to make sure it works. No point taking your site down accidentally!

4. Set your test to 'Active'! This will add your tests to the site, so you can start collecting data! Now is the time to go to Google Analytics and watch the data pour in (for some definition of pour, depending on how busy your site is right now!).


Analysing your data

A key thing to remember when watching your analytics is that things change all the time, and sometimes randomness can be responsible for what you’re seeing. Or maybe there was a seasonal spike in sales which increased revenue that week, or maybe you’re not filtering your users to the right segment… A few recommendations for you:

  • Create segments for your two dimension values, so you can easily filter your data.
  • Data can be misleading. Always check other angles before declaring you’ve fixed the problem.
  • Run your numbers to check the Statistical Significance. If you don’t have tens of thousands of samples, your results may just be random chatter rather than necessarily related to the changes your Experience made. Either remember your A-Level statistics, or go use an online calculator. I recommend https://measuringu.com/statistically-significant/ for a good explainer.
  • If your site is not high traffic, you may need to run your tests for weeks or even months to get enough data to clearly show whether there's a difference. Or, it may be worth deciding that there's not clearly a difference, so it's worth testing something else.
     

     

So, we’ve created some tests with ABJS. How did it go?

Overall, ABJS is nice because it feels like you’re in control. And all developers like to feel in control. It’s also nice because if you want to go set up a test, you can! It’s easy!

Where ABJS loses out is in the pile of lovely features that the big products out there can offer. Creating, managing, scheduling and analysing are all tasks that have been made a lot easier by some off-the-shelf products. But if you can’t afford that budget, or really rather enjoy thinking things through (or indeed love a bit of statistics!) then this is your lot - and it works well enough.

Later on in the series we'll be playing with Google Analytics' A/B testing suite and seeing how it compares. Stay tuned!

CTI Digital: How do you start contributing to Drupal without code?

5. Februar 2019 - 12:27

Outlets for contributing to Drupal beyond code, whilst abundant, are not always evident to those having interest to do so. I want to help people become better acquainted with ways to get involved and how to start their contribution journey. Be they completely new to Drupal or simply yet to find an outlet.

Agiledrop.com Blog: Top Drupal blog posts from January 2019

5. Februar 2019 - 10:25

Just like every month, we’ve prepared a selection of the most interesting and engaging Drupal-related blog posts from the previous month. Check out January’s list and make sure you haven’t missed any!

READ MORE

Spinning Code: SCDUG November 2018

4. Februar 2019 - 15:00

This fall the South Carolina Drupal User’s Group started using Zoom are part of all our meetings. Sometimes the technology has worked better than others, but when it works in our favor we are recording the presentations and sharing them when we can.

In November Kaylan Wagner gave a draft talk on using experiences in the world of online gaming to be a better remote team member.

We frequently use these presentations to practice new presentations and test out new ideas. If you want to see a polished version hunt group members out at camps and cons. So if some of the content of these videos seems a bit rough please understand we are all learning all the time and we are open to constructive feedback.

If you would like to join us please check out our up coming events on Meetup for meeting times, locations, and connection information.

DrupalEasy: DrupalEasy Podcast 215 - Kaleem Clarkson - Drupal Event Organizers Working Group

4. Februar 2019 - 14:00

Direct .mp3 file download.

Kaleem Clarkson, Operations Manager and Front-End Drupal Developer at Kennesaw State University and Drupal developer at blend me inc. Listen in as they discuss the newly formed Drupal Event Organizers Group and Mike breaks bad news about the Marvel Universe to Kaleem.

Discussion DrupalEasy News Upcoming Events Sponsors 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.

Matt Glaman: Testing your Drupal code base for deprecated code usage with PHPStan

3. Februar 2019 - 17:14
Testing your Drupal code base for deprecated code usage with PHPStan Sunday 3, February 2019 mglaman

Last month I wrote about writing better Drupal code with static analysis using PHPStan. One of the more practical uses I saw for PHPStan and Drupal was the discovery of deprecated code usages through the phpstan/phpstan-deprecation-rules package. I had not fully tested it, until this week. 

blog.studio.gd: Drupal 8 Views Plugins (Part 2) : The display extender plugin

3. Februar 2019 - 10:04
Let's see how and why to use a views display extender plugin.

blog.studio.gd: Views Plugins (Part 1) : Simple area handler plugin

3. Februar 2019 - 10:04
In this series I will show you how to make use of the new Drupal 8 Plugin system, we begin with a simple example : the views area handler plugins.

blog.studio.gd: Overview of CMI in Drupal 8

3. Februar 2019 - 10:04
Some notes about the new Configuration management system in Drupal 8

blog.studio.gd: Migrate to Drupal 8 from a custom site

3. Februar 2019 - 10:04
Migrate is now included in the Drupal core for making the upgrade path from 6.x and 7.x versions to Drupal 8.

In this article will see how to use the Drupal migration framework to migrate custom sites to drupal 8.

blog.studio.gd: Inline Entity Display

3. Februar 2019 - 10:04
Handle referenced entity fields directly in the parent entity

WeKnow: Improving Drupal and Gatsby Integration - The Gatsby Boina Starter

1. Februar 2019 - 19:47
Improving Drupal and Gatsby Integration - The Gatsby Boina Starter

This is the latest post of the “Improving Drupal and Gatsby Integration” series. This time I will be talking about the Gatsby Boina Starter; we are contributing to make your Drupal-Gatsby integration easier. The Boina starter ships with the main Gatsby configuration files you might need to get up and running on your Gatsby site.

jmolivas Fri, 02/01/2019 - 17:47