Drupal Planet

Subscribe to canal de noticias Drupal Planet
Drupal.org - aggregated feeds in category Planet Drupal
Actualizado: hace 1 hora 31 segs

Erik Erskine: When your composer build breaks

Mar, 10/31/2017 - 22:00

Yesterday a project on github was moved, causing Drupal's own build process, and that of many other websites, to “break”. Here's what happened:

  1. The coder library was removed from github (it's main home is on drupal.org).
  2. Drupal core's composer.json had a reference to the now non-existent repository.
  3. Anyone attempting to obtain Drupal by downloading it's source and running composer install couldn't.
  4. Many other developers who tried to build their websites were similarly left disappointed.

This seems to be a risk that comes with dependency management, and raises the question of should vendor be committed to version control? I'm hoping that this post will help you answer that.

Read more

Aten Design Group: Drupal's Upgrade Path and the Product Approach

Mar, 10/31/2017 - 16:46

Here at Aten, we do a lot of work with Drupal, mostly on large redesign projects for nonprofits and universities. We’ve been in the business for a while now (since 2000), and one thing we’ve been talking about for years is the predicament of “buy-maintain-replace” release cycles. Specifically, website redesigns often fall prey to a problematic purchasing cycle that directly counteracts strategic goals.

It goes like this: first there’s a capital campaign, then a big spike in funding to do a redesign project, followed by modest support budget for a few years. During support, things everyone would like to change start to pile up, often beginning as a “backlog” or “wish list,” inevitably becoming a “gripe list” for all the things that are slowly and surely making your website obsolete. Time passes and the gripe list grows. We hear things like, “Our current website is horribly outdated; it isn’t even responsive.” Rather than invest in old technology and continue addressing the growing list of issues, tasks are pushed off for a future redesign. Eventually, there is a new capital campaign. The cycle starts over, rinse and repeat.

If you’re coming from a product background and you’re programmed to value ongoing development and continuous innovation, this already sounds bad. But if you’re from traditional IT management, you might think of redesigns more like purchasing any other technology solution. You buy it, it gets old, you replace it – often with some form of ongoing support between major expenditures. The smaller the support requirement, the more successful the project. Likewise the longer you can go without upgrading, the more successful the project.

The trouble is, your website, app, etc. doesn’t really work that way. Your website shouldn’t just be checking boxes on functionality requirements the way your phone system or workstations do; rather, your website is the public face and voice of your organization. It needs to keep up and tell your story clearly, every day. It needs to evolve as quickly as your organization does. And that requires ongoing investment. More than that, it requires a fundamental shift in the way decision makers think about planning digital projects.

There’s already a ton of fantastic material about the need to adopt a product approach over the more traditional project mindset. One of my favorite posts on the subject was written back in 2015 by the team at Greenpeace titled, “Product teams: The next wave of digital for NGOs?” I especially love this infographic. The illustration is spot on: first, a huge spike in money and time with a brief climax at launch, followed by diminished investment during a prolonged support period with equally diminished satisfaction, all to be repeated over and over again.

Interestingly, this problematic “buy-maintain-replace” cycle actually aligned closely with the release cycle for previous versions of Drupal. For years, timing for the “buy” stage in the cycle aligned surprisingly well with the stable release for major Drupal versions. First, you built a website on Drupal 4. Support phase ensued. Over a few years wish lists turned to gripe lists. Momentum grew behind doing the next major redesign, right on time for the stable release of Drupal 5. Rinse. Drupal 6. Repeat. Drupal 7.

While we were talking more and more about a product approach, the technology actually lent itself to the project mindset. Quick example: retainers are a big part of our business at Aten, and have been important for helping us support clients in the product approach. With retainers, clients invest consistently in their digital platforms over the long term. We identify strategic priorities together, maintain a backlog, organize sprints and deploy iterative releases. But with past versions of Drupal, an organization still needed to invest heavily for major release upgrades. At some point in the cycle, there were diminishing returns associated with ongoing investment in an outdated system. We started prioritizing tasks based on the fact that a large redesign was looming. We said things like, “Let’s just wait on Drupal 7 for that.” In many ways the underlying platform was promoting a “buy-maintain-replace” development cycle. The product approach was still valuable, but hampered by inevitable obsoletion of the technology.

Enter Drupal 8.

With Drupal 8, there’s a lot to be excited about: configuration management, component-based theming, improved performance, content moderation, modernized development tools, support for API-first architecture, and the list goes on. But I want to focus for a minute on Drupal’s release cycle.

Drupal’s vastly improved upgrade path is a huge win for the platform and a major reason organizations should consider migrating to Drupal 8 sooner rather than later.

With past versions of Drupal, major release upgrades (i.e. D6 to D7) required a significant development effort and usually constituted a major technology project. As I’ve touched on already, upgrades would typically coincide with a complete redesign (again, buy-maintain-replace).

With Drupal 8 the release cycle is changing. The short, non-technical version is this: Drupal 8 will eventually become Drupal 9. If you stay up-to-date with underlying changes to the platform as it evolves, upgrading from 8 to 9 should be relatively simple. It’s just another release in your ongoing development cycle.

With Drupal 8, an organization can invest consistently in its digital platform without the problem of diminishing returns. As long as you adopt the product approach, your platform won’t become outdated. And that’s fantastic, because the product approach is what we’re all going for – right?

Resources and Related Reading:

Elevated Third: Release Notes, Translated: Drupal 8.4

Mar, 10/31/2017 - 16:01
Release Notes, Translated: Drupal 8.4 Release Notes, Translated: Drupal 8.4 Nick Switzer Tue, 10/31/2017 - 12:01

Drupal 8.4 is here! The most current minor release of Drupal 8 officially came out on October 4. This release contains lots of changes that push Drupal 8 forward in some big ways, but what are those changes and what do they mean to you?

The changes introduced in Drupal 8.4 affect everyone from Drupal developers to content administrators and site owners. I’ve broken things down into four categories, and we’ll cover the high points of each one. If you’re interested in really digging into the details, check out the full release notes available on drupal.org.

Security

The initial release of Drupal 8.4 doesn’t contain any major security updates that make it a mandatory update in the hours, or days, immediately after release. That being said, this is still an update that is critical for site security because as soon as a new minor release of Drupal comes out, security issues in previous minor releases are no longer patched.

I recommend updating to Drupal 8.4 as soon as possible because there is always a chance of a critical security release. You don’t want to get stuck dealing with the complexities of updating from Drupal 8.3 to 8.4 when you’re also racing the clock that starts ticking when a security vulnerability is made public.

Browser Support

Drupal 8.4 made some major updates to the versions of Internet Explorer that are supported out of the box. Previously, Drupal supported Internet Explorer 9 and up. Since Microsoft discontinued all support for Internet Explorer 9 and 10 in April of this year, Drupal has followed suit and will only be supporting Internet Explorer 11 moving forward.

No need to panic yet though - your site won’t cease to function in Internet Explorer 9 and 10 as soon as the 8.4 update is implemented, but bugs related to those browsers will no longer be fixed. Starting in Drupal 8.5, which is currently scheduled for release in March of 2018, existing workarounds for these browsers will be removed. This will impact every site differently, depending on how much support your frontend provides for these older browsers, so start talking to your developer now about the best approach for your site.

New and Updated Features

Drupal 8 introduced the idea of experimental modules in core. These are modules the Drupal core team has decided provide valuable functionality and should be included in core but still need testing. Many of them can be used in production releases without any issues, but, until they are officially declared stable core modules in a minor release, there may be breaking changes or non-existent upgrade paths as new minor releases of Drupal come out.

Quite a few notable modules were moved from experimental to stable status in Drupal 8.4, so I’ll provide a quick rundown here.

Datetime Range - Dates are challenging for web developers. Especially when you start dealing with things like ranges and events that span time zones. The Datetime Range module is another great tool in the Drupal developer’s toolbox. The module makes managing date and time ranges and integrating them with other parts of Drupal, much simpler.

Layout Discovery - There isn’t much to see on the frontend with this module, but it’s a really big step forward for Drupal core because standardized layout systems have never been possible with Drupal in the past. This module sets the groundwork for a common layout system across core and contributed modules.

Media - Finally! Media in Drupal core! This is a huge addition and one that will affect the team at Elevated Third in a big way because we have leveraged the contributed Media suite of modules very heavily thanks to its ability to provide a centralized media library that makes media management a breeze for content admins. Transitioning from the contributed Media module to the core Media module will bring it’s own set of challenges, but the good news is that transition does not have to happen immediately.

Inline Form Errors - This is a great little module we’ve used on quite a few sites to make the admin experience better. With Inline Form Errors, we’re able to quickly implement a system for providing users feedback when they fail to complete the necessary actions in a form.

Workflows - This is another piece of functionality lots of Drupal users have been craving. In the past, our team has leveraged the Workbench suite of modules to provide content workflow capability, but now, with Workflows in core, we have the groundwork for providing more advanced content administration experiences without the need for additional contributed modules.

Behind the Scenes/Developer Tools

In addition to everything we’ve already walked through, Drupal 8.4 implemented some major changes under the hood that are worth knowing about. These changes most directly affect developers but impact anyone involved in the Drupal ecosystem because they significantly increase the complexity of this update over previous Drupal core updates.

Symfony updated from 2.8 to 3.2 - When Drupal 8 was released, you probably heard a lot about Drupal “getting off the island” and embracing the standards and practices of the larger PHP development community. Incorporating Symfony into Drupal core made this transition much simpler than it would have been to write all of the required backend components from scratch. Symfony is a PHP framework that provides a huge amount of functionality to Drupal under the hood. Just like Drupal, Symfony also has major releases, and Drupal needs to be sure it’s leveraging the latest and greatest from Symfony. This kind of update won’t often happen because Symfony releases major versions every two years. When a Drupal minor release does incorporate a major Symfony version update, the complexity of the update does increase.

jQuery updated to 3.0 - jQuery is an extremely common Javascript library that has been packaged with Drupal core for a long time. One of the problems with previous major releases of Drupal is that they would get stuck running really old versions of jQuery because Drupal core did not have a minor release system that allowed these kinds of updates. Until this release, Drupal included jQuery 2.x, which will not be receiving feature updates anymore. This update might break some frontend functionality, but leverages the latest and greatest jQuery has to offer.

Drush support - Drush is a command line tool a huge number of Drupal developers leverage to make day-to-day development work much more efficient and easier to manage. It is an invaluable tool for our development team here at Elevated Third. With Drupal 8.4, Drush version requirements were increased, so our team found that we needed to upgrade our tools, in addition to Drupal core. This requires careful planning to be sure everything plays nicely during the update process, and after the updates have been applied.

What happens next?

The Drupal core release cycle works around minor releases every six months. The next expected minor release is Drupal 8.5, in March of 2018. Between now and then, there will likely be multiple patch releases that will introduce bug fixes and security updates, which will be much simpler updates and should be applied as soon as they are released.

Minor release updates introduce more complexity than the Drupal world has ever seen for updates within a major release, but the tradeoff is that when Drupal 9 comes out, you won’t have to completely rebuild!

Stay tuned for my next post detailing the Drupal 8 release cycle, where I’ll dig more into how this works, why and when you should update and what we can expect for the future of Drupal.

Dries Buytaert: Acquia Engage 2017 keynote

Mar, 10/31/2017 - 13:29

This October, Acquia welcomed over 650 people to the fourth annual Acquia Engage conference. In my opening keynote, I talked about the evolution of Acquia's product strategy and the move from building websites to creating customer journeys. You can watch a recording of my keynote (30 minutes) or download a copy of my slides (54 MB).

I shared that a number of new technology trends have emerged, such as conversational interfaces, beacons, augmented reality, artificial intelligence and more. These trends give organizations the opportunity to re-imagine their customer experience. Existing customer experiences can be leapfrogged by taking advantage of more channels and more data (e.g. be more intelligent, be more personalized, and be more contextualized).

I gave an example of this in a blog post last week, which showed how augmented reality can improve the shopping experience and help customers make better choices. It's just one example of how these new technologies advance existing customer experiences and move our industry from website management to customer journey management.

This is actually good news for Drupal as organizations will have to create and manage even more content. This content will need to be optimized for different channels and audience segments. However, it puts more emphasis on content modeling, content workflows, media management and web service integrations.

I believe that the transition from web content management to data-driven customer journeys is full of opportunity, and it has become clear that customers and partners are excited to take advantage of these new technology trends. This year's Acquia Engage showed how our own transformation will empower organizations to take advantage of new technology and transform how they do business.

Annertech: #DrupalCampDublin 2017 - a retrospective

Mar, 10/31/2017 - 11:29
#DrupalCampDublin 2017 - a retrospective

Over the past number of years, Drupal Camp Dublin was becoming more of a showcase/case study event where different speakers display work they had been doing on various websites. This year, we (the Drupal Ireland Association, of which I was chairperson) decided to "go back to our roots" and do two things: create a developer conference for developers, and engage more people from outside of Ireland.

Valuebound: Configure Apache Solr with Drupal for better content search

Mar, 10/31/2017 - 09:20

There have been times when clients are not very satisfied with the default Drupal search as quite a few times it is unable to meet their requirement especially when you need specific search control beyond core e.g. facets and related content. In order to resolve this issue and make search fast for end customers, we can use Apache Solr - an open source enterprise search platform - and configure it with our Drupal site.

In one of our previous blog post, we have discussed “How To Create Custom SOLR Search With Autocomplete In Drupal 7”. Note, before creating custom Solr search,…

Amazee Labs: Amazee Agile Agency Survey Results - Part 1

Mar, 10/31/2017 - 07:00
Amazee Agile Agency Survey Results - Part 1

A few weeks ago I published a call for feedback on a project I've begun to assess agile practices in our industry (Take the Amazee Agile Agency Survey 2017). I would like to share a preliminary overview of the results I have received for the Amazee Agile Agency survey so far. Twenty-five individuals have completed the survey to date, so I have decided to extend the deadline a few more days, to November 5th, in order to gather more responses. Thanks to everyone who has participated so far! 

Josef Dabernig Tue, 10/31/2017 - 10:00 Initial Observations Popular Methodologies

Given the initial survey results, Scrum (or a Scrum hybrid or variant) is the most widespread development process used by agencies. Many teams consider it their top priority in order to deliver a successful project. Following Scrum as methods most use by agencies are Kanban or Waterfall.

ScrumBan (a hybrid of Scrum and Kanban) has not been widely adopted.  

In addition to those processes presented, Holocracy, Extreme Programming or DSDM have also been mentioned.

At Amazee, we began using Scrum to deliver projects a little over two years ago and have made great progress on it since then. In the last year, we also started a maintenance team which uses Kanban. Just recently, we began evaluating ScrumBan as a way of integrating our maintenance team with one of our project teams.

Project Teams 

Agencies ranging in sizes from 1-5 people to over 100 people have responded to the survey. Of those surveyed, the most common team size for project work are, in order from most common to least common:

  • three people or fewer
  • five people
  • four people
  • six people  

In terms of co-located or working remotely, team location varied wildly, but skewed towards 'mostly co-located' with some degree of remote. More than 50% of agencies form a new team with the launch of a new project, followed by stable teams which deliver multiple projects at the same time. Following multiple-project delivery are stable teams which deliver one project at a time.

At Amazee, we started out spinning up a new team with each new project, but soon realized that the constant starting and stopping of mid-sized projects was too disruptive. These days, we use stable teams to deliver multiple projects.

Sprints

Most teams surveyed deliver in two-week sprints. The remaining 33% of respondants deliver anywhere from single-day sprints to month-long sprints.

Team Integration

Frontend and backend developers are usually specialized but mostly work together on one team.

DevOps, QA/Testing, as well as the Scrum Master role, are shown in all variations of integrated or totally separate teams.

UX & Design are split, with this role either in a separate team (or external resource) or as part of a stable team. 

At Amazee, we try to hire T-shaped experts that can work across most disciplines on a team. For example, a Frontend developer may also have experience with backend tasks, which can help alleviate work silos and ticket bottlenecks. 

Staying Connected

Most agency teams rely on written communication to stay connected. This can take the form of tickets or via a chat tool such as Slack.

The majority of teams hold team meetings and 1-on-1 meetings, while fewer teams communicate mainly via blogs, wikis or even pull requests.

The majority of standups last fifteen minutes while some are only 5-10 minutes.

At Amazee, our hubs differ. Our Zurich office holds a company-wide standup that takes about ten minutes, followed by a team-specific standup that takes another ten minutes. Our Austin office holds a company-wide standup, which includes a client, which lasts about fifteen minutes. 

Splitting up the Work 

Many agencies vary in their approach to defininig, writing, reviewing, and estimating tasks and tickets. For most agencies, the project team is involved in each step of the ticket creation process. In others, creating tickets falls to the client, project manager, or product owner. In most cases, a technical lead is involved in the high-level ticket creation and the team is brought in for estimations. 

The most common approach to estimating ticket is time based (hours, days, weeks) followed by story points (t-shirt sizes, fibonacci sequence) 

Client Communication 

When it comes to meetings between the team and the client, the top mentioned options where 'less frequently' followed by 'more or once per week' and 'every two weeks'.

At Amazee, depending on the project size, our teams meet weekly or bi-weekly with the client. Clients are encouraged to talk directly with the team via Slack. We'd like to offer a daily standup with some clients, but haven't figured out how to do this easily as usually a team works on multiple projects at the same time. 

Delivery Practices

Most teams surveyed deliver rolling deployments, pushing code whenever necessary.

Peer reviews / code reviews have been named equally “somewhat in use” as well considered “very important”.

While the majority of agencies considers user testing very important, for automated testing the majority still tends only towards “somewhat in use”.

While a number of agencies have pair programming somewhat in use, Mob programming is mostly unknown.

The majority of teams consider automated deployments / continuous integration very important.

When it comes to story mapping, most agencies are unfamiliar. Those which do implement this tool, however, consider it very important.

At Amazee, peer review for every ticket is a normal part of our development flow. Our developers implement pair programming whenever necessary. This is an excellent practice for sharing knowledge and increasing the team's technical confidence. We are actively exploring story mapping. 

Take our Survey

This initial post is just a taste of the information I have collected, there is a lot more to be shared. Besides the numerical data, I am especially excited about the free-form responses which give valuable insights into the tangible, real-world decisions that are being taken in agencies to define daily agency life.

Before sharing a deeper analysis and the full, anonymous, survey results, I wanted to share this preliminary data to give an idea of what’s coming in. I hope this information is helpful in determining industry alignment or to find inspiration for what to try next.

Our Agile Agency survey will remain open until Sunday, November 5th at midnight UTC -7. After the survey closes, I will tabulate the results and prepare Part 2 of this series where I look forward to sharing my findings.  

ADCI Solutions: Cloud hosting platforms. Part one: Pantheon

Mar, 10/31/2017 - 04:52

The story of your life: you are searching for a hosting because you need to share code between teammates and show an intermediate result to a client. You don’t need too much: an SSH access, Git, and Drush. You also would like to have a simple and convenient administration panel and have isolated environments and technical domains.

 

We know what hostings do have all these features. Let's talk about Pantheon that allows you to start a new Drupal 7 or Drupal 8 project in a few clicks.

 

Observe Pantheon

 

Mediacurrent: 7 Ways to Evaluate the Security and Stability of Drupal Contrib Modules

Lun, 10/30/2017 - 17:59

Keeping up with Drupal security updates is key to protecting your site, but assessing contrib module security before implementation is just as important. In a new guest post on the Pantheon blog, Mediacurrent Senior Drupal Developers David Younker and Joshua Boltz share a practical guide for sizing up the security of contrib modules.

Try this 7-Step Security Inspection 

To ensure a safe and solid foundation for your Drupal site, consider this 7-point assessment:

1. Has the module maintainer opted in to the security coverage?

Aten Design Group: The Importance of an Accessible Website - Part 3: Make Your Drupal 8 Site More Accessible

Lun, 10/30/2017 - 15:09

Accessibility should be part of the criteria for picking a CMS. Fortunately, many CMSs out there are getting that right. Building on the information from Part 1 and Part 2 of this series, I’m going to focus on leveraging Drupal 8’s accessibility features to enhance any user’s experience.

Drupal 8 Core

Drupal 8 makes it much easier to add accessibility features than previous versions. Some of the most significant improvements for accessibility within Drupal 8 core are:

  • Core code uses semantic HTML5 elements and the addition of aria landmarks, live regions, roles, and properties to improve the experience of screen readers.
  • Creating aural alerts for users who use audio features to navigate and understand a website are easy to implement using Drupal.announce().
  • Users have more control navigating through content with a keyboard using the new Tabbing Manager.
  • Hidden, invisible or on-focus options for all labels have been included so screen readers can give more context to content – without impacting design decisions for traditional screens.
  • Fieldsets have been added for radios and checkboxes in the Form API.
  • Alt text is now required for all image fields by default.
  • The default Bartik Theme is now underlining links so that it is much easier for people to identify links on the page.
  • D8 now includes an optional module to include form errors inline to easily associate errors with inputs when filling in a web form.
Theming

Out of the box, Drupal core is a great starting point for creating an accessible website. Usability issues tend to arise when designers and developers begin the theming process. In order to achieve a desired design or function, they inadvertently remove or alter a lot of Drupal’s accessible defaults. With knowledge gained from the previous posts and the following tips, you will be on your way to theming a more accessible site for everyone!

Links

Make sure pseudo :focus and :active styles are always included for users navigating by keyboard. This helps the user visually understand where they currently are on a page. This can be the default browser styling or something more brand specific.

You may include “read more” links on teasers, but make sure there is a visually hidden field to include what the user will be “reading more" about for aural users.

Display None vs Visually Hidden

Drupal 8 core now has this option for labels when creating content types and forms, but it also includes simple class names to hide content properly. A great example of this usage is fixing a “read more” link to something more descriptive for screen readers.

<a href="{{url}}">{{'Read more'|t}} <span class="visually-hidden"> {{'about'|t}} {{label}}</span></a> Anchor and Skip Links

Providing a way to skip links and navigation on a page can improve the usability of a keyboard or aural user on your site. This is a great addition to your site and easy to implement. As mentioned in the previous post, screen readers have the ability to skip and search your site by sections, headings, links, etc. Adding another way to skip various types of content gives the user an easier way of flowing through and skipping heavy or repetitive information on a page. Just remember that this should be visibly hidden and not display: none;!

Forms

Always include a button for users to submit their form information. Exposed forms within Drupal have the option for an “auto submit” setting, which automatically submits the form once an element is interacted with or changed. Having one action which invokes two outcomes can cause major confusion for users navigating with assistive technologies.

For Example: A user chooses an item within a select dropdown, and the form submits this change which modifies the content on the page. All of this happens just by selecting an item within a dropdown. Ideally, the user should be able to choose the item in the dropdown, and then press submit to search. Each item should only have one action.

Be careful that you are not reducing the accessibility of forms when using hook_form_alter and other techniques to modify forms. Following the basic form guidelines while implementing forms through this technique will ensure that your forms work well for everyone.

Final Thoughts

We have seen great improvements in Drupal’s core code over the past few years to accommodate everyone. Drupal 8 has a lot of accessibility features built in and as developers we need to take advantage of those features or at the very least, not remove them.

Mediacurrent: Top 4 Takeaways from Acquia Engage

Lun, 10/30/2017 - 14:47

This October, Mediacurrent was excited to participate in our 4th Acquia Engage conference in Boston. As returning sponsors we enjoyed connecting with friends, partners, customers and potential customers, all set to a backdrop of Boston Harbor. The sessions were interesting and the receptions boasted delicious local fare (hello lobster rolls!), but the real highlight was to listen in on the strategy behind Acquia’s latest product announcements.

If you were unable to attend, never fear because we have you covered with the biggest topics from this year’s event.

Drop Guard: International PHP & JavaScript Conference - these guys sec you up!

Lun, 10/30/2017 - 11:30
International PHP & JavaScript Conference - these guys sec you up!

Our CEO Manuel spoke at the IPC 2017 in Munich about DevSecOps automation. We took a look around and picked the two other security related sessions which struck our eyes.

 

Dip Your Toes in the Sea of Security - by James Titcumb

Drupal Planet Events Security Business

Jacob Rockowitz: Organizing and Presenting Webform Training Materials

Lun, 10/30/2017 - 07:49

Now that the post-DrupalCon Vienna events are in full swing and next year's pre-DrupalCon Nashville events are in the works, I’ve started organizing and creating next year’s Webform related presentations. I find presenting at DrupalCamps challenging and rewarding. The challenge is getting up in front of a large group of developers and talking about my work, but the reward is I get to meet people who use my work to build awesome forms.

Attending Drupal Camps & Events

In the past, I’ve managed to attend a bunch of events including DrupalCamp NJ, NYCCamp, DrupalCon Baltimore, Design4Drupal, and Drupal GovCon. My last camp of the year is going to be DrupalCamp Atlanta on November 2-4, 2017. I decided to go to DrupalCamp Atlanta because they are offering me the opportunity to do my first training session called Learn how to build awesome webforms and a keynote panel discussion. Yes, I am uncomfortable with public speaking, however I’ve committed myself to doing it for longer and in front of more people; this conference is pushing me to up my game. The hope is that it will prove to be a good thing for me, and hopefully will, in turn, be a good thing for others too.

Overcoming Challenges

One technique I’ve learned to overcome my weaknesses is to leverage my...Read More

Roy Scholten: UX notes week 44

Lun, 10/30/2017 - 07:21
30 Oct 2017 UX notes week 44

A selection of Drupal design topics and issues that are moving or should be :)

Small big win: status report pattern reuse in the migrate UI

A nice success from last week was closing a critical issue for Migrate UI. Particularly pleased that we were able to apply a new “summary” user interface element we recently introduced on the status report page.

Big one: redesign the administrative UI

There was a big interest in this over several meetings and workshops at Drupalcon Vienna and after. Seven theme hasn’t evolved much over the last years and it shows.

The right issues are not yet in place for this but I see and hear multiple people thinking about this. There’s multiple parts to this, of course:

  1. A visual update. What would the next version of this style guide look like?
  2. Improve the information architecture. Lots of solid thinking around this already.
  3. Introduce new interaction patterns. We still mostly rely on tables, select lists and other basic form elements. Experiments with JavaScript frameworks should help here but we should design these starting from user needs.
  4. Modernize the underlying theme architecture.
  5. Update and extend the user interface standards documentation.
Drupal core could use another usability test

The core feature set has grown considerably over the last couple of 8.x releases. On the one hand it would be smart if we found a way to do more smaller tests more often. On the other hand, since it’s been more than 2 years since the last big usability test we could do with one of those as well. Lets figure out what we can do. Check in here if you’re interested in helping with this.

Something to look forward to: Layout builder

The layouts-in-core team has been steadily working towards this. Looks like we are in great shape and on track to really honestly add a visual layout builder to core. There’s a patch going through the last stages of review and refine in https://www.drupal.org/node/2905922. One cool smart detail is that this will also introduce a dynamic way to dynamically generate icons for different types of layouts. Very nice indeed.

Permissions UI

Core and contrib modules often come with their own (set of) permissions. It’s how you can configure which roles get access to do what. This permissions UI is currently an ever growing sea of checkboxes. This does not scale, for user nor machine. The current model of a grid lists all available permissions in rows and all roles in columns needs a thorough rethink. Lets figure out a plan for how to do that.

Also,

& some more pointers to where you can go to find out what’s going on.

Enjoy your week!

Tags drupalplanet

Agiledrop.com Blog: AGILEDROP: We are not here to replace your team

Lun, 10/30/2017 - 06:26
The history and future There is this digital agency which has specialized itself in Drupal a couple of years ago. Let’s call it Gr8 Solutions. And the business is very good, they signed some fancy contracts with some of the biggest companies in the country over the years and thus built themselves a reputation for being professional and creative. And in the process of acquiring new clients and new projects they were steadily growing. This also resulted in hiring a few new developers, a designer, and a salesperson. Fast forward to very near future, nothing memorable happened in the meantime.… READ MORE

qed42.com: Securing Cookie for 3rd Party Identity Management in Drupal

Lun, 10/30/2017 - 06:15
Securing Cookie for 3rd Party Identity Management in Drupal Body

We are in an era where we see a lots of third party integrations being done in projects. In Drupal based projects, cookie management is done via Drupal itself to maintain session, whether it be a pure Drupal project or decoupled Drupal project,.

But what when we have a scenario where user’s information is being managed by a third party service and no user information is being saved on Drupal? And when the authentication is done via some other third party services? How can we manage cookie in this case to run our site session and also keep it secure?

One is way is to set and maintain cookie on our own. In this case, our user’s will be anonymous to Drupal. So, we keep session running based on cookies! The user information will be stored in cookie itself, which then can be validated when a request is made to Drupal.

We have a php function to set cookie called setCookie() , which we can use to create and destroy cookie. So, the flow will be that a user login request which is made to website is verified via a third party service and then we call setCookie function which sets the cookie containing user information. But, securing the cookie is must, so how do we do that?

For this, let’s refer to Bakery module to see how it does it. It contains functions for encrypting cookie, setting it and validating it.

To achieve this in Drupal 8, we will write a helper class let’s say “UserCookie.php” and place it in ‘{modulename}/src/Helper/’. Our cookie helper class will contain static methods for setting cookie and validating cookie. Static methods so that we will be able to call them from anywhere.

We will have to encrypt cookie before setting it so we will use openssl_encrypt() php function in following manner:

/** * Encrypts given cookie data. * * @param string $cookieData * Serialized Cookie data for encryption. * * @return string * Encrypted cookie. */ private static function encryptCookie($cookieData) { // Create a key using a string data. $key = openssl_digest(Settings::get('SOME_COOKIE_KEY'), 'sha256'); // Create an initialization vector to be used for encryption. $iv = openssl_random_pseudo_bytes(16); // Encrypt cookie data along with initialization vector so that initialization // vector can be used for decryption of this cookie. $encryptedCookie = openssl_encrypt($iv . $cookieData, 'aes-256-cbc', $key, OPENSSL_RAW_DATA, $iv); // Add a signature to cookie. $signature = hash_hmac('sha256', $encryptedCookie, $key); // Encode signature and cookie. return base64_encode($signature . $encryptedCookie); }
  1. String parameter in openssl_digest can be replaced with any string you feel like that can be used as key. You can keep simple keyword too.
  2. Key used should be same while decryption of data.
  3. Same initialization vector will be needed while decrypting the data, so to retrieve it back we append this along with cookie data string.
  4. We also add a signature which is generate used the same key used above. We will verify this key while validating cookie.
  5. Finally, we encode both signature and encrypted cookie data together.

For setting cookie:
 

/** * Set cookie using user data. * * @param string $name * Name of cookie to store. * @param mixed $data * Data to store in cookie. */ public static function setCookie($name, $data) { $data = (is_array($data)) ? json_encode($data) : $data; $data = self::encrypt($data); setcookie($name, $cookieData,Settings::get('SOME_DEFAULT_COOKIE_EXPIRE_TIME'), '/'); }

Note: You can keep 'SOME_COOKIE_KEY' and 'SOME_DEFAULT_COOKIE_EXPIRE_TIME' in your settings.php. Settings::get() will fetch that for you.
Tip: You can also append and save expiration time of cookie in encrypted data itself so that you can also verify that at time of decryption. This will stop anyone from extending the session by setting cookie timing manually.

Congrats! We have successfully encrypted the user data and set it into a cookie.

Now let’s see how we can decrypt and validate the same cookie.

To decrypt cookie:

/** * Decrypts the given cookie data. * * @param string $cookieData * Encrypted cookie data. * * @return bool|mixed * False if retrieved signature doesn't matches * or data. */ public static function decryptCookie($cookieData) { // Create a key using a string data used while encryption. $key = openssl_digest(Settings::get('SOME_COOKIE_KEY'), 'sha256'); // Reverse base64 encryption of $cookieData. $cookieData = base64_decode($cookieData); // Extract signature from cookie data. $signature = substr($cookieData, 0, 64); // Extract data without signature. $encryptedData = substr($cookieData, 64); // Signature should match for verification of data. if ($signature !== hash_hmac('sha256', $encryptedData, $key)) { return FALSE; } // Extract initialization vector from data appended while encryption. $iv = substr($string, 64, 16); // Extract main encrypted string data which contains profile details. $encrypted = substr($string, 80); // Decrypt the data using key and // initialization vector extracted above. return openssl_decrypt($encrypted, 'aes-256-cbc', $key, OPENSSL_RAW_DATA, $iv); }
  1. We generate the same key using same string parameter given while encryption.
  2. Then we reverse base64 encoding as we need extract signature to verify it.
  3. We generate same signature again as we have used the same key which was used to creating signature while encryption. If doesn’t signatures doesn’t matches, validation fails!
  4. Else, we extract initialization vector from the encrypted data and use to decrypt the data return to be utilized.
/** * Validates cookie. * * @param string $cookie * Name of cookie. * * @return boolean * True or False based on cookie validation. */ public static function validateCookie($cookie) { if (self::decryptCookie($cookieData)) { return TRUE; } return FALSE; }

We can verify cookie on requests made to website to maintain our session. You can implement function for expiring cookie for simulating user logout. We can also use decrypted user data out of cookie for serving user related pages.

navneet.singh Mon, 10/30/2017 - 13:45

Matt Glaman: Using JSON API to query your Search API indexes

Dom, 10/29/2017 - 01:18
Using JSON API to query your Search API indexes mglaman Sat, 10/28/2017 - 22:18 The JSON API module is becoming wildly popular for in Drupal 8 as an out of the box way to provide an API server. Why? Because it implements the {json:api} specification. It’s still a RESTful interface, but the specification just helps bring an open standard for how data should be represented and requests should be constructed. The JSON API module exposes collection routes, which allows retrieving multiple resources in a single request.

Hook 42: Hook 42's BADCamp 2017 Takeaways

Vie, 10/27/2017 - 17:43

This year at BADCamp we had the opportunity to share in thought leadership by leading a training, participating in the DevOps Summit, and presenting 5 sessions with topics ranging from accessibility, git, project management, A/B testing, and contributing to the Drupal issue queue.

Continuing in the spirit of thought leadership, we also want to share with the whole Drupal community our takeaways, thoughts, and excitement about the new ideas and technologies we learned at BADCamp.

Lullabot: Effective Communication, Part 2: Crossing the Streams

Vie, 10/27/2017 - 16:20

The first article in this series helped us dismantle the various forms of communication, isolate common pitfalls, and set realistic expectations for the team. Now we'll dig a little deeper and explore effective communication techniques to help stakeholders, managers, and the development and design team work together in blissful symbiosis.

Makers vs Managers

First, we need to agree that all of these groups exist in different realms of the project.  What I mean by this is that each group is involved to a different degree and thus approaches the project with a unique mindset. One of my favorite articles outlining this concept is Paul Graham's 2009 post entitled "Maker's Schedule, Manager's Schedule."

Paul outlines the pitfalls of interrupting a "maker's" schedule with meetings. Managers run on a different style of schedule where meetings and context switching are a regular part of their workday. Makers, such as developers, need large blocks of uninterrupted focus to solve logic problems or hunt down a bug in the system. Remembering, preparing for, and attending meetings pulls the developer out of their "zone." And, as any developer will tell you, getting into that zone is much more difficult than being pulled out of it. This comic beautifully outlines the reason why you should never interrupt a programmer.

Minimize the Meetings

First, I'd like to talk to the meeting schedulers.  As we just outlined, meetings, or as most developers refer to them, "productivity crushing time sinks," are budgetary black holes when it comes to development. A one-hour meeting with a developer could cost two or more hours in productivity when you consider scheduling, prep and loss of focus. Lullabot Senior Developer, Juampy, wrote a great article on reforming this process. So when are meetings OK? Before scheduling one, ask yourself these questions:

  1. Could the information be exchanged via email?
  2. Could this information be rolled into a different, more encompassing meeting?
  3. Do we need to create a deliverable item?
  4. Will all invitees be involved?

I see a meeting being a valuable use of time when multiple people are brainstorming an idea and a deliverable needs to be produced as a result. The keystone of the decision being the interactivity of people. In the scope of a project, a meeting where the majority of invitees are present just to listen is a waste of time. Summarize the information in an email or a document and send it to people to read on their own. If the document is well constructed, follow up meetings and Q&A can be avoided completely and you just saved a boatload of time.

If you have decided that a meeting is necessary, consider who is critical to be involved in the meeting and who could stand to simply receive a summary of the decisions made. Inviting people to a meeting "just in case" is just another time sink. Furthermore, when you involve more people in a conversation, the lines of communication increase factorially, which leads to diluted discussions. Information is more easily processed and decisions made more quickly when there are fewer communication channels.

undefined

Keeping the meetings to a minimum removes the focus-busting barriers from your production team's workday, but you still need to be in the loop about the project. I've found that most meetings can be easily replaced with email, progress reports, or other project management tools. The benefit to the developers is that they can incorporate these tasks into their schedules in the most effective manner for them. For many stakeholders, however, meetings are how they stay connected to the project. If the meetings go away, other communication methods may fall in to replace them. That's not a bad thing, as long as expectations for how they should be used are set in advance.

Meeting Alternatives

How you structure these ground rules depends on the size and comfort level of both the development team and the stakeholders. A good project manager will sit in between to ensure the proper channels are used and are not being abused. At Lullabot, we often have the entire development team in the same Slack channel as the clients and set up a distribution mailing list for external stakeholders.

Before we get the project up to cruising altitude, we go over the safety speech with the client on how to use these tools effectively. For example, please don't fire off an email for every idea, bug, or individual task that comes to mind. This also goes for Slack pings. Consolidate your thoughts and send them out in a single request. If you truly want to be ignored and miss your deadline, ping the developer every time you send them an email to make sure they got it. Believe it or not, this has happened. Instead, work with the project manager and follow the communication guidelines outlined in the project charter or kickoff meeting. If all else fails, funnel your requests through the project manager and allow them to parse the necessary actions and assign them to the team. We'll discuss more on handling email effectively in the next article.

As a project manager, your place in the communication landscape could be lounging comfortably at the top of the hill enjoying the view, or you might be down in the weeds playing in the dirt. Teams will play nicely together in some projects and could be completely at odds in another. Your job is to keep the information flowing and the project on track.

Set the Ground Rules Early

When kicking off a project, the project manager should get stakeholders, developers, and designers together to discuss the expected frequency of communication and the proper channels to use for certain communications. For example, do you want your developers emailing the clients directly whenever they have a question? Or is it OK for stakeholders to ping developers on Slack every time they find what they consider to be a bug? Defining these ground rules in the project charter or at least in a formal kickoff meeting ensures that everyone is aware of the expectations and the channels are set to make the project run smoothly. It is very easy for clients to feel ignored or developers to feel overwhelmed if neither knows the right method or frequency to address their concerns.

Keep Your Focus  

Check in periodically with both stakeholders and the production team. Ensure the communication channels originally outlined are holding up and important information is not falling through the cracks. Make adjustments if needed, like increasing daily syncs or eliminating useless notifications. It’s easier to begin with fewer items in the communication landscape and add more as needed than it is to try and remove them later, so start lean.

Don't Overcomplicate the System

If you have some excellent communicators on your production team and the client is open to working with them, cautiously step out of the way and let the stakeholders and your team communicate directly. Given this responsibility, you might be surprised at the leaders you have hidden behind the screens. As a project manager, sometimes you can simplify the process by removing yourself!

"Don't add process for the sake of process. The fewer cogs in the machine, the simpler it is to maintain." -  Jerad Bitner, Lullabot Technical Project Manager

For more resources about effectively managing an agile system, check out Jerad’s article, "Lessons Learned in Scaling Agile."

Block Your Calendar

Lastly, here's a little trick for the production team I used when I worked in a meeting-heavy office environment. Coworkers had access to each others' calendars and could thus schedule meetings based on the attendees' availability, so I reduced my availability. I put two giant blocks of busy time over Tuesday and Thursday and made those my heads-down days.

undefined

This technique funneled most of my meetings into Wednesdays. I saved the smaller tasks that didn't require as much focused brain power to fill in the gaps in between meetings and hunkered down to attack the bigger tasks on those heads-down days. It was a huge productivity boost. Sometimes you need to control the communication flow however you can to get the work done.

We've covered a number of ways that the production team can work effectively with the stakeholders, and also how project managers can help facilitate that. Setting the ground rules early and avoiding unnecessary meetings go a long way to boosting productivity without sacrificing stability. The elephant in the room that we've been tip-toeing around is email. It is by far the most pervasive and invasive form of communication and deserves its own article's worth of attention.  Stay tuned for the next installment, where we'll discuss best practices as well as tips and tricks for dealing with a deluge of email.

In the meantime, if you have any suggestions of your own, I'd love to hear about them! How do you handle complex communication systems?

OSTraining: Adding a MailChimp Newsletter to Your Drupal Site

Vie, 10/27/2017 - 13:50

Finding easy to use modules for Drupal 8 is not always easy. Often they haven't been migrated from Drupal 7. Or they are still in beta. Or the documentation is either poor or non-existent.

That's why finding the MailChimp module was a true delight. In this tutorial, you will learn how to use this module to integrate your Drupal 8 site with MailChimp newsletter service.

Páginas