emGee Software Solutions Custom Database Applications

Share this

Drupal.org aggregator

Drupal.org - aggregated feeds in category Planet Drupal
Updated: 5 days 3 hours ago

erdfisch: Drupalcon mentored core sprint - part 2 - your experience as a sprinter

Sat, 05/12/2018 - 02:00
Drupalcon mentored core sprint - part 2 - your experience as a sprinter 12.05.2018 Michael Lenahan Body:  Drupalcon mentored core sprint - part 2 - your experience as a sprinter

Hello! You've arrived at part 2 of a series of 3 blog posts about the Mentored Core Sprint, which traditionally takes place every Friday at Drupalcon.

If you haven't already, please go back and read part 1.

You may think sprinting is not for you ...

So, you may be the kind of person who usually stays away from the Sprint Room at Drupal events. We understand. You would like to find something to work on, but when you step in the room, you get the feeling you're interrupting something really important that you don't understand.

It's okay. We've all been there.

That's why the Drupal Community invented the Mentored Core Sprint. If you stay for this sprint day, you will be among friends. You can ask any question you like. The venue is packed with people who want to make it a useful experience for you.

Come as you are

All you need in order to take part in the first-time mentored sprint are two things:

  • Your self, a human who is interested in Drupal
  • Your laptop

To get productive, your laptop needs a local installation of Drupal. Don't have one yet? Well, it's your lucky day because you can your Windows or Mac laptop set up at the first-time setup workshop!

Need a local Drupal installation? Come to the first-time setup workshop

After about half an hour, your laptop is now ready, and you can go to the sprint room to work on Drupal Core issues ...

You do not need to be a coder ...

You do not need to be a coder to work on Drupal Core. Let's say, you're a project manager. You have skills in clarifying issues, deciding what needs to be done next, managing developers, and herding cats. You're great at taking large problems and breaking them down into smaller problems that designers or developers can solve. This is what you do all day when you're at work.

Well, that's also what happens here at the Major Issue Triage table!

But - you could just as easily join any other table, because your skills will be needed there, as well!

Never Drupal alone

At this sprint, no-one works on their own. You work collaboratively in a small group (maybe 3-4 people). So, if you don't have coding or design skills, you will have someone alongside you who does, just like at work.

Collaborating together, you will learn how the Drupal issue queue works. You will, most likely, not fix any large issues during the sprint.

Learn the process of contributing

Instead, you will learn the process of contributing to Drupal. You will learn how to use the issue queue so you can stay in touch with the friends you made today, so that you fix the issue over the coming weeks after Drupalcon.

It's never too late

Even if you've been in the Drupal community for over a decade, just come along. Jump in. You'll enjoy it.

A very welcoming place to start contributing is to work on Drupal documentation. This is how I made my first contribution, at Drupalcon London in 2011. In Vienna, this table was mentored by Amber Matz from Drupalize.Me.

This is one of the most experienced mentors, Valery Lourie (valthebald). We'll meet him again in part 3, when we come to the Drupalcon Vienna live commit.

Here's Dries. He comes along and walks around, no one takes any notice because they are too engaged and too busy. And so he gets to talk to people without being interrupted.

This is what Drupal is about. It's not about the code. It's about the people.

Next time. Just come. As a sprinter or a mentor. EVERYONE is welcome, we mean that.

This is a three-part blog post series:
Part one is here
You've just finished reading part two
Part three is coming soon

Credit to Amazee Labs and Roy Segall for use of photos from the Drupalcon Vienna flickr stream, made available under the CC BY-NC-SA 2.0 licence.

Schlagworte/Tags:  planet drupal-planet drupalcon mentoring code sprint Ihr Name Kommentar/Comment Kommentar hinzufügen/Add comment Leave this field blank
Categories: Drupal CMS

KnackForge: How to update Drupal 8 core?

Fri, 03/23/2018 - 22:01
How to update Drupal 8 core?

Let's see how to update your Drupal site between 8.x.x minor and patch versions. For example, from 8.1.2 to 8.1.3, or from 8.3.5 to 8.4.0. I hope this will help you.

  • If you are upgrading to Drupal version x.y.z

           x -> is known as the major version number

           y -> is known as the minor version number

           z -> is known as the patch version number.

Sat, 03/24/2018 - 10:31
Categories: Drupal CMS

Freelock : The Spectre of a Meltdown

Thu, 01/11/2018 - 16:31
The Spectre of a Meltdown John Locke Thu, 01/11/2018 - 17:31

The news was supposed to come out this Tuesday, but it leaked early. Last week we learned about three variations of a new class of attacks on modern computing, before many vendors could release a patch -- and we come to find out that the root cause may be entirely unpatchable, and can only be fixed by buying new computers.

Disaster Recovery Drupal Planet hacked site maintenance Meltdown Security Spectre
Categories: Drupal CMS

Drupal Commerce: Drupal Commerce 2.x: 2017 in review

Thu, 01/11/2018 - 15:45

Now that 2017 is over and we’re back from our well deserved holidays, it’s time to look at what the Drupal Commerce community accomplished over the past year.

There is no doubt that Drupal Commerce is one of the largest and most active projects in the Drupal community. The #commerce channel is now the most active channel on the Drupal Slack, with 550 members. Over a hundred modules have received contributions from several hundred contributors working for dozens of different agencies. Just a few months after the initial stable release, there are over 2000 reported installations with new case studies appearing every week!

Let’s take a closer look.

Categories: Drupal CMS

Acro Media: Drupal Commerce 2: How to Set up Taxes

Thu, 01/11/2018 - 15:10

Setting up taxes in Drupal Commerce 2 is a snap. The component comes bundled with some predefined tax rate plugins, such as Canadian sales tax and European Union VAT. This means that enabling these tax types is as easy as checking a box. More complicated tax regions, like you would find in the United States, have integrations available with services such as Avalara AvaTax, TaxCloud and more. Custom tax types can also be created out-of-the-box.

In this Acro Media Tech Talk video, we user our Urban Hipster Commerce 2 demo site to quickly show you how to configure the predefined tax plugins as well as add a custom tax type. 

Its important to note that this video was recorded before the official 2.0 release of Drupal Commerce. The current state of the Taxes sub-module is even more robust than what you see here, and additional plugins have been added out-of-the-box. Documentation is also still lacking at the time of this post, however, we've added a link anyway so that whoever finds this in the future will benefit.

Urban Hipster Commerce 2 Demo site

This video was created using the Urban Hipster Commerce 2 demo site. We've built this site to show the adaptability of the Drupal 8, Commerce 2 platform. Most of what you see is out-of-the-box functionality combined with expert configuration and theming.

More from Acro Media Drupal modules used in this video Additional resources

Categories: Drupal CMS

Phase2: How Digital Marketing is Evolving with Drupal

Thu, 01/11/2018 - 09:32

With exponential growth in marketing tools and website builders, why are marketers still adopting Drupal and maintaining their existing Drupal systems? And how has Drupal evolved to become a crucial piece of leading brands’ martech ecosystems?

For marketing decision makers, there are many reasons to choose and stick with Drupal, including:  

  • Designed to integrate with other marketing tools

  • Increased administrative efficiencies

Categories: Drupal CMS

Community: Nominations are now open for the 2018 Aaron Winborn Award

Thu, 01/11/2018 - 06:20

The Drupal Community Working Group is pleased to announce that nominations for the 2018 Aaron Winborn Award are now open. This annual award recognizes an individual who demonstrates personal integrity, kindness, and above-and-beyond commitment to the Drupal community. It will include a scholarship and stipend to attend DrupalCon and recognition in a plenary session at the event.

Nominations are open to not only well-known Drupal contributors, but also people who have made a big impact in their local or regional community. If you know of someone who has made a big difference to any number of people in our community, we want to hear about it.

This award was created in honor of long-time Drupal contributor Aaron Winborn, whose battle with Amyotrophic lateral sclerosis (ALS) (also referred to as Lou Gehrig's Disease) came to an end on March 24, 2015. Based on a suggestion by Hans Riemenschneider, the Community Working Group, with the support of the Drupal Association, launched the Aaron Winborn Award.

Nominations are open until March 1, 2018. A committee consisting of the Community Working Group members and past award winners will select a winner from the submissions. Members of this committee and previous winners are exempt from winning the award.

Previous winners of the award are:

  • 2015: Cathy Theys
  • 2016: Gábor Hojtsy
  • 2017: Nikki Stevens

If you know someone amazing who should benefit from this award you can make your nomination.
 

Categories: Drupal CMS

Mark Shropshire: Drupal SEO Presentation at CharDUG

Thu, 01/11/2018 - 04:30

I had a great time talking general and Drupal SEO at last night's CharDUG meetup! Just wanted to drop my slide deck here for reference. There are a lot of fantastic links in the deck.

Thanks to Mediacurrent for having a great culture for internal training. They invested in a large group of staff to go through the SEO Olympian program. I also want to thank the Mediacurrent Digital Strategy team for putting this training together. This training inspired me to dig more into SEO and put together this presentation and live demo of Drupal SEO modules.

I hope to present this talk again in the future.

Blog Category: 
Categories: Drupal CMS

Agiledrop.com Blog: AGILEDROP: Who will get the control of personal data after GDPR?

Thu, 01/11/2018 - 01:36
When taking steps in the digital arena footprints are left behind. While browsing websites or when accepting the terms of use of a certain application, data is stored. Data that contains sensitive and personal information (IP address is also a personal information). That is why EU is imposing a new set of rules in the form of General Data Protection Regulation (GDPR). The goal of GDPR is to protect EU citizens from privacy and data breaches in a world never so digitally connected as it is now. The directive was first established in 1995, we have to bear in mind that a lot has changed since… READ MORE
Categories: Drupal CMS

Amazee Labs: Launching Forever Chocolate

Thu, 01/11/2018 - 01:04
Launching Forever Chocolate

We are happy to announce the website launch of Forever Chocolate, providing Barry Callebaut with a platform for their initiative to make sustainable chocolate the norm by 2025. 

Sian Wheeler Thu, 01/11/2018 - 10:04

Barry Callebaut is the world’s leading manufacturer of high-quality chocolate and cocoa and considers a sustainable production the only way through which it can continue to thrive as a company. 

To succeed with this ambitious plan by 2025, Barry Callebaut has set the following goals:

  • eradicate child labour from our supply chain

  • lift more than 500,000 cocoa farmers out of poverty

  • become carbon and forest positive

  • have 100% sustainable ingredients in all of our products

The new site was built in collaboration with London based communication agency SalterBaxter. SalterBaxter designed the report with reference to Barry Callebaut’s annual report which is built and published by Amazee Labs. The new report includes certain graphical elements which can optionally be replicated in any upcoming annual report.

Based on the uniform design with big, colourful hero elements and beautifully displayed data the information is easily comprehensible. In addition to its responsiveness, the use of animations adds a lively appearance to the site. To achieve this, the Drupal module "Paragraphs" was used to build all media & text options. From a content editor point of view, this means that anything can be reused anywhere. It is also very easy to replicate selected features for future annual reports.

Categories: Drupal CMS

WeKnow: Switching from Vagrant to Docker

Wed, 01/10/2018 - 23:30
Switching from Vagrant to Docker

Setting up a new local environment can be challenging and really time-consuming if you're doing it from scratch. While this might not be a big deal when working as a single developer on a project, in a team-based scenario it's important to share the same infrastructure configuration. That's why we highly recommended using a tool like Docker to simplify the process.

Last summer, Jesus Manuel Olivas (Project lead) and I started working on a new project, and we had to discuss which setup we should use for the local environments. Since the project was already set up to use Lightning and BLT, we both agreed to use DrupalVM with Vagrant. Everything seemed to work great apart from some permissions conflicts, which we could easily resolve since the project only had two developers at the time.

bonfil1 Thu, 01/11/2018 - 07:30
Categories: Drupal CMS

Drupal Association blog: DrupalCon Vienna Recap

Wed, 01/10/2018 - 14:01

This past September we gathered together in Vienna, Austria to talk all things Drupal. Over 1,600 of us came together to watch keynotes, present sessions, have impromptu conversations in the hallway, and sprint.

One of the hot topics on site was the future of DrupalCon in Europe. The community has rallied around facilitating a large Drupal event in 2018. The Drupal Association continues to focus on 2019 and beyond, and recently posted a call for proposals for licensing DrupalCon in Europe. You can read more about that in Megan's blog post.

We made some changes to the DrupalCon event format for DrupalCon Vienna, in an effort to improve its financial sustainability. While some of these changes were controversial in the run-up to the event, once we all arrived in Vienna there were a lot of highlights - meeting Dries, sprints, anything related to migration, and (of course!) the Viennese Ball! To read the full recap of DrupalCon Vienna, check out these slides.

Beyond Vienna, we have heard requests for previous years' slides. While we're working on a place to archive them on the website - for quick reference, here are the past couple years' presentations:

See you in Nashville!

Categories: Drupal CMS

Dries Buytaert: How to decouple Drupal in 2018?

Wed, 01/10/2018 - 11:16

In this post, I'm providing some guidance on how and when to decouple Drupal.

Almost two years ago, I had written a blog post called "How should you decouple Drupal?". Many people have found the flowchart in that post to be useful in their decision-making on how to approach their Drupal architectures. Since that point, Drupal, its community, and the surrounding market have evolved, and the original flowchart needs a big update.

Drupal's API-first initiative has introduced new capabilities, and we've seen the advent of the Waterwheel ecosystem and API-first distributions like Reservoir, Headless Lightning, and Contenta. More developers both inside and outside the Drupal community are experimenting with Node.js and adopting fully decoupled architectures. As a result, Acquia now offers Node.js hosting, which means it's never been easier to implement decoupled Drupal on the Acquia platform.

Let's start with the new flowchart in full:

All the ways to decouple Drupal

The traditional approach to Drupal architecture, also referred to as coupled Drupal, is a monolithic implementation where Drupal maintains control over all front-end and back-end concerns. This is Drupal as we've known it — ideal for traditional websites. If you're a content creator, keeping Drupal in its coupled form is the optimal approach, especially if you want to achieve a fast time to market without as much reliance on front-end developers. But traditional Drupal 8 also remains a great approach for developers who love Drupal 8 and want it to own the entire stack.

A second approach, progressively decoupled Drupal, offers an approach that strikes a balance between editorial needs like layout management and developer desires to use more JavaScript, by interpolating a JavaScript framework into the Drupal front end. Progressive decoupling is in fact a spectrum, whether it is Drupal only rendering the page's shell and populating initial data — or JavaScript only controlling explicitly delineated sections of the page. Progressively decoupled Drupal hasn't taken the world by storm, likely because it's a mixture of both JavaScript and PHP and doesn't take advantage of server-side rendering via Node.js. Nonetheless, it's an attractive approach because it makes more compromises and offers features important to both editors and developers.

Last but not least, fully decoupled Drupal has gained more attention in recent years as the growth of JavaScript continues with no signs of slowing down. This involves a complete separation of concerns between the structure of your content and its presentation. In short, it's like treating your web experience as just another application that needs to be served content. Even though it results in a loss of some out-of-the-box CMS functionality such as in-place editing or content preview, it's been popular because of the freedom and control it offers front-end developers.

What do you intend to build?

The most important question to ask is what you are trying to build.

  1. If your plan is to create a single standalone website or web application, decoupling Drupal may or may not be the right choice based on the must-have features your developers and editors are asking for.
  2. If your plan is to create multiple experiences (including web, native mobile, IoT, etc.), you can use Drupal to provide web service APIs that serve content to other experiences, either as (a) a content repository with no public-facing component or (b) a traditional website that is also a content repository at the same time.

Ultimately, your needs will determine the usefulness of decoupled Drupal for your use case. There is no technical reason to decouple if you're building a standalone website that needs editorial capabilities, but that doesn't mean people don't prefer to decouple because of their preference for JavaScript over PHP. Nonetheless, you need to pay close attention to the needs of your editors and ensure you aren't removing crucial features by using a decoupled approach. By the same token, you can't avoid decoupling Drupal if you're using it as a content repository for IoT or native applications. The next part of the flowchart will help you weigh those trade-offs.

Today, Drupal makes it much easier to build applications consuming decoupled Drupal. Even if you're using Drupal as a content repository to serve content to other applications, well-understood specifications like JSON API, GraphQL, OpenAPI, and CouchDB significantly lower its learning curve and open the door to tooling ecosystems provided by the communities who wrote those standards. In addition, there are now API-first distributions optimized to serve as content repositories and SDKs like Waterwheel.js that help developers "speak" Drupal.

Are there things you can't live without?

Perhaps most critical to any decision to decouple Drupal is the must-have feature set desired for both editors and developers. In order to determine whether you should use a decoupled Drupal, it's important to isolate which features are most valuable for your editors and developers. Unfortunately, there is are no black-and-white answers here; every project will have to weigh the different pros and cons.

For example, many marketing teams choose a CMS because they want to create landing pages, and a CMS gives them the ability to lay out content on a page, quickly reorganize a page and more. The ability to do all this without the aid of a developer can make or break a CMS in marketers' eyes. Similarly, many digital marketers value the option to edit content in the context of its preview and to do so across various workflow states. These kind of features typically get lost in a fully decoupled setting where Drupal does not exert control over the front end.

On the other hand, the need for control over the visual presentation of content can hinder developers who want to craft nuanced interactions or build user experiences in a particular way. Moreover, developer teams often want to use the latest and greatest technologies, and JavaScript is no exception. Nowadays, more JavaScript developers are including modern techniques, like server-side rendering and ES6 transpilation, in their toolboxes, and this is something decision-makers should take into account as well.

How you reconcile this tension between developers' needs and editors' requirements will dictate which approach you choose. For teams that have an entirely editorial focus and lack developer resources — or whose needs are focused on the ability to edit, place, and preview content in context — decoupling Drupal will remove all of the critical linkages within Drupal that allow editors to make such visual changes. But for teams with developers itching to have more flexibility and who don't need to cater to editors or marketers, fully decoupled Drupal can be freeing and allow developers to explore new paradigms in the industry — with the caveat that many of those features that editors value are now unavailable.

What will the future hold?

In the future, and in light of the rapid evolution of decoupled Drupal, my hope is that Drupal keeps shrinking the gap between developers and editors. After all, this was the original goal of the CMS in the first place: to help content authors write and assemble their own websites. Drupal's history has always been a balancing act between editorial needs and developers' needs, even as the number of experiences driven by Drupal grows.

I believe the next big hurdle is how to begin enabling marketers to administer all of the other channels appearing now and in the future with as much ease as they manage websites in Drupal today. In an ideal future, a content creator can build a content model once, preview content on every channel, and use familiar tools to edit and place content, regardless of whether the channel in question is mobile, chatbots, digital signs, or even augmented reality.

Today, developers are beginning to use Drupal not just as a content repository for their various applications but also as a means to create custom editorial interfaces. It's my hope that we'll see more experimentation around conceiving new editorial interfaces that help give content creators the control they need over a growing number of channels. At that point, I'm sure we'll need another new flowchart.

Conclusion

Thankfully, Drupal is in the right place at the right time. We've anticipated the new world of decoupled CMS architectures with web services in Drupal 8 and older contributed modules. More recently, API-first distributions, SDKs, and even reference applications in Ember and React are giving developers who have never heard of Drupal the tools to interact with it in unprecedented ways. Moreover, for Acquia customers, Acquia's recent launch of Node.js hosting on Acquia Cloud means that developers can leverage the most modern approaches in JavaScript while benefiting from Drupal's capabilities as a content repository.

Unlike many other content management systems, old and new, Drupal provides a spectrum of architectural possibilities tuned to the diverse needs of different organizations. This flexibility between fully decoupling Drupal, progressively decoupling it, and traditional Drupal — in addition to each solution's proven robustness in the wild — gives teams the ability to make an educated decision about the best approach for them. This optionality sets Drupal apart from new headless content management systems and most SaaS platforms, and it also shows Drupal's maturity as a decoupled CMS over WordPress. In other words, it doesn't matter what the team looks like or what the project's requirements are; Drupal has the answer.

Special thanks to Preston So for contributions to this blog post and to Alex Bronstein, Angie Byron, Gabe Sullice, Samuel Mortenson, Ted Bowman and Wim Leers for their feedback during the writing process.

Categories: Drupal CMS

Lullabot: Guidelines for Writing Proper Tickets and Commits

Wed, 01/10/2018 - 08:12

Have you ever been assigned a ticket with a title like “Some Images Don’t Work,” or opened a monstrous pull request containing a single commit labeled “bug fixes” as your only clue to the changes made? This level of ambiguity is frustrating and can end up costing exorbitant time and money to research. The titles, descriptions, and messages we provide in our workflow should make the jobs of not only our peers easier but also future team members who will inherit the project.

By tweaking our process just a little to document while we work, we can alleviate stress and save time and money on the project. Now don’t go breaking out the wikis and word processors just yet. Much of the critical documentation can be done within the tools you are already using. Writing actionable ticket titles, informative descriptions, and properly referencing related issues and resources can remove mountains of ambiguity and save yourself loads of time filling in the blanks or worse, making assumptions.

Before we get into the details, we need to think about the motivations behind the madness. If we’re going to spend more time writing up descriptions and details, what do we get for it? Anytime you are writing words that another person will read, think about who that person is. It might be a new developer on the team who doesn't have your background knowledge or you in a few months. Maybe a project manager, maybe a stakeholder. Will a machine be able to read and interpret this? All of these factors should influence what you write, regardless of whether it is a description of a bug or a commit message. What information will the next person need so they can eliminate assumptions about the task? Keeping this concept in mind, consider the following benefits:

  • Hours of time spent onboarding a new developer could be reduced.
  • Determining who signed off on a ticket and the process they followed could be done by inspecting a commit’s notes.
  • Changelogs could be automatically generated in different formats for stakeholders and developers.
  • Stop cursing out the previous development team because you don’t understand why they chose a particular method.
  • Or worse, don’t waste your time refactoring that code, then reverting it because you finally did figure out why they chose a particular method.
  • Spend time developing instead of researching a ticket.

As you’re creating a ticket, a commit message, or a pull request; remove the space for assumption. Explain why you did what you did, and, if necessary, how. Let’s start at the beginning with the ticket queue.

Tickets

In this section, we’ll focus on the most granular of issue types: tasks and bugs. Epics and user stories have their own sets of rules and fall outside the scope of this article.

Ticket titles are the first field that someone reads. As I’m looking at my queue, I should know specifically what the ticket is intended to resolve by its title. Consequently, the title should describe the action that the ticket is to fulfill. Here are a couple of examples of good and bad versions of a ticket titles.

Good: “Prevent Nav Bar From Bouncing on Scroll”

Bad: “Navigation is Wonky”

Good: “Implement Home Page Right Rail Promo Block”  

Bad: “Homepage updates”

A helpful hint to consider when writing a title is that it should complete the phrase “This ticket will….” If you’ve done this correctly, the title will always begin with a verb; a call to action. When I see a ticket with the title, “Some Links are Yellow,” I think to myself, “Yes, yes they are. I’m assuming they shouldn’t be since you created a ticket, but what do you want me to do?  Should all links be yellow?  Or none of them?  What color should they be?”  Now, imagine you are a stakeholder reading over a list of completed tickets.  What would you think as you read this title?

Sometimes you’re going to need more than just the title to convey the complete purpose of the ticket, so make sure your ticket descriptions eliminate any room for assumption as well. For bugs, include the steps it takes to reproduce the issue, the environment where you encountered it (OS, browser, device, etc), and what the desired result should be. For simple tasks, reference any comps that describe how it should be implemented and consider user interactions if there are any.  The description field should provide extra information about the goal of the ticket.

If you are having trouble coming up with a specific enough title, consider breaking the ticket down into smaller subtasks, or promoting the ticket to an epic.

Branches

When you start your work, the best practice is to keep your main line of code clear by creating feature branches in your VCS to work on new tickets.  Branches should be filterable, recognizable, and attributable. That is to say, I want to be able to locate a branch quickly by who created it, which issue it’s tied to, and what it’s about.

I prefer a format like this: "owner/issue-id/short-description"

Which could end up looking like: "keyboardcowboy/proj-1234/fix_jumping_nav"

Think about who will see the branch names: myself, other developers, maybe a project manager, the repo gatekeeper if you have one, and machines. Using this format, I can now easily find my branches to create a pull request; I can check if anyone else has a branch for this ticket number; and I can allow project software, such as Jira or GitHub, to reference this branch by searching for the issue number pattern.

undefined Commit Messages

Developers may recognize the commit message prompt as that annoying thing GIT makes you do before you can push your changes. While it may be annoying when you’re working on your own, I guarantee that coworkers and your future self will appreciate the detailed messages you provide.

The reason for the commit message is to describe the changes taking place in that commit. If you find you can’t describe everything in one sentence, try breaking the commit into smaller, atomic commits. This makes it easier to roll back isolated changes if necessary and allows you to describe each change more succinctly. Just as with the issue titles, describe what the commit does. Someone else should be able to read it and understand to a basic degree what this change encompasses.

It’s also extremely helpful to precede the commit message with the issue number. The software can recognize certain patterns in commit messages and generate links from them. Tools like PHPStorm can help automate this for your process by integrating with GIT.

undefined

Here’s an example of well formatted, atomic commits vs a lazy commit.

Good Commits:

[proj-1234] Refactor white space in CSS so it’s readable. [proj-1234] Remove deprecated classes and definitions from CSS and templates. [proj-1234] Increase transition timing on navigation dropdown. The nav seemed to be jumping when the user scrolled while it was open. Increasing the transition timing allows it to expand and contract more smoothly and alleviates the jumpiness. [proj-1234] Fix merge conflict in update hook number.

Bad Commits:

Nav stuff.

Notice how the third good commit has multiple lines. The other commits in this set were ancillary to the issue.  The third commit is where the critical changes were made, so I explained my reasoning and why it fixes the issue. Without that, it looks like I just changed the timing. You might be able to trace the PR back to the original issue and piece things together, but a brief explanation directly in the commit can save time and headaches.

It may seem like overkill, but commits become very handy for the next developer, especially if you are using an IDE that integrates with GIT.

undefined Pull Requests

Pull requests are a common method to contribute to a project without needing commit access to the repository or to the main code branch.  The title of your pull request should follow the same structure as issues, but with one caveat; like tickets, they should describe the action that will occur if the code is merged, but they should also be prefixed with the issue-id of the issue they resolve. In GitHub, for example, the pattern "#ID" creates a link to that issue number. Even if you are not using GitHub as your issue manager, this is still an important reference, especially if you are running on a standard sprint cycle and need to generate reports for what was completed in each release.  Humans can follow this pattern to reference tickets as well as machines.

When you merge a pull request, a commit is made against the base branch and the title of the pull request is used in the commit message. Wouldn't it be nice if you could search through all the commits between release tags, find any that are pull requests and print them with references to their original issue as a change report? It’s surprisingly simple to automate that process if you follow these guidelines. Here’s an example of a good and a bad pull request title.

Good: “[PROJ-1234] Prevent Nav Bar From Bouncing on Scroll”

Bad: “Navbar Issues”

Imagine reading this as a code reviewer or a stakeholder trying to gauge what was accomplished in the last release. Which is going to be more informative? The title text describes exactly what was addressed, and the prefixed issue number provides the information needed to create a link directly to the original issue.

Just as with the original issue, you have an area for a summary in the pull request. I’ve found the most success in separating business discussions and technical review discussions between the issue management software and the pull request tool respectively. If necessary, provide testing instructions in the proper place and that your team follows any documentation guidelines consistently.

Automated Changelogs

Stakeholders often ask us to provide a list of everything that changed in the last release. Long sprint cycles and large teams can make this a challenge, especially if your issues, commits, and pull requests are vague.  The aforementioned guidelines not only make the project more understandable for people, but also for robots. On a project where the stakeholder required that an email is sent out after every release containing all the changes in that release, we used a simple, custom node script to pull all the commits made between tags and format them into a human-readable list using markdown. That list could be copied and pasted into various places, such as email and GitHub releases.  I’ve found a growing number of utility programs that attempt to do this or something similar. In a single command, you have a perfectly formatted, readable changelog, complete with links to the original issues!

Here are a few helpful tools I’ve found so far:

Documentation doesn't have to be boring and time-consuming. You can clarify your project with just a few simple refinements in your existing process and drastically reduce time spent writing up wiki documentation. Writing more detailed and informative tickets, commits, and pull requests will reduce sunk developer time, provide clarity for your stakeholders, ease your onboarding process, and provide better accountability and understanding throughout the project.

Do you have any suggestions or tips for documenting as you work? I’d love to hear about them!

Categories: Drupal CMS

Acquia Developer Center Blog: Working with BLT: An Automation Layer for Testing, Building, and Launching Drupal 8 Applications

Wed, 01/10/2018 - 06:57

Mike Madison, a Technical Architect in Acquia Professional Services, recently completed a Drupal site build for a major public transit agency in the United States. We spoke with him about his experiences using BLT -- an open-source Acquia product that provides an automation layer for testing, building, and launching Drupal 8 applications -- on this project. Mike said that BLT has been a critical component of the project’s success, and has especially helped in three primary ways: by accelerating project spin-up, improving developer onboarding, and increasing development velocity and delivery consistency.

Tags: acquia drupal planet
Categories: Drupal CMS

Mediacurrent: Do Drupal and Digital Right in 2018: Know Where and How to Start

Wed, 01/10/2018 - 06:30

When you’re solely focused on Digital Strategy and Drupal as your open source website and web application development framework like Mediacurrent has been for the last 10 years, you’re deeply invested in all of the great challenges and rewards that come with delivering products and solutions that are essentially only limited to your creativity and what you can dream up.

Categories: Drupal CMS

Valuebound: My first impression of learning AngularJS

Wed, 01/10/2018 - 05:07

Before we delve into the ocean of understanding and learning curves of AngularJS, let me share my insights and experience of working on web development. Later, I will tell you why experiences are worth sharing.

For the past four-and-a-half years, I have been working in an IT industry. Started my career as a Drupal developer, working on web building, site building, extending features, development as well as designing. During this journey, I came across many technologies which I was expected to learn from scratch to bind/ integrate one to another. 

Cutting a long story to short! So why did I started learning AngularJS? What is the scope of AngularJS? And why I am sharing my experiences with…

Categories: Drupal CMS

Glassdimly tech Blog: Overriding Drupal 8's .eslintrc.json File in Your Theme With Extends

Tue, 01/09/2018 - 14:44

I had to do a little RTFMing today, and so I thought I'd post about it.

First of all, this is how you set up PhpStorm to use ES6 eslint settings. You may find it useful

Is the linter getting in your way? The first way to override an eslint setting is inline, disabling it on a one-off basis.

Categories: Drupal CMS

Glassdimly tech Blog: Drupal ES6 Linting in PhpStorm. Or, PhpStorm Drupal Error: Cannot find module 'eslint-config-airbnb'

Tue, 01/09/2018 - 12:40

You may not know this, but support for ES6 was added in Drupal 8.4. It wasn't in the release notes, but I was delighted to learn of it.

You have probably landed here because you have gotten Error: Cannot find module 'eslint-config-airbnb'.

Categories: Drupal CMS

DrupalEasy: Mastering Pantheon Workflows (especially these 5 elements) is Awesome

Tue, 01/09/2018 - 12:28

The following is a guest blog post by Brian Coffelt.

Train to Reign

I’m surprised often by the slow adoption rate of quality development workflows. Time probably plays a big part. One thing I have experienced though, is that in order to get the full value of tools, especially software, you really need to spend the time learning how to use them properly.  

Since I changed my career to become a Drupal developer, I haven’t had a day of regret, nor a day when I did not realize that the key to success is learning more: More about the software, more about techniques, and more about the tools that make Drupal development better. It all feeds into what I learned early on in DrupalEasy’s Career training program, and that I still feel are the best parts of this amazing Drupal-based vocation: to create quality work and become part of the Community.

So when I had the chance to take DrupalEasy’s Mastering Pantheon Workflows course, I jumped at it.  I have been relying on (and loving!) Pantheon’s website management platform since my early career training, and am a huge fan of the great workflow and development tools it offers.  The Workflows class, which is several afternoons a week for six weeks, was time truly well spent. It taught me to really leverage Pantheon’s advantages, and has made me a better developer.

Top 5 Takeaways

The quality of the curriculum and instruction of this course are second to none.  I mean it. DrupalEasy’s insight on what is important provides tremendous value to the time spent in the class and honing your skills. As any professional web developer knows, a great development workflow is worth its weight in gold. This class helped me learn a Docker-based local development workflow that has been directly applied to my everyday routine as well as that of my team.  In addition, learning how Composer manages dependencies was an eye opener for me. It allows my projects to be very lean, efficient, and modular. There are plenty more topics I can point to, but the top 5 area’s we covered that make my day-to-day better and easier are:

  1. Composer integration and dependency management
  2. Drupal 8 configuration management (exporting & importing)
  3. Docksal/Lando local environment structure & setup
  4. Higher level Terminus commands
  5. Development workflows between Pantheon environments and local

The instruction, either direct or via additional screencasts, was always thorough, well planned, and thoughtful. The instructor, Mike Anello (@ultimike), always allows time for questions and troubleshooting. Integrating a class Slack channel was valuable for questions and troubleshooting between classes as well as resource sharing (links, documents, etc.). I still keep in contact with my classmates as often as I can via Slack, email or Drupal events.

Worth the time

It may seem like a few afternoons a week for six weeks will chew up your schedule, but in fact, the opposite is the case. The skills acquired from this class can immediately boost your production, proficiency, and overall value, all of which are well worth the financial and time commitment.

I am definitely a better Drupal developer after having taken the Workflows course. The knowledge, experience, and overall comfort level I achieved has given me valuable skills that I use and share with others every day. The class always stresses the pursuit of best practices to minimize development time and maximize results. I recommend this course to Drupal developers looking to streamline their Pantheon development workflow. It’s certainly well worth the investment.

DrupalEasy’s next Mastering Professional Drupal Development Workflows with Pantheon course starts in February.  Contact DrupalEasy for more information.

Categories: Drupal CMS

Pages

1 2 3 4 5 6 7 8 9 next › last »