Drupal

Social Geolocation

New Drupal Modules - 13 December 2018 - 5:04am

This module is there to provide a solution for Open Social to allow:
- Showing entities on a map
- Filtering entities on proximity

All based on connecting Open Social with contributed modules:
- Address
- Geocode

Enabling this module will ensure entity address data is geocoded and stored in your database.

Categories: Drupal

Wim Leers: State of JSON:API (December 2018)

Planet Drupal - 13 December 2018 - 4:58am

Gabe, Mateu and I just released the third RC of JSON:API 2, so time for an update! The last update is from three weeks ago.

What happened since then? In a nutshell:

RC3

Curious about RC3? RC2 → RC3 has five key changes:

  1. ndobromirov is all over the issue queue to fix performance issues: he fixed a critical performance regression in 2.x vs 1.x that is only noticeable when requesting responses with hundreds of resources (entities); he also fixed another performance problem that manifests itself only in those circumstances, but also exists in 1.x.
  2. One major bug was reported by dagmar: the ?filter syntax that we made less confusing in RC2 was a big step forward, but we had missed one particular edge case!
  3. A pretty obscure broken edge case was discovered, but probably fairly common for those creating custom entity types: optional entity reference base fields that are empty made the JSON:API module stumble. Turns out optional entity reference fields get different default values depending on whether they’re base fields or configured fields! Fortunately, three people gave valuable information that led to finding this root cause and the solution! Thanks, olexyy, keesee & caseylau!
  4. A minor bug that only occurs when installing JSON:API Extras and configuring it in a certain way.
  5. Version 1.1 RC1 of the JSON:API spec was published; it includes two clarifications to the existing spec. We already were doing one of them correctly (test coverage added to guarantee it), and the other one we are now complying with too. Everything else in version 1.1 of the spec is additive, this is the only thing that could be disruptive, so we chose to do it ASAP.

So … now is the time to update to 2.0-RC3. We’d love the next release of JSON:API to be the final 2.0 release!

P.S.: if you want fixes to land quickly, follow dagmar’s example:

If you don't know how to fix a bug of a #drupal module, providing a failing test usually is really helpful to guide project maintainers. Thanks! @GabeSullice and @wimleers for fixing my bug report https://t.co/bEkkjSrE8U

— Mariano D'Agostino (@cuencodigital) December 11, 2018
  1. Note that usage statistics on drupal.org are an underestimation! Any site can opt out from reporting back, and composer-based installs don’t report back by default. ↩︎

  2. Since we’re in the RC phase, we’re limiting ourselves to only critical issues. ↩︎

  3. This is the first officially proposed JSON:API profile! ↩︎

Categories: Drupal

Term Revision

New Drupal Modules - 13 December 2018 - 4:53am

Coming Soon....

Categories: Drupal

Twitter API Search

New Drupal Modules - 13 December 2018 - 4:31am
Overview

Twitter API Search module provides a block that will show embed tweets resulting from a Twitter API v1.1 Search query.

If you are not familiar with Twitter API, go to https://developer.twitter.com/en/docs/tweets/search/overview/standard.

Categories: Drupal

Agiledrop.com Blog: Interview with Kevin Kaland, aka wizonesolutions: Towards a more and more decoupled Drupal

Planet Drupal - 13 December 2018 - 4:03am

Meet Kevin Kaland, perhaps more easily recognized by his Twitter handle wizonesolutions, the digital wizard responsible for the FillPDF module. In this interview, he talks about his first interactions with Drupal and reveals his thoughts on the future of Drupal as a decoupled system. 

READ MORE
Categories: Drupal

Stock Photo Search

New Drupal Modules - 13 December 2018 - 1:51am
STOCK PHOTO SEARCH

Provides a field type for downloading images from 3rd party stock photography providers.

This module is safe to use on a production site.

Categories: Drupal

Google API PHP Client

New Drupal Modules - 13 December 2018 - 1:20am

Provides a Drupal wrapper and Service for Google API Client. https://github.com/google/google-api-php-client

Categories: Drupal

Acquia highway billboards

Dries Buytaert - 12 December 2018 - 7:01pm

If you're driving into Boston, you might notice something new on I-90. Acquia has placed ads on two local billboards; more than 120,000 cars drive past these billboards everyday. This is the first time in Acquia's eleven years that we've taken out a highway billboard, and dipped our toes in more traditional media advertising. Personally, I find that exciting, because it means that more and more people will be introduced to Acquia. If you find yourself on the Mass Pike, keep an eye out!

Categories: Drupal

CKEditor Plugins

New Drupal Modules - 12 December 2018 - 5:34pm
Categories: Drupal

Commerce Collect.js

New Drupal Modules - 12 December 2018 - 4:35pm

This module provides for processing payments in Drupal Commerce version 1.x (for D7) by using a payment gateway tokenization function known as "Collect.js" with a Direct Post API, greatly enhancing security with minimal impact on the end-user experience. This API was developed by Network Merchants, LLC and is used by other processors because NMI repackages the API for various other ISOs. If your payment gateway uses Collect.js, this module will work for you.

Categories: Drupal

Environment tokens

New Drupal Modules - 12 December 2018 - 3:50pm

Provides tokens for environmental variables.

Categories: Drupal

Drupal Association blog: Introducing the (unofficial) Drupal Recording Initiative

Planet Drupal - 12 December 2018 - 1:53pm

This is a guest blog by Kevin Thull (kthull).

Shout-out to Matt Westgate of Lullabot, who I met earlier this year at DrupalCorn Camp in Des Moines for casually referring to what I’ve been doing for the past five years as the “Drupal Recording Initiative.” It was yet another one of those moments when I realized that what I’ve been doing for the past five years is much bigger than just me.

Let’s recap

What began in 2013 as an effort to record sessions for camps in my local community became a passion project and a way for me to help a handful of other camps record their sessions. That was the extent of my “vision” for this project.

With the advent of Slack (specifically the Drupal Camp Organizer Slack) it became even easier for camp organizers to discover and request my services, and suddenly I was recording a dozen-plus camps per year. With more robust documentation and enough inventory to ship kits to camps that I can’t attend, I have nearly complete coverage of camps in North America.

Turning point

With this year’s milestones, funding, and recognition (and all the publicity that came with it), conversations at camps turned more toward “what’s next” and “how do you grow this” rather than “how and why.”

As I started to think along the lines of future-proofing, open-sourcing, and growth, I’ve made some steps in the right direction this past year (again with no goals or plan):

  • Tweaks to the kits and troubleshooting for more reliable recording
  • Docs moved from Google Drive to GitHub for discoverability and collaboration
  • A growing contributor list: basically anyone who has helped me in the trenches, expressed interest in doing so, recorded sessions with my equipment, or has their own set of equipment based on my setup.
The initiative

This is rough, and the point of this post is to get input from the community.

Purpose

Make the recording of Drupal and related talks at camps, summits, meetups (essentially anything outside of DrupalCon) easy, turn-key, affordable, and available.

Roadmap

The first five years evolved organically and overall successfully, but without a plan. Following are the goals for the next five years.

Training and mentorship

I’ve proven that I can do this and do it very well. My goal is to spend an increasing amount of time teaching and supporting others to repeat my success.

  • Improved camp support – I already offer support for a few camps, primarily via email and Slack before and during events; need to schedule more check-ins during events
  • Post event – Schedule post-event calls to debrief and discover gaps in documentation and training
  • Ongoing solicitation for contributors – Identify and somehow organize a group of people that can manage the recordings whether I’m on-site or not to continually spread the knowledge and coverage; the goal here is one new contact per event

Expanded coverage

While it sounds impressive to directly or indirectly record nearly all North American camps, it’s not enough. There are many more events than just camps, and there’s so much more to the world than North America.

  • Shipping kits – I’ve shipped to two events in 2018. The goal is to double that each successive year until there is sufficient global coverage of camps and larger events; smaller events like meetups would need to be covered by local equipment hubs, detailed below
  • Funding for equipment hubs – Navigating customs can prove tricky and equipment hubs within countries or regions would mitigate that risk; possible sources include crowdsourced funding or the Drupal Community Cultivation Grant (more info on this toward the end of the post)
  • Expanding beyond Drupal events – An early goal was to make a device-agnostic recording solution, so it only makes sense that it also should be content-agnostic; primary focus would be adjunct communities: WordPress, PHP, Symfony, Javascript, etc.

Improved documentation

Moving existing docs to GitHub was a step in the right direction. More visuals are needed.

  • Record a setup video
  • Record a troubleshooting video
  • Add more pics and diagrams
  • Create docs for speakers: what to bring, what to do, what not to do, how to optimize your laptop for presenting, etc.
  • Create docs for organizers: what is provided, what is needed from the venue or camp, what speakers need to know, what room monitors need to know, etc.

Higher recording success rate

In 2018, the capture rate based on my documentation and remote support was 80-85% versus 92-100% when I was on the scene. The goal here is to bridge that gap.

  • Better pre-event support and onboarding
  • Broader support for USB-c
  • Improved coverage for non-Mac audio issues
  • Better prep for volunteers and contributors for on-site coverage

Streamlined funding

This is an expensive endeavor, and I couldn’t do it without camp donations, and reimbursements for airfare and lodging. At the same time, incidental costs (food, entertainment, commuting, etc.) add up, and the current model limits me geographically.

  • Charge a flat fee of $1,000 per event (airfare and lodging typically runs $350-$750)
  • Roll surplus funds into new equipment and subsidized travel to events outside North America
  • Maintain existing crowdfunded campaign to cover personal costs (whether current GoFundMe or an alternate)
  • Potentially seek sponsorship or Drupal Community Cultivation Grant (again, see below)

Overall organization

This is definitely the squishiest part of the roadmap. Solo, this is easy to manage. But to grow, I need tools and I don’t know the best ones for this type of work.

  • Contacts – What is the best way to manage the growing list of contributors, as well as give recognition?
  • Scheduling – There should be an event calendar with ways to sign up as a recording volunteer
  • Accounting – There should be an open way to manage the funds
  • Outreach – What is the best way to publicly and continually reach out for new contributors, and to grow the base of recorded events?
  • Inventory – We need a managed inventory of equipment, who controls them, whether they are available or on loan, their condition, etc.
  • Options:

    1. Drupal.org community project
    2. GitHub project board
    3. Slack channel (they already exist in Drupal Slack and the Organizer Slack)
    4. Public meetings
    5. Other / All of the above

Content discoverability

I am not the only person recording sessions, but I am definitely the loudest and most prolific. But my tweets and siloed camp YouTube channels are not optimal for the greater community to find content. I don’t have the bandwidth to do this personally, but would contribute.

  • We absolutely need a Drupal equivalent to Wordpress.tv (several solutions are in the works, but that also has been the state of things for years)
  • Aggregate content from all events, including DrupalCon
  • Include curation and content authors to annotate various versions of the same talk, or even unpublish older or largely repetitive versions
  • Add tagging for searchability
  • Add captioning for accessibility
  • Promote local events as well as the Drupal project
Wrapping it up

I’m continually thanked and reminded of how important what I’m doing is for the community. At the same time, it’s hard for me because it feels pretty routine and relatively easy (aside from the unknowns that come with each venue setup, and the hourly hustle to connect presenters and confirm recordings). Yet recorded content is also how I first learned Drupal and it’s the very reason I began this effort.

So the next stage of this unexpected, unplanned success is to create a structure to prevent my own burnout and prevent this initiative from hitting a plateau. If you want to participate, hit me up on Drupal.org, Twitter, or send me an email.

Lastly, for those who don’t know, the Drupal Community Cultivation Grant exists for things like this. I am very grateful for the Drupal Association offering me a grant to support this program, though I hadn't yet applied (I should have and you should too).

Categories: Drupal

Drupal blog: Plan for Drupal 9

Planet Drupal - 12 December 2018 - 10:38am

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

At Drupal Europe, I announced that Drupal 9 will be released in 2020. Although I explained why we plan to release in 2020, I wasn't very specific about when we plan to release Drupal 9 in 2020. Given that 2020 is less than thirteen months away (gasp!), it's time to be more specific.

Shifting Drupal's six month release cycle

We shifted Drupal 8's minor release windows so we can adopt Symfony's releases faster.

Before I talk about the Drupal 9 release date, I want to explain another change we made, which has a minor impact on the Drupal 9 release date.

As announced over two years ago, Drupal 8 adopted a 6-month release cycle (two releases a year). Symfony, a PHP framework which Drupal depends on, uses a similar release schedule. Unfortunately the timing of Drupal's releases has historically occurred 1-2 months before Symfony's releases, which forces us to wait six months to adopt the latest Symfony release. To be able to adopt the latest Symfony releases faster, we are moving Drupal's minor releases to June and December. This will allow us to adopt the latest Symfony releases within one month. For example, Drupal 8.8.0 is now scheduled for December 2019.

We hope to release Drupal 9 on June 3, 2020

Drupal 8's biggest dependency is Symfony 3, which has an end-of-life date in November 2021. This means that after November 2021, security bugs in Symfony 3 will not get fixed. Therefore, we have to end-of-life Drupal 8 no later than November 2021. Or put differently, by November 2021, everyone should be on Drupal 9.

Working backwards from November 2021, we'd like to give site owners at least one year to upgrade from Drupal 8 to Drupal 9. While we could release Drupal 9 in December 2020, we decided it was better to try to release Drupal 9 on June 3, 2020. This gives site owners 18 months to upgrade. Plus, it also gives the Drupal core contributors an extra buffer in case we can't finish Drupal 9 in time for a summer release.

Planned Drupal 8 and 9 minor release dates.

We are building Drupal 9 in Drupal 8

Instead of working on Drupal 9 in a separate codebase, we are building Drupal 9 in Drupal 8. This means that we are adding new functionality as backwards-compatible code and experimental features. Once the code becomes stable, we deprecate any old functionality.

Let's look at an example. As mentioned, Drupal 8 currently depends on Symfony 3. Our plan is to release Drupal 9 with Symfony 4 or 5. Symfony 5's release is less than one year away, while Symfony 4 was released a year ago. Ideally Drupal 9 would ship with Symfony 5, both for the latest Symfony improvements and for longer support. However, Symfony 5 hasn't been released yet, so we don't know the scope of its changes, and we will have limited time to try to adopt it before Symfony 3's end-of-life.

We are currently working on making it possible to run Drupal 8 with Symfony 4 (without requiring it). Supporting Symfony 4 is a valuable stepping stone to Symfony 5 as it brings new capabilities for sites that choose to use it, and it eases the amount of Symfony 5 upgrade work to do for Drupal core developers. In the end, our goal is for Drupal 8 to work with Symfony 3, 4 or 5 so we can identify and fix any issues before we start requiring Symfony 4 or 5 in Drupal 9.

Another example is our support for reusable media. Drupal 8.0.0 launched without a media library. We are currently working on adding a media library to Drupal 8 so content authors can select pre-existing media from a library and easily embed them in their posts. Once the media library becomes stable, we can deprecate the use of the old file upload functionality and make the new media library the default experience.

The upgrade to Drupal 9 will be easy

Because we are building Drupal 9 in Drupal 8, the technology in Drupal 9 will have been battle-tested in Drupal 8.

For Drupal core contributors, this means that we have a limited set of tasks to do in Drupal 9 itself before we can release it. Releasing Drupal 9 will only depend on removing deprecated functionality and upgrading Drupal's dependencies, such as Symfony. This will make the release timing more predictable and the release quality more robust.

For contributed module authors, it means they already have the new technology at their service, so they can work on Drupal 9 compatibility earlier (e.g. they can start updating their media modules to use the new media library before Drupal 9 is released). Finally, their Drupal 8 know-how will remain highly relevant in Drupal 9, as there will not be a dramatic change in how Drupal is built.

But most importantly, for Drupal site owners, this means that it should be much easier to upgrade to Drupal 9 than it was to upgrade to Drupal 8. Drupal 9 will simply be the last version of Drupal 8, with its deprecations removed. This means we will not introduce new, backwards-compatibility breaking APIs or features in Drupal 9 except for our dependency updates. As long as modules and themes stay up-to-date with the latest Drupal 8 APIs, the upgrade to Drupal 9 should be easy. Therefore, we believe that a 12- to 18-month upgrade period should suffice.

So what is the big deal about Drupal 9, then?

The big deal about Drupal 9 is … that it should not be a big deal. The best way to be ready for Drupal 9 is to keep up with Drupal 8 updates. Make sure you are not using deprecated modules and APIs, and where possible, use the latest versions of dependencies. If you do that, your upgrade experience will be smooth, and that is a big deal for us.

Special thanks to Gábor Hojtsy (Acquia), Angie Byron (Acquia), xjm(Acquia), and catch for their input in this blog post.

Categories: Drupal

Jacob Rockowitz: Managing Drupal and Webform configuration

Planet Drupal - 12 December 2018 - 9:58am

Webforms in Drupal 8 are configuration entities, which means that they are exportable to YAML files and this makes it easy to transfer a webform from one server environment to another. Generally, anything that defines functionality or behavior in Drupal 8 is stored as simple configuration or a configuration entity. For example, fields, views, and roles are stored as configuration entities. Things that are considered 'content' are stored in the database as content entities. Content entities include nodes, comments, taxonomy terms, users, and also webform submissions.

Managing Configuration

The core concept behind Drupal's configuration management is you can export and import how a website is configured (aka how it works) from one environment to another environment. For example, we might want to copy the configuration from your staging server to your production server. Drupal 8 has initially taken the approach that all configuration from one environment needs to be moved to the new environment. The problem is that…

In the case of webforms and blocks, this is a major issue because site builders are continually updating these config entities on a production website. The Drupal community is aware of this problem - they have provided some solutions and are actively working to fix this challenge/issue in a future release of Drupal.

Improving Configuration Management

Dries Buytaert shared how we are improving Drupal's configuration management system and he notes that the currently recommended solutions are the Config Filter, Configuration Split, and Config Ignore modules.

Below is a summary...Read More

Categories: Drupal

Media Field Formatters

New Drupal Modules - 12 December 2018 - 9:09am

Miscellaneous field formatters designed to be used with the Media module bundled in core. Patches are welcome to expand the selection of available formatters.

Categories: Drupal

SVG Upload Sanitizer

New Drupal Modules - 12 December 2018 - 9:02am
Introduction

The SVG Upload Sanitizer module provides a simple way to sanitize
uploaded svg.

Every uploaded svg is automatically sanitize.

Requirements

The module requires the following package:

Categories: Drupal

InternetDevels: Top Drupal e-commerce distributions to quickly create an online store

Planet Drupal - 12 December 2018 - 7:52am

Your future awesome e-commerce website can be closer than you imagined. Drupal makes site creation especially quick and easy thanks to distributions. Ready distributions in the sphere of commerce are among the numerous reasons why Drupal is the best solution for e-commerce websites. They allow to quickly create an online store and spend much less on it.

Read more
Categories: Drupal

Champions Blog Core

New Drupal Modules - 12 December 2018 - 6:03am

The core of the blog module which installs a content type, its fields, numerous paragraphs, image styles, form and view displays, etc. It might make sense to migrate this into a feature, but it is a module for now.

Categories: Drupal

App

New Drupal Modules - 12 December 2018 - 6:00am

Docker hosting

Categories: Drupal

Dries Buytaert: Plan for Drupal 9

Planet Drupal - 12 December 2018 - 5:13am

At Drupal Europe, I announced that Drupal 9 will be released in 2020. Although I explained why we plan to release in 2020, I wasn't very specific about when we plan to release Drupal 9 in 2020. Given that 2020 is less than thirteen months away (gasp!), it's time to be more specific.

Shifting Drupal's six month release cycle We shifted Drupal 8's minor release windows so we can adopt Symfony's releases faster.

Before I talk about the Drupal 9 release date, I want to explain another change we made, which has a minor impact on the Drupal 9 release date.

As announced over two years ago, Drupal 8 adopted a 6-month release cycle (two releases a year). Symfony, a PHP framework which Drupal depends on, uses a similar release schedule. Unfortunately the timing of Drupal's releases has historically occurred 1-2 months before Symfony's releases, which forces us to wait six months to adopt the latest Symfony release. To be able to adopt the latest Symfony releases faster, we are moving Drupal's minor releases to June and December. This will allow us to adopt the latest Symfony releases within one month. For example, Drupal 8.8.0 is now scheduled for December 2019.

We hope to release Drupal 9 on June 3, 2020

Drupal 8's biggest dependency is Symfony 3, which has an end-of-life date in November 2021. This means that after November 2021, security bugs in Symfony 3 will not get fixed. Therefore, we have to end-of-life Drupal 8 no later than November 2021. Or put differently, by November 2021, everyone should be on Drupal 9.

Working backwards from November 2021, we'd like to give site owners at least one year to upgrade from Drupal 8 to Drupal 9. While we could release Drupal 9 in December 2020, we decided it was better to try to release Drupal 9 on June 3, 2020. This gives site owners 18 months to upgrade. Plus, it also gives the Drupal core contributors an extra buffer in case we can't finish Drupal 9 in time for a summer release.

Planned Drupal 8 and 9 minor release dates.We are building Drupal 9 in Drupal 8

Instead of working on Drupal 9 in a separate codebase, we are building Drupal 9 in Drupal 8. This means that we are adding new functionality as backwards-compatible code and experimental features. Once the code becomes stable, we deprecate any old functionality.

Let's look at an example. As mentioned, Drupal 8 currently depends on Symfony 3. Our plan is to release Drupal 9 with Symfony 4 or 5. Symfony 5's release is less than one year away, while Symfony 4 was released a year ago. Ideally Drupal 9 would ship with Symfony 5, both for the latest Symfony improvements and for longer support. However, Symfony 5 hasn't been released yet, so we don't know the scope of its changes, and we will have limited time to try to adopt it before Symfony 3's end-of-life.

We are currently working on making it possible to run Drupal 8 with Symfony 4 (without requiring it). Supporting Symfony 4 is a valuable stepping stone to Symfony 5 as it brings new capabilities for sites that choose to use it, and it eases the amount of Symfony 5 upgrade work to do for Drupal core developers. In the end, our goal is for Drupal 8 to work with Symfony 3, 4 or 5 so we can identify and fix any issues before we start requiring Symfony 4 or 5 in Drupal 9.

Another example is our support for reusable media. Drupal 8.0.0 launched without a media library. We are currently working on adding a media library to Drupal 8 so content authors can select pre-existing media from a library and easily embed them in their posts. Once the media library becomes stable, we can deprecate the use of the old file upload functionality and make the new media library the default experience.

The upgrade to Drupal 9 will be easy

Because we are building Drupal 9 in Drupal 8, the technology in Drupal 9 will have been battle-tested in Drupal 8.

For Drupal core contributors, this means that we have a limited set of tasks to do in Drupal 9 itself before we can release it. Releasing Drupal 9 will only depend on removing deprecated functionality and upgrading Drupal's dependencies, such as Symfony. This will make the release timing more predictable and the release quality more robust.

For contributed module authors, it means they already have the new technology at their service, so they can work on Drupal 9 compatibility earlier (e.g. they can start updating their media modules to use the new media library before Drupal 9 is released). Finally, their Drupal 8 know-how will remain highly relevant in Drupal 9, as there will not be a dramatic change in how Drupal is built.

But most importantly, for Drupal site owners, this means that it should be much easier to upgrade to Drupal 9 than it was to upgrade to Drupal 8. Drupal 9 will simply be the last version of Drupal 8, with its deprecations removed. This means we will not introduce new, backwards-compatibility breaking APIs or features in Drupal 9 except for our dependency updates. As long as modules and themes stay up-to-date with the latest Drupal 8 APIs, the upgrade to Drupal 9 should be easy. Therefore, we believe that a 12- to 18-month upgrade period should suffice.

So what is the big deal about Drupal 9, then?

The big deal about Drupal 9 is … that it should not be a big deal. The best way to be ready for Drupal 9 is to keep up with Drupal 8 updates. Make sure you are not using deprecated modules and APIs, and where possible, use the latest versions of dependencies. If you do that, your upgrade experience will be smooth, and that is a big deal for us.

Special thanks to Gábor Hojtsy (Acquia), Angie Byron (Acquia), xjm (Acquia), and catch for their input in this blog post.

Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal