Drupal Planet

Subscribe to Drupal Planet feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 51 min 39 sec ago

Drupal.org blog: An update on the Developer Tooling Initiative for Drupal.org - Part 1

December 20, 2017 - 1:20pm

The initiative to improve Drupal.org's developer tools is part of a broader effort to broaden the reach of Drupal, not just to end-users and evaluators, but to a wider audience of developers as well. Improvements to our tools are an opportunity to remove friction to changes, increase the quality of changes, improve velocity of changes, and make contributing to Drupal delightful.

The initiative began in coordination with Drupal Association Staff, the Technical Advisory Committee, and a small group of volunteers from the community. We first announced the initiative in October of 2016, and provided our last update at the end of April of this year. Since that time a great deal of work has been underway to evaluate and prototype our options, collaborate with the vendors who supply these toolsets, and make some decisions about the direction we want to move in, with more data in hand.

Buckle up! Because this is such a large topic we've broken it into multiple posts:

Want a TLDR?

Where do we stand now?

Drupal is one of the longest-running open source projects on the web, and for more than 15 years (and many more to come), Drupal.org has been the home of the project. Over the years, we've built a developer toolset to serve the unique needs of the project. These tools have evolved as the open source environment changed. Right now, we use a combination of best-of-breed third party technologies, such as Git, Jenkins, Fastly, OpsGenie, integrated with our own bespoke tools, including issue queues, project pages, etc.

Right now, some of the third party and bespoke tools that we are using are market leading, whereas others have fallen behind. For example, CGIT (third party) and the patch workflow (bespoke) have both fallen behind compared to toolsets that can be found on other tooling providers. On the other hand, our issue crediting system (bespoke) is market leading, and a model for other projects to follow.

In the end, we will always be negotiating a balance between what we can do uniquely well with bespoke solutions, and integrating the latest and greatest of third party solutions as they coalesce around best practices that we want to adopt as well.

At DrupalCon Vienna it was decided that the Technical Advisory Committee had fulfilled their threefold mandate:

  • Helping the technical leadership transition on the DA engineering team after the downsizing in summer of 2016.
  • Helping manage the prioritization and scope of work.
  • Making recommendations to the board and DA staff on key initiatives, such as the project application process changes, and the direction to take with our developer tools.

We want to thank Angie Byron, Steve Francia, and Moshe Weitzman for serving on the committee. From here, DA engineering staff will carry the torch, though we will continue to rely on the individuals who were part of the TAC and other volunteers for feedback and help from time to time as we move forward.

Our evaluation

The most recent phase of this initiative was an evaluation of the leading contenders for open source tooling providers that Drupal.org could integrate with. These options were GitHub and GitLab, and after setting out to develop prototypes for these options, we added BitBucket to the list as well. For each of these options we built MVP prototypes, either as integrations with Drupal.org development environments, or with private organizations/repositories. Finally, we wanted to compare these options to the bespoke Issue Workspaces solution that we had proposed several years ago.

The Criteria

For the Developer Tools initiative to be successful we have to understand the criteria for improvement. From a user requirements point of view, contrib and core developers are unique stakeholders with unique requirements. Ideally we want a solution that increases velocity for both types of users, without fundamentally sacrificing the needs of one or the other.

  • Adopt a developer workflow that will be familiar to the millions of developers outside our community.
  • Preserve those unique elements of how we collaborate that have made the Drupal project so successful.
    • Many-to-one collaboration: that is to say, many developers collaborating on a single solution to a problem.
    • Issue workflow.
    • Picking up on long standing issues where other collaborators left off.
    • Contribution credit.
  • If possible, leverage an expert partner who will help keeping our tooling up to date as open source collaboration tools continue to evolve.

There are also some technical requirements that came out of our evaluation process.

  • Retention of our data/ability to migrate.
    • Where possible, retain existing Git remote urls for projects.
  • Maintainability for a small staff.
  • Project maintainer management: including abandoned project reassignment, fork control, security release management, etc.

In terms of features, we were looking for:

  • Merge/pull requests.
  • Code review.
  • Inline editing.
  • Branch permissioning to allow collaboration on merge/pull requests.
  • Administrative tools for managing project maintainership.
  • Project management tools that equal or exceed what we have with the issue queues.*
  • Extensibility, so that we can preserve areas where the Drupal project is a market leader, such as with our contribution credit system.

*Our tools for issues are very sophisticated on an individual issue level, however we are sorely lacking in tools for grouping and prioritizing sets of issues, ie: issue boards.

Finally, cost:

  • Given the care with which we must use our funding from the community, any option we consider must be cost neutral with the current cost of maintaining our tools.

It's difficult to condense the scope of our evaluation into a short blog series, but in the following posts we'll talk about how the options we considered measured up to these criteria, what implementing one of these options could look like for Drupal.org, and our suggested implementation roadmap.

In our next post:

Our tooling options, compared.

Categories: Blogs

Platform.sh: A look back on 2017

December 20, 2017 - 1:07pm
A look back on 2017 Crell Wed, 12/20/2017 - 17:07 Blog

Time flies. It's been quite a year for Platform.sh as our product continues to improve. One of the great things about a managed services product is that it can continually improve without you even realizing it. The sign of a successful product feature is that it feels like it's always been there. Who can imagine life without it?

Let's take a look at what we've improved just in the last 12 months...

January opened with support for HTTP/2 on all projects. HTTP/2 changes the way browsers and servers communicate, making it faster, more streamlined, and better tailored to modern, asset-heavy web sites. HTTP/2 "just works" automatically as long as you're using a reasonably modern browser and HTTPS.

And as of April, you're using HTTPS. Courtesy of Let's Encrypt, you now get a free, automatic SSL certificate provisioned for every environment. No one should have to think about HTTPS in 2017. It's just a part of the package.

April also saw the launch of our tiered CDN for Platform.sh Enterprise. The Global CDN combines a flexible, high-feature CDN for dynamic pages with a low-cost, high-bandwidth CDN for static assets. That offers the best of both worlds for sites that want the best performance for the least cost.

We've also continued to expand our available services. We kicked off the year with support for persistent Redis as a key/value store rather than just as a cache server. March saw the addition of InfluxDB, a popular time-series data service for recording time-based data. In June, we added support for Memcached in case Redis doesn't do it for you.

We also beefed up the functionality of our existing services, adding support for multiple-core Solr configurations and multi-database MySQL configurations. We even now support regular expressions in the router for more fine-grained cookie control.

And of course we've kept up with the latest releases of your favorite languages, be that Python, Ruby, NodeJS, or perennial favorite PHP 7.2. We even added preliminary support for Go and Java, both of which are in beta now. (Interested in trying them out? Please reach out to us!)

August included support for arbitrary worker processes in their own container. That allows an application to easily spin up a background task to handle queue processing, image generation, or other out-of-band tasks with just a few lines of YAML with no impact on production responsiveness.

As of October, we've added health notification support for all projects. At the moment they only cover disk usage, but in time will expand to other health notices. (If you haven't configured them on your project yet we strongly recommend you do so.)

We're also closing out the year with new support for GitLab, as well as more flexible control over TLS and Client TLS, plus a few other changes that line us up for even bigger things in the year to come.

Last but not least, all of that goodness is available down under as of July with our new Sydney region for Platform.sh Professional.

And that's all been just this year! What do we have coming in 2018 to further redefine "modern hosting"?

You'll just have to join us in 2018 to find out...

Larry Garfield 29 Dec, 2017
Categories: Blogs

Dries Buytaert: Clean CSS with Stylelint

December 20, 2017 - 11:29am

Last night I was working on the album functionality for this website. CSS is not my strong suit, so I wanted to get some help from a CSS linter. A CSS lint tool parses your CSS code and flags signs of inefficiency, stylistic inconsistencies, and patterns that may be erroneous.

I tried Stylelint, an open source CSS linter written in JavaScript that is maintained as an npm package. It was quick and easy to install on my local development environment:

$ npm install -g stylelint stylelint-config-standard stylelint-no-browser-hacks

The -g attribute instructs npm to install the packages globally, the stylelint-config-standard is a standard configuration file (more about that in a second), and the stylelint-no-browser-hacks is an optional Stylelint plugin.

Stylelint has over 150 rules to catch invalid CSS syntax, duplicates, etc. What is interesting about Stylelint is that it is completely unopinionated; all the rules are disabled by default. Configuring all 150+ rules would be very time-consuming. Fortunately you can use the example stylelint-config-standard configuration file as a starting point. This configuration file is maintained as a separate npm package. Instead of having to configure all 150+ rules, you can start with the stylelint-config-standard configuration file and overwrite the standard configuration with your own configuration file. In my case, I created a configuration file called stylelint.js in my Drupal directory.

"use strict" module.exports = { "extends": "stylelint-config-standard", "plugins": [ "stylelint-no-browser-hacks/lib" ], "rules": { "block-closing-brace-newline-after": "always", "color-no-invalid-hex": true, "indentation": 2, "property-no-unknown": true, "plugin/no-browser-hacks": [true, { "browsers": [ "last 2 versions", "ie >=8" ] }], "max-empty-lines": 1, "value-keyword-case": "lower", "at-rule-empty-line-before": null, "rule-empty-line-before": null, }, }

As you can see, the configuration file is a JSON file. I've extended stylelint-config-standard and overwrote the indentation rule to be 2 spaces instead of tabs, for example.

To check your CSS file, you can run Stylelint from the command line:

$ stylelint --config stylelint.js --config-basedir /usr/local/lib/node_modules/ css/album.css

Stylelint will point out errors, automatically fix some stylistic violations, or highlight where your rules are violated. In my case it found an error that was easy to fix:

For fun, I googled "Stylelint Drupal" and found that Alex Pott has proposed adding a Stylelint configuration file to Drupal core. Seems useful to me!

Categories: Blogs

Amazee Labs: Zurich Drupal Meetup January 2018

December 20, 2017 - 7:49am
Zurich Drupal Meetup January 2018

Join us on January 18th for the first edition of the Zurich Drupal Meetup, where we will discuss the possible future of  React, GraphQL and Drupal at the Amazee Labs Zürich office.

Vijay Dubb Wed, 12/20/2017 - 12:49

In the Meetup, Amazee Group CTO and Partner, Michael Schmid, will lead our discussion and address the following issue:

The idea of a decoupled Frontend and Backend has been around for a couple of years. Some teams tried them out, but nobody was entirely satisfied with it. Too many problems arose during development; bad or non-existing accessibility, no support for crawlers and bots, changing APIs and expensive refactorings. Even the simple task of displaying a menu on the frontend was problematic.

All these concerns retained us at Amazee Labs from actually trying it. We avoided the use of decoupled systems. That is until a couple of months ago. In summer 2016, we were able to connect React with Drupal via GraphQL for the first time, and felt comfortable using it in a project. To increase the stakes we applied it in a multiple hundred-thousand dollar projects. We wouldn't be Amazee if we didn't! 

What came out is a completely decoupled system built on React that powers 12 individual websites with a single Drupal Backend connected through GraphQL. All of it is completely tested as part of a continuous deployment workflow, is hosted on Docker, has server-side rendering, and not a single line of content or menu on the frontend.

As one of the leading Drupal and React agencies, we always look towards the future. We would like to take the opportunity to plan community activities for 2018 and beyond. Here is a list of topics we are looking to address:

- Define overall goals for Drupal in Switzerland 2018
- Fix dates & contents for meetups for the Zurich Drupal Community
- Pre-discuss planning for the next Drupal Mountain Camp

Come for great talks, people and networking. Sign up here at meetup.com

 
Categories: Blogs

Agiledrop.com Blog: AGILEDROP: Drive greater business value with deeper integrations

December 20, 2017 - 7:18am
While the first blog post of the series covered the meaning of words ambitious and digital experiences both as singular and combined entities, and the second blog post was dedicated to channels of communication and interaction, I will now turn the attention over to the possibilities of integrations with Drupal.    How small is too small There is quite a substantial gap between what is characterized as for the enterprise and as for an ambitious digital experience. The latter is far broader. In more than one way. The most obvious being, as it is not just for the enterprise, you can also… READ MORE
Categories: Blogs

Aegir Dispatch: Ægir Rules

December 19, 2017 - 8:00pm
Aegir faithfully runs a lot of tasks for us, but sometimes one can fail for various reasons. That could be as simple as a filled up disk or a remote Git server that’s unavailable. When you’re logged in, you can quickly see what’s going wrong. But with more and more automation, there are days when you’re not watching the Aegir dashboard of your server. It could run a Git pull task because someone committed new code for the site you’re hosting, or a Let’s Encrypt certificate is being renewed.
Categories: Blogs

Promet Source: Drupalcamp Cebu 2017 Up Close

December 19, 2017 - 6:54pm
Another Drupalcamp event had just successfully ended in Cebu! Wait... Where is Cebu?
Categories: Blogs

Acro Media: Video: How Drupal Delivers a True Omnichannel Experience

December 19, 2017 - 5:43pm

The term "omnichannel" has been around for a long time, but in a lot of cases it was just a buzzword.

We talk sometimes about omnichannel being online and in store, but in reality, it refers to all the channels that are available to your customers. That's call-in orders, customer service, catalog orders, integrations with other fulfillment partners like Amazon or eBay—those are all channels through which you sell products.

Omnichannel is about having all those channels work together. So if Joe buys something online, for instance, he should be able to return it to the physical store, and the customer service rep in the store should be able to see his updated account history, because everything should sync up.

In the early days, basic omnichannel really just meant that if the product showed on the website, it was also in the store. But these days, omnichannel is also about customizing the experience for each channel.

So if Joe is on the app, it should automatically pick his closest store. It should show him what aisle or section the item is located in and whether its in stock. On the other hand, if Joe is buying online, he doesn't care what aisle it's in, he just wants to know how long it will take to get the item shipped to him. So you have to tailor the experience to each type of channel, but the systems all need to mesh together.

What can you expect from the omnichannel experience from most platforms?

You will generally get rudimentary stock syncing. That means that whether you sell items online or in store, you will know how many you have and when you're out of stock. But even that has variations. Do you know your inventory status in real time? Every hour? Or does it only sync nightly? That can make a big difference.

With most platforms, you're not going to get features like the ability to inform the customer where the item is located in the store. Only a few retailers do that because it's very difficult and requires a lot of extra work. You need to know that data, for one thing. So even if the platform supports that, that doesn't mean that you actually track the precise location of every single product in your store.

What's different with Drupal?

With Drupal, syncing is simple because we can use the same platform for everything: we have a point of sale, we have a web platform, and we can automatically do pushes to different channels like Amazon and eBay. We have real-time stock and shipping.

Then we can add more customizations. We can allow for your customers to start an order online and finish it in store, for instance. Or if they go into the store and find it's not in stock, the clerk can put in an order—but instead of it getting shipped to the store and the customer having to come and pick it up, the clerk can simply turn it into an online order and have the item shipped to the customer. This is the kind of stuff we can mostly do out of the box, but there's usually a bit of customization work to make it a smooth flow.

What's the deal with add-ons?

Drupal is well set up for omnichannel, but keep in mind that there can be problems any time you integrate with other systems. Payment gateways are usually not a problem, but you can run into issues if you have to pass data to some warehouse fulfillment system and it can't provide real-time stock info back. So Drupal can keep track of stock, but if they knock over a pallet in the warehouse, or they get a new shipment but take a while to put it in, that can be slow to update. So the caveat here is that you can be let down by other parts of your system.

Chat with us

If you'd like to how Drupal Commerce fits into your omnichannel solution, give us a shout. We're here to help.

Categories: Blogs

qed42.com: Art of writing template files - Drupal 8

December 19, 2017 - 4:49pm

When it comes to Drupal 8 theming layer, there is a lot Drupal 8 offers. Few concepts that come to mind while thinking of Drupal 8 theme layer include Renderable Array, Cacheabilty, Cache Context, Cache Tags, Twig and Preprocessors. Some of these are improvements of old concepts, while others are new introduction in Drupal 8. In this post, I'll share my experience on how to best utilise these concepts for a robust and performant frontend with Drupal 8.

To get best out of this post, you should be comfortable with:

  1. Drupal 8 #cache
  2. Twig Debug
  3. Preprocessor functions


We will focus on the following concepts:

Renderable array caching, walk through Drupal 8 caching power and Cache contexts

Drupal 8 comes with a lot of changes and almost all of us are even familiar with these changes. So, now it’s high time we start exploiting these to get best out of Drupal 8. It’s very important to understand how Drupal 8 caching works. Go through drupal.org documentation besides implementing the same once thoroughly on a vanilla Drupal instance. At the end have an answer to all these questions:

Categories: Blogs

Drupal Association blog: Call for Proposals: DrupalCon Europe License

December 19, 2017 - 2:09pm

The Drupal Association’s mission is to unite the global open source community to help them build and promote Drupal. One of the most important ways that we advance our mission is through DrupalCon, Drupal’s flagship event.

At DrupalCon, community members with a technical, business, and marketing background come together to unite as a community, level up their Drupal skills, and contribute to the project. As a global event, DrupalCon breaks down walls between countries and the various personas who build, use and support Drupal, making it an accelerator of knowledge sharing, relationship building and contribution.

DrupalCon is ready to grow.  We need a model that allows the community to deliver DrupalCon globally. Our vision is to empower all regions to host DrupalCon, providing this experience to communities around the world.  As a first step, we are licensing DrupalCon to the European region.

We are excited to empower a new entity grounded in the European Drupal community to take this special event to the next level. The DrupalCon license initiative is an opportunity to re-imagine DrupalCon Europe to uniquely serve the Drupal community. The license is designed to allow for a new creative direction while enhancing Drupal’s mission, vision and values while maintaining the integrity of DrupalCon.

With the help of the DrupalCon Europe License Committee, we created a process for entities to apply for a DrupalCon Europe license by 30 March, 2018. We reviewed approaches used by other conference organizers, with particular attention to the key attributes that allow TED to scale its TEDx events. Then, we applied those learnings to our licensing process.

In short, we learned that TEDx scales because of clear “rules and tools” for the licensee (aka event organizer) and we aimed to provide the same level of guidance and support for the DrupalCon licensee. There are clear guidelines in the license agreement and the event rules and we will provide support in the form of knowledge transfer, tools, and advisory services. We also recognize that this is our first time creating such a program, so we encourage entities who are applying to contact us to discuss any areas of concern or question.

Below details how to submit a proposal for the DrupalCon license and the criteria that the Drupal Association will use to select the licensee.

We are grateful for the help of Bert Boerland, Baddy Breidert, Alex Burrows, Gabor Hojtsy, Janne Kalliola, Zsofi Major, and Stella Powers, who participated in the DrupalCon Europe License committee and contributed many hours and great insight into this process.

Table of Contents
  • Key Points
  • Who Can Apply For a DrupalCon License
  • Important Dates
  • What To Submit To Apply for a DrupalCon License
  • DrupalCon License Rules
  • Drupal Association Support
  • Decision Making Criteria
Key Points Who Can Apply For a DrupalCon License

To be eligible to apply for a DrupalCon license, you must meet the following criteria:

  • An entity grounded in the voice and needs of the Drupal community. This can include, but is not limited to:

    • A professional event company

    • A Drupal community group

    • A collective of Drupal businesses

    • A Drupal business

    • An event organizing company that demonstrates how they will work with the Drupal community

    • An entity where someone on the team has event experience

  • Able to accept funds as a business or nonprofit

  • Must have successfully produced an event that broke even or was profitable. Or, the team member with event experience has worked on an event that broke even or was profitable.

  • Must agree to abide by and enforce DrupalCon’s policies and rules.

Important Dates

Above is a timeline of important dates to know. The call for a DrupalCon license proposal is now open and it closes on 30 March, 2018. In mid to late April, applicants will be interviewed and a licensee will be selected by the Drupal Association in May 2018.

As early as July 2018, The Drupal Association will provide an onboarding workshop to the licensee, to begin knowledge sharing, and map out how best to support the event organizer leading up to and during DrupalCon.

What To Submit To Apply for a DrupalCon License

To apply for the DrupalCon license, please submit the following items by 30 March, 2018 to DrupalConEurope@association.drupal.org. Your application must include the items listed below in the following formats (presentation, spreadsheet, document).

  1. DrupalCon Business Plan. Submit a business plan with the following information:

    • Event location and dates.

    • Detailed event budget, structured as similarly as possible to the current DrupalCon budget format.

    • Budget assumptions. Clearly define the budget assumptions for expenses. Also, include forecasted ticket and sponsor revenue. Define your ticket pricing plan and your sponsor strategy (who you will sell to and how you will create value for sponsors). Additionally, explain how you will secure the cash flow for initial event investments like securing the venue.

    • Details about your event team. Who are the key people on your team, what roles will they play, and what is their event experience?

    • An overview of how you will ensure the event reflects the Drupal community's needs and culture and moves the project forward.

    • The event’s mission and vision, which should align with the Drupal Association’s mission and vision.

    • Target audience and target size. Which personas will your event attract and generally in what ratio? Please define your personas.

    • Event goals, strategies and objectives

    • What value will you bring to each persona and how?

    • Programming concept overview (which we know can change as you get further into planning). Please be sure to adhere to the programming rules.

      • Event duration

      • Provide a sample program and suggested tracks

      • Share your general concept for session selection

      • What is your plan to ensure conference diversity (attendees and speakers)

      • Tell us about some aspirational keynotes you would like to invite

  2. Drupal culture. Tell us how you define Drupal’s community spirit and culture and what it means to you.

  3. What’s your “why”. Tell us why you want to organize DrupalCon. Why should you be selected, and how will you maintain the Drupal community spirit.

  4. Your needs. As seen on page 4, the Drupal Association will support you with knowledge sharing, tools, and advisory services. What additional needs do you have?

  5. About your past events. Submit an overview of your past event that you, your event partner, or your team member worked on. Describe the event audience, audience size, goals, and how you achieved those goals along with the event’s financial statements.

The Drupal Association will select the organizer who can demonstrate the best approach for creating value to a technical and non technical audience by uniting the community, leveling up Drupal skill, and accelerating the project through a sustainable model.

DrupalCon License Rules

The DrupalCon license is designed to encourage creativity, to re-imagine the event. That means you can decide what is the best programming to meet the attendee’s needs. Or you can decide that sustainability is best achieved by starting with a smaller event that grows over time. However, all proposals and the actual event must conform to the DrupalCon licensing rules and agreement to maintain the Drupal Association’s community and governance expectations, as well as DrupalCon’s brand experience.

You can find DrupalCon Rules here.  

You can find the DrupalCon license agreement here.

Since this is the first time the Drupal Association has crafted DrupalCon license rules, we are open to discussion. Please contact us if you feel a rule is a blocker to you submitting a proposal. If discussions result in a rule change, we will update the rules document to reflect that change.

Drupal Association Support

The Drupal Association wants to make sure the chosen event organizer is set up for success. We recognize this means that we will play a role leading up to and perhaps during the event. Here are some ways the Drupal Association will help. We are open to hearing about additional ways in which we might help.

  • In-person workshop: The Drupal Association staff will fly to the organizer’s location to run a workshop where we will do a knowledge transfer, training, and determine how the Drupal Association will play a support role during the event production phase.

  • Playbooks, Guidelines, and Templates. The Drupal Association has several production playbooks that we will share so the organizer can see how the event was produced in the past. We recognize that the event organizer may want to alter our approach or create a brand new one.

  • Advisory Services. You may have questions along the way and we are here to help. No question will be too big or too small. We can set up periodic check in meetings to provide guidance as you develop your event.

  • Access to tools. DrupalCon promotion and management relies on several tools that we will share with the event organizer including the DrupalCon event site, social media handles, access to DrupalCon email lists, etc.

  • Promotion Support

    • The Drupal Association can amplify your call for ticket sales, sponsorship, and content through our channels including social media, email, newsletters.

Decision Making Criteria

When reviewing and comparing proposals, The Drupal Association will select the event organizer by using the following criteria:

Category

Topic

Weight

Sustainability

Conservative, realistic, complete budget plan with clear revenue and expense budget assumptions

10

Staffing plan

Clearly defined leadership team description and a staffing plan for producing the event that is designed to avoid burnout

8

Goals, strategies, objectives

Clearly articulated goals, strategies, and objectives that move the project forward, serve multiple personas, and has achievable metrics.

9

Location

Easy to reach by European community

8

Event Dates

Avoids major holidays (national, religious, etc) and aligns with Dries Buytaert’s availability

10

Target Audience

Program serves multiple personas

8

Programming

Creative approach for serving all persona  while meeting the licensing rules.

9

Session Selection

Well thought out approach that adheres to the DrupalCon licensing rules.

7

Diversity & Inclusion

Well thought out approach for growing speaker and attendee diversity to exceed the DrupalCon Vienna benchmark

8

Definition of spirit/ culture

Strong understanding of the Drupal culture

7

Keynote examples

Creative, inspiring keynote ideas that speak to all personas

6

Event Planning Experience

Clear demonstration of event experience on the team

7

Categories: Blogs

Acquia Developer Center Blog: A Look Inside Decoupled Architecture: The Engage Digital Application

December 19, 2017 - 1:07pm

“The most compelling advantage of API-first Drupal is not the way it negates Drupal's presentation features, it's the way it enables the capabilities of the CMS to power multiple applications and devices. Leveraging Drupal as a centralized data source enables authors to deliver content to multiple devices outside of Drupal, while leaning on the strength of the CMS editorial workflow and patterns.” -- Jason Enter, Manager Technical Services, Acquia.

Tags: acquia drupal planet
Categories: Blogs

Jacob Rockowitz: Drupal 8 and the Webform module helps NYC online voter registration bill get passed

December 19, 2017 - 1:04pm

My family and I got to see Mayor Bill de Blasio sign the online voter registration bill into law which Ben Kallos, a New York City councilman and true fan of Open Source, sponsored. Kallos used the Webform module to demonstrate how easy it easy it is to capture a digital signature. The most ironic thing about watching the mayor sign the online voter registration bill, which is driven by the concept of digital signatures, into law, was the fact that he used used multiple pens to sign the bill. My daughter Lili and I both received pens that the mayor used to sign the bill. Everyone, myself included, has Kallos to thank for making this bill and experience happen. I guess - and this is a good thing - we’ll have to find other uses for our pens.

Last month, Kallos did a presentation at the NYC Drupal Meetup about how he used the Webform module to help get legislation passed to allow online voter registration for New Yorkers.

 

We all know that we can’t vote online yet, but I was surprised to realize that people can’t even register to vote online! Sure governments and municipalities move slowly, but how hard should it be to set up an online voter registration application? There is even an online HTML form that generates a filled-out PDF form that you have to print out, sign, and mail in. Next, someone manually re-enters your information, with no typos…duh. Kallos gets technology, which is why he sponsored this legislation and tackled the real challenge of showing his fellow council members how to capture a digital signature, which is essential for registering...Read More

Categories: Blogs

Droptica: Droptica: Building a big website? Here are ten reasons why you should be using Drupal

December 19, 2017 - 7:24am
When you’re building an advanced website, you can choose from among many technologies. Usually, the first choice is the programming language (PHP, Python, Java, ASP.NET, etc.) and then we decide whether we should code everything from scratch or use a framework to do all the heavy lifting. There is also a third choice, a more comprehensive solution –so-called CMF systems, which stands for content management framework. Drupal 8 is one of these systems. In this article, I will tell you why it’s worth it to choose Drupal as the basis for any large and advanced website.  By large and advanced, I mean one that is changed frequently. Content changes are carried out by at least one editor, supported by at least one developer (along with a QA tester and a sysadmin), who’s responsible for continuous development of the website, adding new functionalities, fixing the emerging bugs and so on.  Some examples of large and advanced websites:
Categories: Blogs

Amazee Labs: Client Interactions - Amazee Agile Agency Survey Results - Part 8

December 19, 2017 - 7:24am
Client Interactions - Amazee Agile Agency Survey Results - Part 8

This is part eight of our series processing the results of the Amazee Agile Agency Survey. Previously I wrote about estimations, this time let’s focus on client interactions. How regularly does the team meet the client and how is communication between the team and the client handled?

Josef Dabernig Tue, 12/19/2017 - 12:24 Client Meetings

When asked about “how regularly does the team meet the client”, 33% mentioned “more or once per week”, 30% selected they would meet “less frequently” compared to the 16.7% which chose “every two weeks”. This is followed by 6.7% that chose to meet clients “each day for the daily standup”, and the same amount chose to meet clients “never”. It looks like there is no apparent tendency but half of the teams choose to work together with clients more regularly, and another half of the team doesn’t have much client interactions.

For us, at Amazee this depends heavily on the project and the teams. In some cases we form teams together with clients where all developers will be assigned to the project full time in that consequence have regular client interactions. For the stable Scrum teams in Zurich that I work most with, we run multiple projects at the same time and therefore didn’t consider inviting clients to our daily meetings as we discuss several projects at the same time. As we have been successfully moving towards having fewer projects per team and a global maintenance team, we are considering this option though as to have closer client interactions between the team members. On top of that, we have found regular demos for clients and grooming meetings between the teams and clients beneficial. We balance the decision to do them based on how much money the client is willing to spend on having multiple people at a meeting.

Client Communication

In a second question, we asked “How is communication between the team and the client handled” and contestants could choose from a scale of 1-5. The lowest indicates communication is handled “exclusively by a person dedicated to talking to the client (PM, PO proxy, ...)”, and the highest, indicates that communication is handled “Always together with the entire team”. An equal share of 33% turned out to be with a 2 or a 3, 13.3% with a 1 or a 4 and 6.7% with a 5. We can see that there is a tendency to channel communication between clients and the team through a person within the company (PM, PO proxy).

For us at Amazee its a 2. Every project has a PO from our side assigned that will represent the client to the team if the client is not available and will represent the team to the client to have a single point of contact. Still, we encourage clients to meet the team regularly for a better understanding on both sides of the project and collaboration. The higher the ratio is that a team can dedicate their time to one project & customer, the easier it is to justify that the entire team will collaborate with the client. Being in an agency environment with multiple projects at the same time, those customers are not often to be encountered though. This is why we try to find a good compromise between customer collaboration with the team and efficiency gains of channelled communication.

How do you and your team interact with your clients? Please leave us a comment below. If you are interested in Agile Scrum training, don’t hesitate to contact us.

Stay tuned for the next post where we’ll look at agile practices.

 
Categories: Blogs

Digital Echidna: Thoughts on all things digital: Putting Our Best Foot Forward Against Bullying on For Me Day

December 19, 2017 - 5:12am
Bullying is a major problem in our schools, workplaces, homes, and over the Internet. Over the next 14 months, Digital Echidna is supporting a series of mental health awareness campaigns, in particular those with an emphasis on inclusion and…
Categories: Blogs

Last Call Media: LCM Drupal Scaffold 2.0

December 18, 2017 - 10:00pm
LCM Drupal Scaffold 2.0 Rob Mon, 12/18/2017 - 21:00

Last year, we released an ambitious project to open source our own internal workflow. We called it the Last Call Drupal Scaffold (definitely not the most original name), and we presented it to the world at several different camps and conferences, including Drupalcon Baltimore.

Categories: Blogs

Agiledrop.com Blog: AGILEDROP: What do developers joining Drupal need to know before they start?

December 18, 2017 - 8:02pm
Did you decide that you want to become a Drupal Developer? Congratulation! That is a great decision. As a Junior Drupal developer, you are going to face some of the challengers. Do not worry; every Drupal developer needed to go true this. But what skills do you need to join Drupal community? Are there any particular tools that you need to me familiar with? Jup, there is some knowledge you need to conquer before you enter Drupal coding and let's see the list of important skills, concepts, and tools that we think you should already know as a beginner in Drupal.    1. PHP language Every… READ MORE
Categories: Blogs

Xeno Media: Web Accessibility Part I: Do we still need to ask?

December 18, 2017 - 4:06pm

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”

Tim Berners-Lee, 1997

What exactly is web accessibility?

Web accessibility is the removal of technical impediments that could limit access to or interaction with a website by any person with disabilities. The goal of a web accessible site is to allow all users equal access to all content and functionality. 

Some disabilities that web accessibility can address
  • Visual: Visual impairments up to and including complete blindness, various common types of poor vision, color blindness

  • Motor Skills: Difficulty using hands, tremors, Bradykinesia, loss of detailed muscle control, etc., due to conditions such as Parkinson’s, MS, stroke, and other movement disorders

  • Auditory: Hearing impairments up to and including total deafness and including the hard of hearing

  • Cognitive: Cognitive impairment and learning disabilities (Dyslexia, Dyscalculia, etc.) that may affect memory, attention, problem-solving and logic skills.

Temporary Disabilities

When developing with accessibility in mind there will almost certainly be some unexpected good fortune.  For example: if a person breaks her primary hand, and is forced to wear a cast, she may temporarily lose the ability to operate a mouse. The developer didn’t plan to cater to the temporarily disabled, but well designed keyboard navigation could surely save the day for such an accident victim.

Why does web accessibility matter?
  • It’s the right thing to do.

    Here’s a chance to make a positive difference in many people’s lives. Improving a site’s accessibility will make that site better for all users and will likely improve its position in the SERPs (Search Engine Result Pages). So be a good citizen and contribute to web accessibility! Make the web a better place for everyone!

  • It may be required.

    There are various state and federal laws regarding web accessibility.

    Some organizations and businesses have faced legal action for non-compliance with accessibility guidelines. Even if you were to win such a challenge, the cost in legal fees and in lost time would be substantial. Why risk exposing your business to the possibility of a legal challenge.

  • It’s good for business.

    According to the U.S. Census Bureau’s 2002 Survey of Income and Program Participation (SIPP), there are 51.2 million people with disabilities in the United States. That’s 18.1% of the U.S. population! Those folks need goods and services too, some of which are very specialized.

    Millions of people with disabilities shop, travel, buy cars, buy homes, eat out, go out and participate in most of the same activities as their fully-abled friends, neighbors and family. Web developers are in a unique position to work towards the good of all to advocate for and to help facilitate these behaviors. We all benefit.
     

  • Web accessibility is becoming easier to achieve and more unified with web standards as time passes.
  • More to come

    This series on Web accessibility will continue with the following:

    Part II: What guides accessibility efforts?

    This post will highlight the laws and governance related to web accessibility efforts.

    Part III: Tools and techniques for web accessibility

    Here we will provide a primer on assistive technologies and tools you and your developers can use to make your site more accessible.

    Part IV: Case studies

    This post will highlight two real-world applications where we have worked closely with clients to achieve highly-accessible websites. 

     

    Categories: Blogs

    Evolving Web: Writing a Custom Migration Source Plugin in Drupal 8

    December 18, 2017 - 2:01pm

    Usually, Drupal migrations get run at the beginning of a project to get all your content into Drupal. But sometimes, you need to create a migration that runs on a regular basis. For example, you have an external database of courses and programs maintained by a university that needs to be displayed on a Drupal site. Another example: you have a database of book data that needs to be pulled into Drupal nightly.

    When working with migrations where the source files are updated every day, it can get really tedious to download the updated source files manually each time the migration runs.

    In this tutorial, we'll write a source plugin based on the CSV source plugin which will allow us to automatically download CSV files from a remote server via SFTP before running migrations. This article was co-authored by my colleague David Valdez - gracias David for your contribution.

    The Problem

    In a project we worked on recently, we had the following situation:

    • CSV files are updated by a PowerShell script every night on the client's server.
    • These CSV files are accessible via SFTP.

    Our task is to download the CSV source files over SFTP and to use them as our migration source.

    Before We Start The Plan

    The goal is to avoid downloading the file manually every time we run our migrations. So we need a way to doing this automatically everytime we execute a migration. To achieve this, we create a custom source plugin extending the CSV plugin provided by the Migrate Source CSV module, which will download CSV files from a remote server and pass it to the CSV plugin to process them.

    The Source Migrate Plugin

    To start, let's create a custom module and call it migrate_example_source and implement a custom migrate source plugin by creating a PHP class inside it at /src/Plugin/migrate/source/MigrateExampleSourceRemoteCSV.php

    We start implementing the class by simply extending the CSV plugin provided by the migrate_source_csv module: namespace Drupal\migrate_source_csv\Plugin\migrate\source; use Drupal\migrate_source_csv\Plugin\migrate\source\CSV as SourceCSV; use phpseclib\Net\SFTP /** * @MigrateSource( * id = "migrate_example_source_remote_csv" * ) */ class MigrateExampleSourceRemoteCSV extends SourceCSV {}

    Adding the annotation @MigrateSource is very important because that is what will make the migrate module detect our source plugin. In our plugin, we use the phpseclib/phpseclib libraries to make SFTP connections. Hence, we need to include the libraries in our project by running the following command in the Drupal root:

    composer require phpseclib/phpseclib

    Our plugin will download the source CSV file and will simply pass it to the CSV plugin to do the rest. We do the download when the plugin is being instantiated like this:

    /** * {@inheritdoc} */ public function __construct(array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration) { // If SFTP connection parameters are present. if (!empty($configuration['sftp'])) { // A settings key must be specified. // We use the settings key to get SFTP configuration from $settings. if (!isset($configuration['sftp']['settings'])) { throw new MigrateException('Parameter "sftp/settings" not defined for Remote CSV source plugin.'); } // Merge plugin settings with global settings. $configuration['sftp'] += Settings::get('sftp', []); // We simply download the remote CSV file to a temporary path and set // the temporary path to the parent CSV plugin. $configuration['path'] = $this->downloadFile($configuration['sftp']); } // Having downloaded the remote CSV, we simply pass the call to the parent plugin. parent::__construct($configuration, $plugin_id, $plugin_definition, $migration); }

    In the constructor we are using global SFTP credentials with Settings::get(). We need to define the credentials in settings.php like this:

    $settings['sftp'] = array( 'default' => [ 'server' => 'ftp.example.com', 'username' => 'username', 'password' => 'password', 'port' => '22', ], );

    Once we have the credentials of the FTP server we use a downloadFile() method to download the remote CSV file. Here's an extract of the relevant code:

    protected function downloadFile(array $conn_config) { ... // Prepare to download file to a temporary directory. $path_remote = $conn_config['path']; $basename = basename($path_remote); $path_local = file_directory_temp() . '/' . $basename; ... // Download file by SFTP and place it in temporary directory. $sftp = static::getSFTPConnection($conn_config); if (!$sftp->get($path_remote, $path_local)) { throw new MigrateException('Cannot download remote file ' . $basename . ' by SFTP.'); } ... // Return path to the local of the file. // This will in turn be passed to the parent CSV plugin. return $path_local; }

    Note: The code block above has been simplified a bit. If you see the actual source plugin, there are some lines of code which make things more compatible with the migration_lookup plugin.

    This method creates an SFTP connection, downloads the file to a temporary location and returns the path to the downloaded file. The temporary file path is then passed to the Migrate Source CSV and that's it! Finally, to use the plugin in our migration we just set our plugin as the source/plugin:

    id: migrate_example_content label: 'Example content' ... source: plugin: migrate_example_source_remote_csv # Settings for our custom Remote CSV plugin. sftp: settings: sftp path: "/path/to/file/example_content.csv" # Settings for the contrib CSV plugin. header_row_count: 1 keys: - id ...

    The code for this plugin and the example module is available at migrate_example_source. Great!

    + more awesome articles by Evolving Web
    Categories: Blogs

    Electric Citizen: Essential SEO Tune-Up for your Drupal 8 Website

    December 18, 2017 - 11:49am

    Drupal is well known for being a Search Engine Optimization (SEO) friendly Content Management System (CMS) and Drupal 8, the latest version, is the best by far. Many of the essential requirements for SEO best practices are already baked into the core software architecture, and with a little knowledge and some basic configuration anyone can tune up their website to become faster, drive more traffic, and perform better in the search engine rankings.

    Categories: Blogs

    Pages