Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 23 hours 29 min ago

Drupal Modules: The One Percent: Drupal Modules: The One Percent — Contact Block (video tutorial)

15 December 2016 - 11:25am
Drupal Modules: The One Percent — Contact Block (video tutorial) NonProfit Thu, 12/15/2016 - 13:25 Episode 12

Here is where we bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll consider Contact Block, a module which will expose your contact form to the block system.

Categories: Drupal

Palantir: AcademyHealth

15 December 2016 - 9:12am
AcademyHealth brandt Thu, 12/15/2016 - 11:12 Increasing Membership Through Thoughtful Design

Showcasing the value of membership through a beautiful design.

  • Creating a modern design for a research organization

  • Emphasizing the value of membership

  • Building a custom Drupal module for GatherContent

We want to make your project a success.

Let's Chat. Our Client

AcademyHealth brings together health services and policy research professionals to transform the future of health services research (HSR). ​Health services research is the science of study that determines what works, for whom, at what cost, and under what circumstances. HSR studies how our health system works, how to support patients and providers in choosing the right care, and how to improve health through care delivery.

As an objective broker of healthcare information, AcademyHealth offers HSR practitioners access to leading health policy publications, course syllabi, research funding, networking opportunities and training programs. They also provide policymakers and the media the necessary tools to navigate and address key issues related to the delivery of health care and the development of health policy.

Goals and Direction

AcademyHealth was looking for a strategic design partner to help define their web presence and effectively demonstrate the value of AcademyHealth membership. To do so, they needed to make it easy to find and explore relevant HSR research and topics drawn from a variety of sources.

The primary high-level goals for the redesign were to:

  • Create a strong experience for multiple audiences. The primary purpose of AcademyHealth’s website is to convey and promote the breadth and impact of health services research to a broad audience of users. The redesign needed to enhance the visibility and accessibility of key information produced by AcademyHealth and its members and partners.
  • Implement a streamlined design system. This design system needed to be cohesive and user-focused for users both internal and external, as well as member and non-member.
  • Improve internal user experience. The editing experience needed to provide better tools for managing the flow of copy as editors created new content.
  • Improve navigation through topic-centered information architecture. The hierarchy of the navigation needed to support the topic-centered approach of the new information architecture and improve users’ findability of content.
  • Convey diverse offerings of AcademyHealth membership. Member-exclusive opportunities that further the professional advancement of HSR practitioners needed to be prominent to make the value of membership obvious.
  • Embrace current web design best practices. The new site needed to utilize responsive design and follow best practices for accessibility.
A Fresh Design

The new site required a responsive design, so that all users could have a positive experience no matter the size of their screen. Responsive design prioritizes content differently based on the device users are using to access the website. With mobile web usage surpassing desktop, we adopted a mobile-first design approach. Because of the limited screen size of mobile — and the distractions inherent to mobile device usage — design must be focused on the actions most important to users.

Another requirement was that the design convey an immediate sense of brand identity that allows AcademyHealth to stand out. Our design team began by researching the competitive landscape to gather ideas for what kind of mood the AcademyHealth site should portray.

A collage of landscape research compiled for design inspiration.

With the goal of increasing membership in mind, our designers knew it was important to create a feel of belonging with the new design. Our design team created a skyline image for the homepage that represents the different elements of their member base: healthcare practitioners, university researchers, and government policymakers. The prismatic skyline also represents the breadth and scale of the healthcare community.

Style tiles, showing the skyline header and general font and color treatments.

After incorporating a round of feedback from the AcademyHealth team, the design direction was finalized and we began prototyping the site and building its style guide. The style guide is a set of interactive HTML and CSS components that form the design for a CMS implementation.

A style guide element showing proper image usage for the site and its behavior on mobile.GatherContent and Development

When planning for a website redesign or relaunch, the content is more important than the technology. Yet, because of the effort involved, it can be easy to neglect this critical step in project planning. As an organization with a dedicated editorial team, AcademyHealth understood the challenge and used GatherContent during the Discovery and Strategy phase of the project. GatherContent is a content development tool that allows content to be prepared and reviewed before publishing to Drupal and other content management systems.

Because AcademyHealth could begin preparing their content so early in the process, all of their baseline content was ready before development even began. Having real, production-ready content greatly enabled our team to develop a site that matched exactly what they needed, and we were able to do all of our technical demos with real content.

In order to migrate AcademyHealth’s content from GatherContent to their new Drupal site, our development team wrote a Drupal 8 migration source plugin for the GatherContent API. Using this module and Migrate Plus, YAML migration configurations can be written to import content from GatherContent to Drupal content, including nodes, taxonomy terms, and menu items. Once development was complete, the use of GatherContent facilitated a quick launch, since moving content into Drupal had been automated.

The Importance of User Testing

While development was in progress, our strategy team conducted both virtual and in-person usability testing. When implementing virtual testing of the navigation, we focused on terms that were used by key audiences to discuss health services content. Building upon the research conducted during the navigation testing, in-person usability testing with a group of prominent health services researchers focused on evaluating stakeholders’ ability to successfully complete key tasks that relate directly to key performance indicators and business goals. Having conducted research and holding conversations with key stakeholders, our strategists’ deep subject knowledge of AcademyHealth’s audience and content enabled them to craft questions and tasks for user testing that aligned specifically with AcademyHealth’s business goals.

By asking very specific questions, we were able to make sure topics were tagged correctly and content was filed in a way that makes sense to users.

Question results during in-person user testing.

By conducting user testing, key stakeholders were able to see in-person reactions from site users. This process helped us to refine the design and functionality with actionable data.

A sample user test result of the site’s navigation.

Our strategy and development team then synthesized the results of testing into recommended improvements to the site’s structure.

Specific results of a usability test for mobile device users.

For teams familiar with working within their organization’s structure, there can be a desire to list all options within the site navigation. After all, it’s how the team thinks of itself. But in this case, we found that listing all options was overwhelming to people just beginning their interaction with AcademyHealth.

As a result, the main navigation was streamlined, and the list of special interest groups is displayed within the context of topical areas. When thinking about a redesign, the ability to step outside your own organization is critical and can be done quickly through the smart application of user testing.

Working in native HTML and CSS allows cross-browser and mobile testing to be introduced immediately, which greatly aids the design process.

The final AcademyHealth homepage.Editorial Training and Workflows

While the editorial team was working with their content during the strategy engagement, during development they needed to become familiar with Drupal 8 and how the new CMS would affect their workflows. Since improving the internal user experience was a key goal, we built editorial training into the project schedule, which allowed the development team to iterate on specific improvements.

Most significantly, working with the editorial team uncovered new workflow efficiencies. Using Drupal 8’s improved editing screens and the Workbench Moderation module (now in Drupal 8.2 core as Content Moderation), we developed a custom approval workflow based around member and non-member content. Since each content type can have a custom workflow, editors with different specialties can adopt a workflow best suited to their publishing needs.

While creating content, editors can also select related content elements to promote discovery and increase visitor retention. The site uses a combination of automated and curated selection for related content, which ensures relevant content appears in each context.

A publication page for AcademyHealth, with related content given prominent location.The Results

In many ways, this was an ideal project. By setting up GatherContent early, our development team was able to effectively build a site that organized and showcased their content. Once development was complete, the extensive amount of user testing performed allowed us to make strong recommendations for future iterations of the site.

We want to make your project a success.

Let's Chat. Drupal 8 Services strategy design development
Categories: Drupal

Acquia Developer Center Blog: PHP FIG, unsplintering PHP for us all - meet Beth Tucker Long

15 December 2016 - 8:59am

This conversation with Beth Tucker Long (@e3bethtl) is the one of a series of interviews Campbell Vertesi (@CampbellVertesi) and I carried out in preparation for DrupalCon Asia in Mumbai. Now, we're sharing all the good stuff we captured but didn’t have time to cover in 40 minutes in Mumbai.

Our session, Meet PHP-FIG: Your community just got a whole lot bigger, Drupal is about Drupal 8’s membership in the new, interoperable PHP community. We’re covering the basics of what the PHP Framework Interoperability Group (PHP-FIG) is, what the various PSRs are and do, talk about testing and dependency management, and what it means to be a part of the new PHP community — including having better architecture, cleaner code, and more interoperability. All of this adds up to a big move to get projects “off their islands,” saving developers a lot of code, and companies a lot of money, among other benefits.

I apologize for the poor audio quality in this recording and hope the quality of the conversation makes up for it.

Selected quotes from this conversation with Beth Tucker Long:

"All right. Hello, Drupal. My name is Beth Tucker-Long, and I am so excited that Drupal 8 is out. Way to go! We’re very proud of you. I am really excited about Drupal 8 because it represents so much community involvement, working together. I’m so excited that we have so many big projects from the PHP side of things and the Drupal side of things working together, and I just can’t wait to see, with all this brainpower that we have merged into this project, where we go from here."

“I really love the fact that now we can say, “Hey, we are all PHP developers, and these are the technologies that we use to help us, and as PHP developers, we are putting forth these standards, so we can all work together and not be so splintered.” That was my main motivation for supporting FIG.”

"As long as we, as a community, are encouraging new developers to be FIG-compliant as they come into it, non-FIG-compliant code is going to start looking like old legacy code."

"So, writing a quick and dirty thing 10 times is going to take longer than writing it the right way once and being able to reuse it."

Guest dossier
Interview video - 27 min.

Full conversation transcript

jam: We are Campbell Vertesi ... My name is Jam. I work for Acquia. My title is Evangelist and I’m in Developer Relations. We have a special guest today. Would you like to introduce yourself?

Beth: I am Beth Tucker-Long, and I am an independent consultant working with PHP. I do work with Drupal on a number of my projects and lots of other things, because as a consultant, I work on whatever you’ll pay me to work on, so ... the life of a consultant.

jam: Right. Over the last however many years it’s been, you were actually, in a way, at the center of what I like to call the PHP Renaissance, so you were definitely a keen observer of this coming together of all these different PHP technologies from being very disparate, siloed implementations of the language back to being something like community. I’m thinking particularly of your role at php[architect].

Beth: Yes. I worked at php[architect] for seven years. I was involved in Tek when PHP-FIG was started at php[tek], and it was a very exciting time. Also, I was doing consulting then as well, so it’s an exciting time for me as well because having to work with all these disparate technologies that did not work well with each other at all was frustrating, and now it is becoming a much happier place for people to work together.

Campbell: One of the things that we’ve talked about with some of the other people is exactly what you say, that consultants for a lot of developers out there, we have to be able to jump between different technology stacks, between different frameworks. This “FIG era” makes it a lot easier for that. Was that a founding motivation for you to get involved in this, or were there other things behind it? What do you think is the best benefit that made you wanted to get involved in PHP-FIG?

Beth: Sure. I should clarify. I’m not directly involved in PHP-FIG because I’m not a project owner. I am just a big supporter of what FIG is trying to do and a big encourager of trying to get other people who are project owners involved in FIG and encouraging a few people to follow the standards that FIG is setting forward. As a consultant, I have seen so many different people’s code, and I have tried to work to get so many different people’s code to work together and without any standards ... It was a very frustrating time, shall we say. So many people and so many projects had this pride of, “Well, you can obviously tell people are working on my project, because their code looks like this.” While that is a neat thing to be able to say, “My code looks different from everyone else’s because I am an ex-application developer,” it makes it really hard for anyone who has to come in and work with your code who is not familiar with that, or who has to try to get your code to talk to somebody else’s code. So, I really love the fact that now we can say, “Hey, we are all PHP developers, and these are the technologies that we use to help us, and as PHP developers, we are putting forth these standards, so we can all work together and not be so splintered.” That was my main motivation for supporting FIG.

jam: It makes us much more efficient developers. Not only can we reuse a lot more good supported code but once we’ve learned a set of principles as long as whatever else we want to work with is meeting PSR standards, for example, then we can probably jump right in to them and get to work.

Beth: Definitely, even projects that don’t support the FIG standards yet. I think it still makes things easier as a whole because so many projects are becoming more open to working with other projects so even if they haven’t necessarily gotten all of the standards, at least projects are now aware that people want them to work together and so the development that’s happening moving forward, even if it’s not officially FIG-compliant, seems to be supporting the mindset of “We need to work together,” and “I want my code to be reusable in other places and easy to be reused.” Even if projects aren’t necessarily on board with FIG, I feel that just the landscape mentality has changed as a whole to something more positive because of the work that FIG has been doing.

jam: So, set the scene. You were probably even a co-organizer. You were at php[tek] when late one night, I don’t know how many people had this crazy idea. In German, we might call it a “Schnappsidee,” which is the kind of idea you have when you’re having schnapps. Like, “Well we need to ... this all needs to ... let’s make a standards group, let’s see.” You were there, right? Set the scene. How was that? What was going on?

Beth: Actually, I was working at that time. So I was in the building but not in the room when it happened but the stories that I’ve heard. A dark, hazy room with lots of alcohol and lots of cheering and yes. You know? Like all great ideas are born, right?

jam: Yes. So, Cal Evans told me that the people that were in the room thought it was a great idea and put this thing together and then there was a lot of hate. What happened next?

Beth: Yes, there was a lot of hate afterwards. I feel that with most landscape-changing decisions ... as a species, we really dislike change. So, anytime there’s something new, there’s always resistance. This was a really big shift in mentality, and there was a lot of animosity about, “Who do these people think they are telling me I have to conform to the standards they think are best?” There was a lot of, “I’m fine if we all get along as long as we’re doing my standard, not yours.” So, right away, the animosity I felt at least was not necessarily towards the idea of standardizing and working together, which is nice, but there was a lot of animosity about whose standard we were going to use and why certain people had the right to tell other people to standardize on which standard. That took several years of working through and probably still isn’t quite officially worked through but it is getting better.

jam: I think also that the name change that the group underwent fairly rapidly also helped the shift in perceptions. Originally, it was founded as something like a standards, a “PHP Standards Group” or standards something.

Beth Yes, “Standard Compliance Group” or something.

jam: Right and renaming it the Framework Interoperability Group immediately gave it a much more positive spin.

Beth: Yes, it did. Although then, there’s a lot of complaints about, “Well, I’m not a framework but ...” you know. So, you can never make everyone happy but it does put it in a much more positive light. Like, “We’re all working together. Let’s embrace the part of the idea that everybody seems to like and then we’ll work on the parts that people don’t like.”

Campbell: With this in mind, what do you think is the most important PSR in terms of actually unifying what people do?

Beth: The actual FIG PSR, you mean?

Campbell: Yes. You’re allowed to choose ones that haven’t been accepted yet. We won’t tell.

Beth: Oh my goodness. The most important FIG PSR...

Campbell: In terms of making it easier to work together.

Beth: I guess in my day-to-day life, the PSR that affected me the most are the actual coding standards just because I don’t write a major framework. So, some of the requirements about how to write your framework to work with other things, it’s already architected by the time I get it so I just use it. But the spacing issues and the format issues which cause so much ire in the community, those are the ones that affect me most day-to-day and the ones that I try to get people who work with me to follow the most because if our code all looks the same, it’s a lot easier to scan through. It’s a lot easier to read through. It has really made things easier coming into a new project if they follow the FIG coding standards as well. So, I would say probably on a big scale, that’s probably not the most important one community wide, but that’s the most important one in my day-to-day life.

Campbell: In some way, I wonder if we’ll start seeing a peer-pressure effect this way. I mean, I worked really hard to get my personal code to follow PSR 0 and 1 under a month.

jam: No, one and two.

Campbell: One and two.

Beth: Yes. It can be started with one and then we can move in to two.

Campbell: Yes, which is exactly what I did, and then I popped open Drupal 8 and started to rage that, “Dang it! Those crazy - are still using two spaces to indent. It should be four!”

jam: That’s where FIG got it wrong, though, because two spaces is the one true way. Not tabs, not four spaces.

Campbell: Absolutely. And we will defend that!

Beth: I know!

Interviewer: So we’re out!

Interviewer: No, but I wonder if...

Beth: That’s it. Throw is all away and start over!

Campbell: I wonder if we’ll start to see a bit of peer pressure, that you get developers coming into projects that are relatively PSR-friendly or FIG-friendly like Drupal and then well, I write with four spaces and cirly braces on the next line. Sorry about your...

Beth: Yes. I think what will happen over time is that... as long as we, as a community, are encouraging new developers to be FIG-compliant as they come into it, non-FIG-compliant code is going to start looking like old legacy code. So, I think you’re right in that there probably will be some peer pressure in the fact that you don’t want your code to look old the moment you write it. So, it will start to be the way to tell old code, I guess, from newer code.

jam: How do you feel about Drupal 8?

Beth: Just in general?

jam: I could – so, how do you feel about Drupal 8 as the first product of this convergence in PHP? Somehow, the dependency management and code interoperability has produced this meta-product which is a combination of code from across a dozen ... 20 different open source projects, and we call it Drupal 8 but it’s a really magnificent combination of different stuff.

Beth: My favorite thing about that besides the fact that I think it’s going to become a lot easier to work with, is that it has really forced the issue of getting our communities to work together. We’ve, for so long, been siloed into, “Oh, I’m a PHP developer. I only write plain old PHP. I’m a Drupal developer, I only work with Drupal. Or I’m a Symphony developer. I only work with Symphony.” We’ve just been so isolated in what we’ve done. Now, we have one project where all of those people are together into one project is, I think, forcing the community to address the issue of how isolated we’ve become and allowing us to all have a project that we can contribute to, that we can work with, that we can feel a sense of pride because our personal piece of PHP is participating, and is a part of this project. It’s really allowing so much more community between just being the different developer types, and I’m excited to see more projects pulling in those different viewpoints and I guess capitalizing on the fact that different communities have different specialties and different ways of looking at things and analyzing things and different worst-case scenario-planning, and we can all benefit from the sharing of this knowledge that we’ve grown in each of our different areas.

Campbell: We’ve had some great conversations, especially at PHP conferences and Symphony conferences with people. We’ll go and present to them and talk about Drupal 8 as this first integrated product and what you can do with it. Before the session, people go, “Oh, I don’t use a CMS. I build it all off from scratch,” and it sounds like I feel like I’m talking to somebody from 2009. Really...

Beth: Yes. A lot of us were around then ...

Campbell: They really poo–poo the idea just because it’s CMS or because they would have used Drupal in 2009 in 2007, right? Then we can give a presentation and go, “Oh well, this is how you architect a large multi-headed beast where this CMS is just a part of it. It fits smoothly into the rest of it.” It really – I mean I feel like this can really change people’s perspective on actually, how they work with different frameworks - also from [Unintelligible] ... It’s a component.

Beth: Yes.

jam: Outsource don’t write a CMS ever again. Outsource that to Drupal 8 and get on with what’s interesting.

Beth: One of the great things about this now when you’re talking about - talking to those people who are, “I do it all from scratch, I don’t need to,” or “I only use this. I don’t need to use anything else.” is that the conversation now is not, “You have to stop using your thing and switch to ours,” because that’s what the conversation has always been. Now, we don’t have to tell people to give up their technology. Now, we say, “Your technology is awesome and you can use it with ours to make things even better.” So, I think the discussion is getting more friendly as well, so yes.

jam: Now, take your awesomeness and ours and let’s put it together.

Beth: Yes, and something even bigger.

jam: Instead of our awesomeness is clearly more awesome than yours, you should as well.

Beth: Exactly, because that’s instantly a confrontational discussion. So, now we’re working together instead of confronting.

Campbell: So, we talk a lot with other consultant-developers of, like jam said, our first time we’re giving this session is going to be in Mumbai. One of the things we’ve heard a lot from shops that are going to be in our session is they’re not interested in standards, they’re not interested in best practices. They’re interested in just get it done. You got to get it out of the door fast, and I’m going to jump in and do it quick and dirty. It’s partly because people have to learn to work with new frameworks quickly, and it’s partly just because of the, frankly, the case of business. What’s your argument? Why should these people care about the “Interoperability Era”?

Beth: As a consultant, I completely understand that mindset at times. Because when you’re a consultant, people are not paying you to learn new things. They are not paying you to spend time to do things the right way because the people hiring you don’t understand what you’re doing on the backend, all they understand is how long it takes you to do it, and how much that’s going to cost them and they don’t care about anything beyond that. So, it becomes very difficult to, I guess, convince yourself that you need to have that time to do those things, and learning a new framework is a big undertaking. It’s a lot of work. It’s a big shift in how you do things. It makes it uncomfortable to code again for a while because you’re retraining even just your fingers on how to type. It’s amazing the muscle memory that you get coding things. It’s a big shift. It’s a lot of work, and there’s no immediate benefit to that work. It’s not instant benefit. It’s a long-term benefit.

So, when you’re in the thick of things and you’re stressed, and you have a deadline looming, those long-term benefits are really hard to buy into. So, what I try to do with the other consultants that I work with or with the clients that I work with is I try to really quantify those long-term benefits. Sometimes I win and sometimes I don’t, but I try to, at least, make people aware that there are long-term benefits and consequences of these rushed decisions that you’re making and these shortcuts you’re taking. I hope at least that people are making an informed decision when they decide to do things quick and dirty. In some cases, maybe quick and dirty is fine. “Hey, we’ve got this thing. We’re only using it for a couple of weeks. I swear we’re going to throw it away for real this time.”

jam: “Nothing lasts longer than a temporary fix.”

Beth: I know, right? I know. But, on the flip-side, like you said, things last forever. If you do it the right way, it’s easier to reuse it in the future. So, writing a quick and dirty thing 10 times is going to take longer than writing it the right way once and being able to reuse it.

Campbell: One of the things we’ve heard from Sebastian Bergmann that – is that time and again, studies have shown that yes, okay, there’s a 30% extra time requirement when you start writing unit tests the first time you code. Hard to get your head around, it’s a slow process that takes you longer. But in the long run ...

Interviewer: You make that up and then you get a 60% productivity gain in the best cases by building tests into your development workflow.

Beth: Yes.

Campbell: Yes.

Beth: Yes. The problem is that a lot of these consulting companies are only involved in that beginning timeframe. So, they’re required to take on that burden if the extra 30% work on the front end, but they never see the 60% gain because they’re no longer on the project when that comes into play.

jam: Although I wonder if another perspective on this efficiency of tools discussion would be, “Hey, so Drupal 8 might be a lot to wrap your head around.” You have to learn this new CMS and figure out a module system in whatever you’re doing but once you have a toolset that’s quite comprehensive and solves a lot of the web use case and you’re fluent in it, then ... I know there’s no data out there, but I imagine that you also gain a productivity win and then because I’m a fanboy, I can also say, “Well, it’s probably more secure when it’s really well-maintained and supported and so of course, you know, that’s a bonus as well.”

Beth: Sure. From the consultant viewpoint, that’s true as long as you are able to choose the technology stack that you’re working on, but in many times in consulting, we don’t get that choice. So, you spend all this time investing and becoming fluent in Drupal and then you get a slew of WordPress projects, and it doesn’t help you at all. That can be a very tough buy-in as well from the consulting viewpoint. But I think that if we can continue to get buy-in from the project owners and managers who are architecting these systems then the consultants that come in will have to take up that viewpoint as well because that will be the environment that they’re working on. So, the consultants tend to work more in legacy systems than in newer systems because newer systems tend to have a developer team who’s working on it and they don’t bring in consultants right away. You bring in consultants when, “Oh, my gosh. That’s horrid code. I don’t want to look at it. Bring in a consultant because I’m too busy just trying to put out these fires over here, to keep things running.” That’s when the consultants get brought in. So, I think the buy-in has to be from the project owners first before we ever have a hope of getting consultants onboard.

jam: Hopefully over time, we’re going to see more and more products that use, for example, PSR-compliant methodologies ... testing and what have you ... and over time, your job as a consultant will become better, more bearable, more productive because you’re going to see more compliant code, stuff that you understand off the bat, things that have been tested along the way.

Campbell: Well, I think at the very least might be the easy one to convince people of is using external libraries, and having something available like Composer or having something available like proper dependency injection means you just need to write less code.

Beth: Definitely. Component libraries are usually an easy thing to convince people of. Although in some consulting projects, you’re not allowed to use external things that aren’t already on the server, so that can be a tough sell. It depends. But with the component library, if you can’t use it, you still have to write it from scratch, so if you can use it some of the time, it’s still an improvement over not being able to use it any of the time.

Campbell: I was going to say I’ve never encountered that. I remember one project five or six years ago where the environment was such like we couldn’t get anything installed on the server or any components without going through an IT approval. This was for a university. This wasn’t like a high-security project but we had to go through ... So, every couple of days, there was another email and because in our case, it was every Drupal module we had to ask permission.

Beth: Yes.

Campbell: Like we use a hundred modules on that project.

Beth: Yes and anything dealing with healthcare or medical industry... Everything has to be audited and approved by a security team before you can use it. So, using a whole bunch of different component library stuff can be an excruciatingly painful process in those types of environments. Which is why most types of environments, hopefully, they’ve had a framework approved, and at least you have a framework that you can use.

Campbell: That’s the easy win, actually. At least healthcare, and there are certain environments there, the security is warranted. That one was really the brochureware front end for the university. “You need to authorize what slideshow we’re using?” :-D

jam: So, we’d like you to do a specific greeting to our session and to the Drupal world. Most people are going for something like, “Hi, Drupal. My name is such and so, and congratulations on getting v8 out, and welcome to the broader PHP world. I’m excited you’re here because,” or “You should be excited about the following,” or some upbeat statement like that, welcoming us into the fold, essentially.

Campbell: Welcome us into the fold and tell us why we’re excited or why you’re excited about it.

Beth: Okay.

Campbell/Beth: Now.

Beth: All right. Hello, Drupal. My name is Beth Tucker-Long, and I am so excited that Drupal 8 is out. Way to go! We’re very proud of you. I am really excited about Drupal 8 because it represents so much community involvement, working together. I’m so excited that we have so many big projects from the PHP side of things and the Drupal side of things working together, and I just can’t wait to see, with all this brainpower that we have merged into this project, where we go from here.

jam: You want to come to a DrupalCon?

Beth: Do I want to come to the DrupalCon? I would love to.

jam: Beth, thank you so much for taking the time to talk with us.

Beth: No problem.

jam: We really appreciate it. I look forward to seeing you in person soon. Perry, thank you for being so patient and sleeping until right now. That was...

Beth: Very good timing. Good job.

Cam: Yes.

jam: Perry’s first podcast. Thanks, Beth!

Beth: Yes. No problem. Awesome.

Podcast series: Drupal 8Skill Level: BeginnerIntermediateAdvanced
Categories: Drupal

DrupalCon News: Wanted: Explorers of Tech Horizons

15 December 2016 - 8:37am

The Horizons track at DrupalCon, as the name suggests, challenges us to explore what’s on the horizon of web- and internet-based technology, and how Drupal can enable software developers to pursue and meet these new challenges.

We asked around a bit and gathered a list of suggested topics—emerging or new technologies—that you as Drupal developers and agencies are creating solutions for and exploring as new market opportunities.

Categories: Drupal

Acquia Developer Center Blog: Bootstrapping BLT: Use the Bootstrap 3 Theme with BLT

15 December 2016 - 7:13am

For a recent project, I needed to use the popular Bootstrap theme, using the Sass starterkit for easy CSS management.

The project is hosted on Acquia Cloud, and the quickest way to start a new Drupal project that deploys to Acquia Cloud is to use BLT (a tool for Building, Testing, and Launching Drupal sites). BLT is an automation framework for running and building Drupal sites locally (it even integrates with Drupal VM!), and it is able to test, build, and deploy code on Acquia Cloud.

Tags: acquia drupal planet
Categories: Drupal

Flocon de toile | Freelance Drupal: Generate programmatically image styles with Drupal 8

15 December 2016 - 5:07am

Drupal 8 allows you to generate image styles for various effects (reduction, cut-out, black-and-white, saturation, etc.) for each uploaded image. You can very quickly have many images styles, and even more if you use responsive images, allowing to propose different dimensions according to the terminal used to consult your website.

Categories: Drupal

Triquanta Web Solutions: Drupal 8's functional JavaScript testing just got better with visibility

15 December 2016 - 12:36am
Drupal level: advanced

Yesterday a patch for Inline Form Errors landed in Drupal, which as a by-product, brought us a new useful testing possibility: we can now more easily write tests that check if elements on a webpage are actually really visible in the viewport. The visibility of page elements in different scenarios is important for the usability and accessibility of your site.

Drupal 8 comes with exciting "new" testing possibilities, the latest addition was Functional JavaScript testing. Which enables us to automatically test if our JavaScript interactions work and keep working throughout the development process. The tests are run in the PhantomJS headless browser. Simulating interaction with this browser is handled by Behat's Mink. For a bit more background and how to set this up locally checkout this Chapter Three blog.

Visibility testing hardship \Behat\Mink\Element\NodeElement->isVisible()

Now let me first warn you that visibility testing can be quite tricky to grasp if you just start out. For example Mink has a method isVisible() and I was tempted to believe that this method checks that a user can see the targeted element on his screen. But nothing could be further from the truth... it only checks that the element is not styled explicitly invisible. So, for example, if you have some CSS styling like display: none;  or visibility: hidden; on an element this isVisible() assertion would fail. However if your element is not explicitly hidden, but is outside your devices viewport or is being obscured by an overlapping element, you are out of luck with this assertion. Your test would pass with flying colors, while the users sees nothing.

Another thing to note for if you'd want to dig in this matter more: as a Drupal user you probably by now interpret the word node as an object or entity with data that is primarily being use to publish content. In our testing context however it has to be understood as a DOM element which can be targeted by using a CSS selector or XPath. In this article I'll continue to use element.

New assertions \Drupal\FunctionalJavascriptTests\JSWebAssert->assertVisibleInViewport()

To work around the first problem of elements falling outside the viewport of a users device, we added a new assertions to Drupal's JSWebAssert class. It is now possible to check if an element is in (the defined) viewport or not using the assertVisibleInViewport() and assertNotVissibleInViewport() methods respectively.

You can target the to be tested element with CSS selectors or XPath and test if a certain corner or the whole element is visible in the viewport.

'How to use' examples

Let's assume the following for testing purposes prepared "Create page" interface of Drupal with an overlay helper of the viewport size.

To check if, in a certain situation, the header title is visible within the viewport you'll first have to define the viewport size. This can be done with a PhantomJS startup arguments and/or during runtime with the method \Behat\Mink\Session->resizeWindow(). In case of testing with the testbots on a default viewport as shown above will be setup for you. From your own Drupal project root you can start the headless browsers using the following command. The last two parameters indicate the default width and the height of the viewport used during your tests.

/path/to/phantomjs --ssl-protocol=any --ignore-ssl-errors=true vendor/jcalderonzumba/gastonjs/src/Client/main.js 8510 1024 768

Now you can use our new assertion to check if the header title is completely visible (partial code snippet):

$web_assert->assertVisibleInViewport('css', 'h1', FALSE, 'The page header title is not visible.');

In case of our first example the user (robot) scrolled down and the header title is not visible (the element is outside the green region). So the assertion would fail. How to setup a complete functional JavaScript test is outside the scope of the article, but you can use the recently commited CKEditor test code as an example.

For our second example we use a viewport of a mobile device. The user just loaded the page and hasn't scrolled down. For testing purposes we pushed the body field a bit down. And we see that the CKeditor of that field is partly visible (in the red area). By default the method tests the visibility of all four corners of a (rectangular) element (third parameter value: FALSE). With the third parameter we can tell the method to check a certain corner for visibility (topLeft, topRight, bottomRight or bottomLeft).

So the assertion given below will pass because the top left corner of the element is within the viewport (red area). But by default it would have failed, because not all corners are visible.

$web_assert->assertVisibleInViewport('css', '#cke_edit-body-0-value', 'topLeft', 'The top left of the CKEditor enabled body field is not visible.'); Final notes

To actually see the used viewport in a screenshot, a patch is available in an ongoing issue on Chime in if you would like this possibility in core. It has been used to generate the illustrations in this blog. And remember, visibility testing doesn't take into account that the element could be obscured by another element. So for now, using printscreens, is the only out-of-the-box way of checking if an element is really really visible. Time for another assertion?

Questions or comments? @dmsmidt

Categories: Drupal Blog: AGILEDROP: Drupal Camps in Oceania

14 December 2016 - 10:42pm
Remember where we have finished in our world tour of Drupal Camps? Let us refresh your memories. After Africa, Asia, North America, Europe and South America it was time for Middle America to shine. Only two Drupal Camps were found there, so we hoped for more Drupal activity in Oceania. Our hopes were fulfilled. Like in the case of Africa, most Drupal Camps are taking place in one country. In fact, in this case, all of the Drupal camps took place in Australia in contrast to South Africa, which hosted a majority of the events. That was not the case in the past, because New Zealand also helped… READ MORE
Categories: Drupal

Lullabot: HTTPS Everywhere: Security is Not Just for Banks

14 December 2016 - 12:00pm
Why Does HTTPS Matter?

HTTPS has been around for a while, but it’s generally not well-understood. Many people know that sites using HTTPS instead of HTTP will display a lock on the URL to tell users that the site is safe to use. Everyone knows that big ecommerce websites have to use HTTPS. Many people are aware that HTTPS is a good idea for login pages and other form pages on any site. But does it matter for every day web pages and sites? Increasingly, the answer is YES, even for small sites and non-form pages.

HTTPS protects end users from eavesdroppers and other threats. Because of all the security ramifications of plain HTTP, Google is putting its considerable weight behind efforts to encourage websites to become more secure with an “HTTPS Everywhere” initiative:

HTTPS is also a requirement for some new interactive functionality, like taking pictures, recording audio, enabling offline app experiences, or geolocation, all of which require explicit user permissions. So, there are many reasons for website owners and users to pay attention to it.

What Does Insecurity Look Like?

As an experiment, to see exactly what level of security HTTPS gives the user, I visited two sites, one HTTP, and one HTTPS. Our Senior Systems Administrator, Ben Chavet, acted like an eavesdropper. He wasn’t even sitting next to me. He was 800 miles away watching my traffic over the VPN I was using. It took him just a few minutes to pick up what I was doing. What he did could have been done by someone in a coffee shop on a shared network, or by a “Man-in-the-Middle” somewhere between me and the sites I was accessing.

When I logged into the plain HTTP site, my “eavesdropper” could see everything I did, in plain text, including the full path I was visiting, along with my login name and password. He could even get my session cookie, which would allow him to impersonate me. Here’s a screen shot of some of the information he was able to view.


But when I logged into a site protected by HTTPS, the only thing that was legible to my “eavesdropper” was the domain name of the site, and a couple of other bits of information from the security certificate as it was being processed. Everything else was encrypted. 


There are other problems with plain HTTP. An eavesdropper could steal session cookies to emulate a legitimate user to gain access to information they shouldn’t be able to see. If an attacker has access to a plain HTTP page, they could change links on the page, perhaps to redirect a user to another site. Or by encrypting form submissions (but not the form itself) an attacker can modify a form to post to a different URL. A valid HTTPS page is not vulnerable to these kinds of changes.

Clearly, HTTPS offers a huge security benefit!

What Does HTTPS Provide?

Let’s back up a bit. What exactly does HTTPS give us? It’s two things, really. First, it’s a way to ensure data integrity and make sure that traffic sent over the internet is encrypted. Secondly, it’s a system that provides authentication, meaning an assurance that the site a user is looking at is the site they think they are looking at.

In addition to obfuscating the user’s activity and data, HTTPS means the identity of the site is authenticated using a certificate which has been verified by a trusted third party.

If you get to a site using HTTPS instead of HTTP, you are accessing a site that purports to be secure. On an HTTPS connection, the browser you use (i.e. Internet Explorer, Safari, Chrome, or Firefox) and the site’s server will communicate with each other. The browser expects the server to provide a certificate of authenticity and a key the browser can use to encode and decode messages between the browser and the server. If the browser gets the information it requires from a secure site, it will display a safety lock in the address bar. If anything seems amiss, the browser will warn the user. Problems on an HTTPS page could be a missing, invalid, or expired certificate or key, or “mixed content” (HTTP content or resources that should never be included on an HTTPS page).

Identity, data integrity, and encryption are all important. A bogus site could still be encrypting its traffic, and a site that is totally legitimate might not be encrypting its traffic. A really secure site will both encrypt its traffic and also provide evidence that it is the site it purports to be.

How Do Users Know a Site is Secure?

Browsers provide messages for insecure sites. The specific messages vary from browser to browser, and depend on the situation, but might include text like “This page may not be secure.” or “The certificate is not trusted because it is self signed.” Most browsers display some color-coding that is expected to help convey the security status.  

If a site is rendered only over HTTP, browsers usually don’t indicate anything at all about the security of the site, they just provide a plain URL without a lock. This provides no information, but also no assurance of any kind. And as noted above, unencrypted internet traffic over HTTP is still a potential security risk.

The following chart illustrates a range of possibilities for browser security status indicators (note that EV is a special type of HTTPS certificate that provides extra assurance, like for bank and financial sites, more about that later):


For more information about the HTTPS security, users can click on the lock icon. The specific details they see will vary from browser to browser, but generally, there is a link with text like “More details” or “View certificate” that will allow the user to see who owns the certificate and other details about it.


Research about how well end users understand HTTPS security status and messages found that most users don’t understand and ultimately ignore security warnings. Users often miss the lock, or lack of a lock, and find the highly technical browser messages to be confusing. The focus on color to indicate security status is a problem for those that are color blind. Also, so many sites still use HTTP or are otherwise potentially insecure that it is easy for users to discount the risk and proceed regardless. The conclusion of all this research is that better systems need to be put in place to make it clear to users which sites are secure and which aren’t, and to encourage more sites to adhere to recommended security best practices.

A while ago, Chrome started to let users understand how secure a site is. These examples use a combination of color and shape to convey what’s secure and what isn’t. Currently, the plain HTTP site is more noticeably a security threat.


Starting in January of 2017, they plan to add text saying ‘Secure’ or ‘Not secure’ for even more emphasis:


Other browsers may follow suit to make plain HTTP look more noticeably insecure. Between the user safety, the SEO hit, and the security warnings that may scare people away from sites using plain HTTP, no legitimate site can really afford to ignore the implications of not serving content over HTTPS.

What Do All the Terms Mean? 

HTTPS terminology is confusing. There is a lot of jargon and countless acronyms. If you read anything about HTTPS, you can quickly get lost in a sea of unfamiliar terminology. Here is a list of definitions to help make things more clear.

Secure Socket Layer (SSL)

SSL is the original standard used for encrypted traffic sent over HTTP. It has actually been superseded by TLS, but the term is still used in a generic way to refer to either SSL or TLS.

Transport Layer Security (TLS)

TLS is the new variation of SSL, but it’s a newer, more stringent, protocol. TLS is not just for web browsers and HTTP, it can also be used with non-HTTP applications. For instance, it can be used to provide secure email delivery. TLS is the layer where encryption takes place.


HTTPS is just a protocol that indicates that HTTP includes the extra layer of security provided by TLS.

Certificate Authority (CA)

A CA is an organization that provides and verifies HTTPS certificates. “Self-signed” certificates don’t have any indication about who they belong to. Certificates should be signed by a known third party.

Certificate Chain of Trust

There can be one or more intermediate certificates, creating a chain. This chain should take you from the current certificate all the way back to a trusted CA.

Domain Validation (DV)

A DV certificate indicates that the applicant has control over the specified DNS domain. DV certificates do not assure that any particular legal entity is connected to the certificate, even if the domain name may imply that. The name of the organization will not appear next to the lock since the controlling organization is not validated. DV certificates are relatively inexpensive, or even free. It’s a low level of authentication, but provides assurance that the user is not on a spoofed copy of a legitimate site.

Extended Validation (EV)

Extended Validation certificates validate the legal entity that controls the domain as well as the fact that they have actual control over the domain. The name of the verified legal identity is displayed in the browser, in green, next to the lock. EV certificates are more expensive than DV certificates because of the extra work they require from the CA. EV certificates convey more trust, so are appropriate for financial and commerce sites.

Next Steps

It seems pretty clear that HTTPS is important. In my next article, HTTPS Everywhere: Making the Switch, I’ll talk about what it takes to migrate a site from HTTP to HTTPS.

More Reading How HTTPS works How HTTPS affects SEO ranking Browser clues about website security How a password can be stolen over an insecure connection Types of Certificates
Categories: Drupal

Redfin Solutions: Starting Out With Sketch and Drupal

14 December 2016 - 9:53am
Ruth December 14, 2016 Starting Out With Sketch and Drupal

One of my big projects this past summer as an intern at Redfin was to learn about the design software Sketch. This was supposed to culminate in a small presentation just to the office, but I ended up giving a presentation at a “birds of a feather” session at Design4Drupal in Boston. A couple people who missed it asked if I could record it, so I made a video of it once I got back to Portland.

Categories: Drupal

DrupalCon News: Built By Humans for Humans

14 December 2016 - 8:57am

Last spring DrupalCon North America in New Orleans was attended by 3,102 Drupal community members, in the fall 1,787 of you came to Dublin for DrupalCon Europe. That's a whole lot of human beings getting together to talk about the Drupal software, development processes, tools, business strategies, future directions and more. All of which are important. But, I want to talk about all of those human beings. What makes you tick?

Categories: Drupal

OpenLucius: Update OpenLucius | December 2016

14 December 2016 - 8:51am

We updated OpenLucius, an open source work management system -contributed as a Drupal distribution. These are the 5 most important improvements:

1.Modern layout for folders and files

The app ‘files’ takes care of central management of files and folders. Prevents messy document management on 'G-drives' and in email boxes. You can see the old layout in this video (we will update it soon):

The new layout:

Top 3 improvements:

  • Added thumbnails of images
  • Mobile ready, so you can tap on file/folder with your finger.
  • See where a file originated from (a message, task, event or ‘isolated file upload’), who placed it and when.
2. New group overview
Categories: Drupal

Acquia Developer Center Blog: Decoupled Drupal with Ember: Introducing Ember and JSON API

14 December 2016 - 7:03am

Decoupled Drupal has long been an approach touted by some in the front-end contingent of the Drupal community to achieve goals such as a better user experience, a more modern front-end developer experience, and clearer separation of concerns.

Tags: acquia drupal planet
Categories: Drupal Are you a spammer without knowing it? Beware the Print Mail module!

13 December 2016 - 11:52am

One of the really interesting things about providing support and maintenance for lots and lots of sites is that you get to see patterns or certain issues affecting several sites, that you might not notice if you're only responsible for a handful of sites.

Not only does this add to our knowledge base of solutions when a customer has a problem, but it can sometimes allow us to preemptively find a problem before a customer even knows they have it (or point it out when we do a FREE site audit).

Anyway, here's a request we've recently gotten from a couple of customers:

Is our web site compromised?!

Our hosting provider says that we've been sending hundreds of e-mails a day that are setting off alarms with their SPAM filter.

Please help!!!!

It turns out that none of the affected websites were hacked -- it was just a matter of spammers taking advantage of a particular Drupal module: "Print Mail" a sub-module of Print.

It's not a security vulnerability - they're using normal features of the module, just at scale with automation.

If you use this module on any of your sites, or are considering enabling it, please read on for an explanation of the problem and some possible solutions.

Categories: Drupal

Four Kitchens: Stranger in a Strange Land — WordCamp US Trip Report

13 December 2016 - 10:26am

Web Chef Randy Oest got some perspective from the other side at WordCamp US […]

Categories: Drupal

Acquia Developer Center Blog: Contribution Stories: Nida Ismail Shah, The State of Hooking into Drupal

13 December 2016 - 9:53am

Drupal gets better when companies, organizations, and individuals build or fix something they need and then share it with the rest of us. Our community becomes better, stronger, and smarter when others take it upon themselves to make a positive difference contributing their knowledge, time, and energy to Drupal. Acquia is proud to play a part, alongside thousands of others, in some of the stories making tomorrow’s Drupal better than today’s. One of them is Nida Ismail Shah’s.

Tags: acquia drupal planeteventshooksSymfonydispatchercoremodule
Categories: Drupal

InternetDevels: The Field image tooltips Drupal module by InternetDevels developers

13 December 2016 - 6:17am

InternetDevels developers working at JYSK shop chain project, keep creating new Drupal modules for the community. In the previous blog post, you could check out the Gridstack field module. This time, we present the Field image tooltips module, which is also ready for Drupal 7 and Drupal 8. As it is our tradition, the author himself is going to introduce the module.

Read more
Categories: Drupal

A Dev From The Plains: Overwriting global permissions within Organic Groups for single page requests

13 December 2016 - 5:56am

In a recent project built in Drupal 7, I came across a bit of an uncommon scenario, by which some users needed to have access to certain features that were normally restricted to them, when viewing, editing or creating groups content (ie: whenever they are visiting a part of the site that is considered part of a group).

For example, while normal users didn’t have access to use certain text formats in the wysiwyg editor, those that were considered group leaders needed to make use of that particular text format. In this scenario, a group leader was an existing role within Organic Groups.

While a simple solution could be a dedicated, global user role that is assigned to users when they become group leaders, and assign any extra permissions to that role, it wasn’t the right solution for this scenario, because a user could be a group leader for some groups, but just a normal group member for other groups, whereas the permissions needed to be applied specifically for the groups in which the user is a group leader. In other words, permissions had to be resolved dynamically depending on what group a user is working on at any given moment.

So, what other options are there available to accomplish this? One would be to use drupal alters and hook mechanisms to change the way each feature restricts access to users, but that will become messy very quickly, particularly if you have to do it for several features, in which case each one might need to be tackled in a different way. Besides, what looks simple on the surface, might involve some more hacking and tweaking than expected: for example, for wysiwyg-related alters, hacks need to be made not only when rendering the wysiwyg editor, but also when validating the input data.

I was looking for a more generic solution that could be easily applied and extended to any feature on the system, and I found it while reviewing the user_access function from Drupal core. Code below:

function user_access($string, $account = NULL) { global $user; if (!isset($account)) { $account = $user; } // User #1 has all privileges: if ($account->uid == 1) { return TRUE; } // To reduce the number of SQL queries, we cache the user's permissions // in a static variable. // Use the advanced drupal_static() pattern, since this is called very often. static $drupal_static_fast; if (!isset($drupal_static_fast)) { $drupal_static_fast['perm'] = &drupal_static(__FUNCTION__); } $perm = &$drupal_static_fast['perm']; if (!isset($perm[$account->uid])) { $role_permissions = user_role_permissions($account->roles); $perms = array(); foreach ($role_permissions as $one_role) { $perms += $one_role; } $perm[$account->uid] = $perms; } return isset($perm[$account->uid][$string]); }

As you can see, the permissions are fetched for a given user (if they haven’t been already gathered in the current page request), and then statically cached, so that on subsequent calls they don’t need to be fetched from the database again. The key line of the code above that allows custom code to override system permissions, is this:

$drupal_static_fast['perm'] = &drupal_static(__FUNCTION__);

The drupal_static() function is a mechanism provided by Drupal core to serve as a central static variable storage. Due to the way it works, it is possible for a custom module to call the function with a parameter to get the values stored in it by some other function. More importantly, because it always returns a variable by reference, it means the returned values can be replaced or modified as we please. In this particular case, user_access() maintains the permissions for a given user, as a reference to the values stored by drupal_static().

Knowing this, all I had to do was calling drupal_static() as if it was being called from user_access() itself, and modify the variable returned by reference, to inject permissions dynamically. The best place to do this was in a hook_init() implementation, to make sure all the permissions are in place from as early as possible in the page request. This can be done in just a few lines of code:

/** * Implements hook_init(). */ function mymodule_init() { // Check if request is a group context and inject group-specific logic. if ($og_context = og_context('node')) { global $user; $group_id = $og_context['gid']; /* * This would include some code to check if the user is a group leader... */ // Issue a call to drupal_static(), on behalf of 'user_access' function. $drupal_static_fast['perm'] = &drupal_static('user_access'); $perm = &$drupal_static_fast['perm']; // Add / remove permissions as needed. $perm[$user->uid]['use text format editor'] = TRUE; $perm[$user->uid]['show format selection for node'] = TRUE; // Allow access to draggable views. $perm[$user->uid]['access draggableviews'] = TRUE; $perm[$user->uid]['other perm 1'] = TRUE; $perm[$user->uid]['other perm 2...'] = TRUE; } }

I removed the logic to check if a user is leader of the current group, for simplicity, but other than that this is a fully functional snippet that could be used in nearly every Drupal 7 project that uses Organic Groups. Essentially, it checks if page request is in a group context, then check if user is a group leader (or any other role your groups setup could have), and then add the permissions needed for him during that page request.

 Bonus points
  •  With this in place, it’d be very simple to build an UI to configure the extra permissions that need to be added to specific group roles, even on a per-group level. That way, full control over who can do what, can be achieved from the UI as configuration, keeping the code tweaks at a minimum.
  • I removed some extra logic here for simplicity, but our scenario was on a very busy site. We used a session variable to keep track of the groups for which the user is a group leader, to save yet another database query on each page request.
Related links

Although I didn’t find any existing solution to this scenario, I came across a module that does just the opposite: OG Role Override. It allows to specify certain global roles, that will be treated as specific group roles automatically, even if they don’t belong to a given group. Very handy, as I also had that particular scenario in this same project!

Categories: Drupal

OpenLucius: Drupal 8 and Solr: Google-fast search on your own website | Why and how

13 December 2016 - 5:33am

Speed is important in a Drupal website, very important. For visitors as well as search engines, it’s an essential benchmark to success. But how do you keep your Drupal system fast, even when it has millions of pages and documents? Solr is the answer, here is why and how in Drupal 8.

Categories: Drupal

J-P Stacey: Extending Drupal 6-to-8 upgrade to create media entities

13 December 2016 - 5:18am

How can one extend the Drupal 6-to-8 core upgrade functionality? Recently, I've been working with Drupal upgrades using the UI and found the process to be fairly smooth, but missing some key functionality, like media; at the same time, I've been writing a series of blogposts on the Drupal 8 APIs: it turns out that, to extend the process of upgrades to Drupal 8, we can bring these two threads together.

Read more of "Extending Drupal 6-to-8 upgrade to create media entities"

Categories: Drupal