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

Specbee: Building Custom Modules in Drupal 8 - Best Practices to Follow

28. März 2018 - 14:42
Recently, I was looking for a module in Drupal and something just crossed my mind. In the Drupal world, when you are looking out or considering for solutions, the first thing you might hear is, "there is a module for that!". While there are close to just 40 core modules in Drupal, it is the additional contributed modules built by the Drupal community that extends the platform's functionality.

Lullabot: A Development Workflow for Drupal 8 Projects

28. März 2018 - 12:43

Every development team has a particular way of working. However, over the years I have noticed that there are a few common practices that, once documented and agreed upon, can help considerably in the team’s productivity. This article aims to serve as a template for new and existing projects.

Assumptions

Feel free to copy the following contents to an internal page in your wiki and start discussing and adjusting it with your team. It’s crucial that everyone in the team is willing to give these practices a go for a sprint and then evaluate and adjust during the next sprint retrospective.

The README and CHANGELOG documents

Each repository must have a README file and may have a CHANGELOG document.

The README describes the project’s nature, lists requirements, and contains installation instructions. This document should contain everything that a developer needs to set up the project locally. If you are looking for a Drupal 8 specific one, here is an example.

The CHANGELOG is the living Release Notes document that allows anyone (developers, product managers, etc.) to understand exactly what changes are affiliated with a specific version of the project. This document is used when creating new releases to describe how should other teams update their current installations.

Working with repositories

It’s useful to receive notifications every time that someone makes changes in a repository. We encourage you to subscribe to pull requests in order to start learning from everyone's code by clicking on the eye icon at the top right corner of each repository's homepage:

undefined

Make sure you have a GitHub account with an SSH key. You can add your SSH key here and, after doing that, you can share it with the team by appending .keys to your profile, like this.

Setting up your environment

Each project is different, so look at the repository’s README for instructions on how to set it up. If you find a repository which does not have a README, use this one as a template.

Setting up your editor

You can use any editor to work on projects, but the one that offers the best integration with Drupal 8 at the moment is PHPStorm. Please take a few minutes to adjust PHPStorm to work with Drupal by reading this guide.

Working on a ticket

Each ticket should have its own branch or branches. A branch name should be prefixed with the ticket number and a one or two-word description (for example, PROJECTNAME-123-foo). Here is how you can do it:

cd /var/www/projectname git checkout master git pull origin master // Merge the current master into your branch. git checkout -b PROJECTNAME-123-foo // create and switch to a new branch 'PROJECTNAME-123-foo'

Once you are ready to push your changes, commit them to the branch with the following commands:

git status // Shows your changes. git add [file] // Add any new or modified files. Supports patterns. git add --patch [file] // Better yet, review changes and stage your hunks. git diff --cached // Shows what is about to be committed. Review it carefully! git commit -m "PROJECTNAME-123 Description shorter than 50 characters"

Aim to make small commits which you can describe easily in your branch. The Erlang project has a good guide for writing good commit messages. If you want to add further info to the commit message, skip the -m parameter and use the default editor to set the title and the description of the commit message.

If your pull request alters the installation process or requires additional steps during the updating process, then adjust the README and CHANGELOG files accordingly.

Writing and updating tests

Bug fixes and new features will be easier to peer review if the project's tests pass and the new code is covered by the tests. To get an idea of what sort of tests you may find, check out this article.

Ok, ship it!

Once you have completed the above section, push the branch to Github:

git push -u origin PROJECTNAME-123-foo // pushes your branch to the origin repository. PROJECTNAME-456 Fix video uploads only allowing mp4 undefined

Post a link to the pull request in the respective ticket and set it's status to "Needs Review" in order to track progress within the sprint.

Peer reviews

The rule of thumb of peer reviews is that nobody can push to master branch. Everything should happen in pull requests which are reviewed and merged by the rest of the team.

After creating the pull request, prepare it for code review by following this guide. Once the pull request is ready for review, add reviewers to it through the web interface. Here is an example:

undefined

When merging a pull request, follow the git standards with a short one-line message, a blank line, and paragraphs if needed. Here are two sample merge commits::

[#pr-number] PROJECTNAME-123: Summary of the work being merged PROJECTNAME-123: Summary of the work being merged #pr-number

Finally, if this pull request completes the Jira ticket, then open it and change its status to the next one, which normally is "In QA", if you have a QA team, or "Done" if not.

How to create a release

If you are distributing code to be deployed by other teams, then your team needs to keep a CHANGELOG which evolves along with the code. Review the section "The README and CHANGELOG documents" for an introduction.

Once the sprint has completed, it is time to create a release. Here are the steps to follow:

  1. If there is Continuous Integration, check that all tests pass and that there is the same or higher coverage that by the end of the previous sprint. If not, request the development team to fix this.
  2. Clone the repository where you want to create the new release.
  3. Create a new branch where you update the module's CHANGELOG by setting a version number at the top. If the module does not have a CHANGELOG file yet, create one using the example further above as a template.
  4. Developers indicate the level bump needed for each change by indicating it with the word "PATCH", "MINOR" or "MAJOR". This takes into account semantic versioning. So, depending on the changes that this release includes you increase either the PATCH, MINOR or MAJOR number for the next version.
  5. Once the pull request has been approved by the team, merge it.
  6. Create a tag: git tag -a [VERSION]
  7. Enter a description of what is being released on this tag.
  8. Push the tag to the repository: git push origin [VERSION].

Note: If you need to double check anything stated in the CHANGELOG while preparing the release, you may use the following command to retrieve all commits since the last release:

git log --oneline --reverse --first-parent <insert last tag version here>.. | cut -c 9- git log --oneline --reverse --first-parent 1.0.0.. | cut -c 9- Ticket review guide

Here are a few tips for both sides: the individual working on the code and the people reviewing the pull request.

For the pull request authors
  • Make sure that the checked in code does what the ticket specifies.
  • Use code sniffer to check and fix violations against Drupal’s coding standards.
  • Add comments on the code as you see fit. This is useful not only for maintenance but also for peer reviewers.
  • Make sure that your set of changes are covered by reasonable PHPUnit or Behat tests.
  • Write a summary of what the code does and other related info such as screenshots. Include manual testing instructions if needed.
  • If there is Continuous Integration, verify that all jobs pass.
For the reviewers
  • Verify that all the jobs executed by the Continuous Integration tool are passing. If there are failures, inspect the logs and notify the pull request’s author.
  • Check that the code is easy to follow, respects Drupal’s Coding Standards, and is documented.
  • If there are no tests, consider suggesting how they could be written.
  • Look for performance and security risks. If you need tips, this guide offers great help.

Further tips can be found at The Peer Review How-To guide.

Acknowledgments

This guide is the result of working with the following clients, which we thank deeply:

Plus, the following folks at Lullabot:

Agiledrop.com Blog: AGILEDROP: What Marketing Tools and Services can Digital Agencies Integrate with Drupal 8

28. März 2018 - 12:32
Automation is a term that probably defines the need of technology most perfectly. Automation not only helps to make menial and repetitive tasks easier but also helps with keeping track of the work that is being done. Due to this fact, there have been a host of marketing automation tools and services that have cropped up in recent history (e.g.: HubSpot). Previously, integrating such platforms in a website was somewhat of a difficult task, but luckily Drupal has realized the need for easier integration with such platforms and starting with Drupal 8, it has become a lot easier to integrate… READ MORE

Dries Buytaert: Matthew's Documentation Initiative Proposal

28. März 2018 - 11:43

Last month, Matthew Grasmick sparked an important conversation surrounding Drupal's evaluator experience and our approach to documentation. It's become clear that we need to evolve our documentation governance model, in addition to formalizing best practices.

After receiving a tremendous amount of support and feedback, Matthew has continued the conversation by publishing a Documentation Initiative Proposal. Matt's proposal includes an evaluation of our current state, a picture of what success could look like, and what you can do to get involved. If you are passionate about improving Drupal's evaluator experience, I would encourage you to read Matt's proposal!

TheodorosPloumis blog: Drupaltools - A list of open and free tools for Drupal

27. März 2018 - 21:42

Drupal community nowadays is huge. Many people create stuff on Drupal.org, on Github, on Gitlab, wherever. Although Drupal.org makes a try to collect all the useful projects related to Drupal there are still some thing that cannot be done.

James Oakley: Overcoming memory issues installing Drupal with Composer

27. März 2018 - 17:34

Drupal 8 uses Composer for package management. You can still install a Drupal 8 site by downloading a tarball, but we're all encouraged to use Composer to download Drupal core and other dependencies and to keep things up to date.

I'm just starting to get my head around how Drupal 8 works, so that I can reach the point where I can build new sites in 8.x rather than 7.x, and in time migrate existing sites over. Composer is part of the learning curve for this.

Blog Category: Drupal Planet

Zivtech: How to Prevent Your Drupal Site from Getting Hacked: Part 1

27. März 2018 - 11:00

There’s no foolproof way to get an unhackable Drupal site; there could always be an exploit that we don’t know about yet. But there are quite a few ways you can help reduce the risk of getting hacked. Let’s dive into some of the most common ways Drupal sites get hacked, and how to secure your site against these points of entry.

Drupal Security Advisories

One of the most common ways to get hacked is to fall behind on known Drupal Security Advisories. Keeping up to date on the latest advisories is ultimately your first line of defense. 

There are security advisories for both Drupal core and contributed projects with varying levels of security risk for the exploits found. You can sign up for the security email list to make things easier to keep track of. You can do this by logging into your Drupal.org account and editing your user profile. From there you can subscribe to the security newsletter on the newsletters tab. This list will email you soon after Drupal Security Advisories are released to the public, which helps quickly notify you or your team of possible exploits that need to be fixed. 

You can use the Update Status module in Drupal core to see which sites are affected by these advisories. Then add an email address to send Security Alerts to daily or weekly. The Update Status alerts have also notified us in a few cases when the email list was backed up and took longer than it normally would. 

Typically, Drupal core security advisories come out on the third Wednesday of the month unless it’s a highly critical update that needs to be patched sooner. Contrib project security advisories can come out on any given Wednesday. 

Read more

Amazee Labs: DrupalCamp Ruhr 2018 Recap

27. März 2018 - 8:41
DrupalCamp Ruhr 2018 Recap

Two hundred and fifty people from across Germany and its neighbouring countries gathered in Essen on 17 and 18 March for DrupalCamp Ruhr, an event full of fresh discussions, workshops and presentations.

Josef Dabernig Tue, 03/27/2018 - 08:41

The organizers decided to use the Open Space / Barcamp format that provided attendees with the option to pre-select certain sessions, but which could also be combined spontaneously with ad-hoc sessions that the participants had presented in the kick-off session. This meant that, in contrast to our regular conference experience, each of us got to quickly present our idea and were also able to adapt the camp’s schedule collaboratively before we started.

On each day, we would then agree upon the session plan. I ended up doing a planned session and two spontaneous ones. Before I start to explain what I talked about, I would like to highlight what stood out for me, in terms of discussions and themes at the conference:

Drupal 8 Distributions are ready

The initial panel discussion on distributions was a great moment to hear Distribution Maintainers and Leads talk about NP8, deGov, Thunder, Varbase, Commerce, OpenSocial and the Out of the Box initiative. It was great to see how much progress the distribution space has already made in Drupal 8. Distributions are an excellent way to highlight what Drupal can do and push for reusable, generic solutions. As I had worked 4 years with the epiqo team on Recruiter, one of the first Drupal 7 distributions, this was also a good reminder of the interesting challenges we face when creating products based on Drupal. In addition, the panelists also discussed how to best manage configurations using approaches like Features and Config Split.

Local Communities starting to collaborate

Another highlight was the discussions around aligning Drupal community efforts. The project, Local Community Distribution, was created to combine efforts in order to build and maintain local community websites. Representatives from various country initiatives were brought together, along with neighbouring countries such as France and the Netherlands, to share their codebases in the interim, which can be used as a solid foundation to get these projects off the ground. Details of the discussion can be found in this ticket.

 

Coincidentally, we recently started an initiative to create a new Drupal Switzerland website, so keep an eye on our group’s page or join one of the Zurich Meetups to follow the progress and join the discussion.

Communication moving from Slack to DrupalChat

Over the last few years, a large percentage of instant communication has moved from IRC to Slack because of superior usability. Unfortunately, Slack’s commercial focus limits the community using it - currently most of our channels appear empty due to the fact that Drupal Slack hides old messages. The local communities, therefore, decided to go for DrupalChat.eu as an alternative. If you are interested, follow this issue or join the BOF at DrupalCon NA.

Drupal 8 Initiatives are making progress

In my talk - Drupal 8 Initiatives, I tried to give an overview of the status, history and achievements of the initiatives that are contributing to the Drupal 8 project. It was a great opportunity to highlight how much Drupal 8 has already been evolving over the years as well as to show how any future contributions can be done collaboratively.

In the spontaneous session, we spoke about Agile and Project Management practices as well as the #d8rules initiative.

Keeping an eye on upcoming Drupal events in Europe

Thanks to the DrupalCamp Ruhr team for putting together such a dynamic event!

We are really looking forward to more collaboration and exchanges within the Drupal community during 2018. For those who can’t make it to DrupalCon Nashville, 9-13 April, Europe has you covered. Keep an eye on these events:

As usual, you can also find many more regional events on Drupical and finally, if you are interested in an unconference using the Open Space format, make sure to join us for Agile Lean Europe Zürich 2018, August 22-24.

For more information on DrupalCamp Ruhr, check out the event website, the #dcruhr18 twitter hashtag or find more pictures on our flickr page.

MidCamp - Midwest Drupal Camp: Musings on MidCamp, and how the Drupal Leprechaun got away

26. März 2018 - 22:01
Musings on MidCamp, and how the Drupal Leprechaun got away

As I mentioned in the closing remarks, this year’s MidCamp was a roller coaster ride. And as I said to people in the halls: the actual camp is the easy part; it’s getting there that is the real challenge.

One would think that after five years of planning MidCamp, this would get easier. Sadly, this has not been the case. Our primary challenge year to year is organizer burnout. The core team keeps shrinking and inevitably someone takes on a significant burden to keep camp on course. This year, that was me, though I’m either too stubborn or too stupid to walk away from the project.

Some specific challenges we faced this year:

  • We overreached with the site rebuild, giving us a late start to crucial things like selling sponsorships and opening the call for papers
  • We were $15k below our revenue goals just four weeks before camp
  • We succeeded in finally getting DePaul faculty to underwrite us as an internal event (which would have saved on both venue rental and catering fees) only to find out that we were too far in the process (and then later find out we will forever be an external event)

To stay afloat, we made adjustments:

  • We increased training ticket costs to cover food and training day venue rental
  • We canceled all but coffee and water for session days and the Sunday sprint
  • We cut any rooms not used for sessions and we massaged our schedule and room reservations (DePaul is unique in letting us reserve by the hour versus whole or half day like many other venues)
  • We cut all but limited snacks at the after parties

The extra hours picking up the slack, the repeated bad news, constant fretting over the budget, and all these cuts really made me start to wonder if MidCamp was worth the effort.

I’m at a dozen or more camps each year. The unsolicited MidCamp love I hear at these camps is what keeps me going. And it was also the reason I could not fathom why we were falling apart at the seams. The community seems to think this is a viable camp, but in all other ways, we were not hitting the mark. Which got me thinking this could very well have been the fifth and final MidCamp.

It was with this in mind that I reached out to Twitter with what I call my hat-in-hand tweet. And the community proved, in no uncertain terms, that this camp matters. We hit record numbers of individual sponsors and received over $1,000 in donations, which we’ve never taken before. And sponsors followed with a last-minute show of support.

We had money again, which meant it was time to reverse some of our cuts. Yet the changes we were forced to make had some unforeseen consequences, the most glaring of which was the cavernous emptiness of the main room. This is a model we lifted from DrupalCorn Camp early on and it worked well for a while. But this year it was a colossal fail as people, by and large, did not return to the main room to eat their lunch after grabbing it from the cafeteria, which meant almost no foot traffic for sponsor tables, and a $5,000-per-day room hosting only a few dozen people outside of the keynote, lightning talks, and camp closing.

So with attendee and sponsor feedback, plus diligent head counts of every room every hour (including the main room), we are now armed with actual data instead of anecdotal recollections:

  • The multi-purpose sponsor/bof/keynote room was a bust
  • There was a 33% drop in session attendance from Friday to Saturday (yikes!)
  • And MidCamp—while amazing—was just another camp

It’s time for change. Here is what’s in store for 2019:

  • Condensing all of camp to a single floor of the student center
  • Allowing slightly longer time between sessions
  • Shifting the schedule so that sessions are Thursday and Friday, to address attendance drop-off
  • Adding summits to the training day before camp starts to draw more attendance
  • Curating sprint initiatives and marketing them early, again to draw more attendance
  • Leveraging MidCamp as the onramp to DrupalCon

And that, my friends, brings us to the amazing Druplichaun we revealed for O’MidCamp. To roll camp back a day, we need to push to the following week in 2019, March 20-23. So if you caught sight of the little fella, know that he got away this time, but we anticipate seeing him again in the future.

Feel free to come to Chicago early and watch the river turn green, escape the Chi-rish, and do some fun things with the local community while we ramp up for an all-new MidCamp.

If you made it this far, thanks for reading and consider getting involved! Join the Slack at https://midcamp-slack.herokuapp.com/

See you around,
Kevin Thull
MidCamp 2019 Fearless Leader (among other things)