ActiveLAMP: Migrating Drupal 7 redirects to Drupal 8

Planet Drupal - Wed, 2017/08/02 - 4:00am

When migrating from Drupal 7 to Drupal 8, it is important to remember to migrate over the redirects as well.

Read more...
Categories:

PreviousNext: Testing sort order with BrowserTestBase

Planet Drupal - Wed, 2017/08/02 - 12:39am

Just a quick post to share a simple way to assert some markup is ordered correctly using BrowserTestBase

Categories:

Himanshu Dixit | Blog: Week 9: Finishing Base Social Auth Implementer And Work on Social Post Implementer

Planet Drupal - Tue, 2017/08/01 - 8:10pm
Week 9: Finishing Base Social Auth Implementer And Work on Social Post Implementer himanshu-dixit Tue, 08/01/2017 - 23:40
Categories:

Mediacurrent: Designer to Developer: How to Go from Paper to Style Guide

Planet Drupal - Tue, 2017/08/01 - 7:42pm

Ever wonder how websites go from initial design to code? What steps and tools are involved? What are the common pitfalls and how can you avoid them? In this blog post, I will recap the process our designers and front-end developers take to when creating a new website design for our clients. Hopefully, this will give you a little more insight into Mediacurrent’s methodology and in turn help you develop a more robust workflow of your own.
 

Build the Foundation

Before design even begins, there are a few key items to set the project up for success:

Categories:

Web Wash: Getting Started with Webform in Drupal 8

Planet Drupal - Tue, 2017/08/01 - 7:00pm
The Webform module in Drupal 8 makes it easy to create complex forms in no time. The basics are easy to learn but when you start digging below the surface, the huge power of the Webform module starts to reveal itself. While the Contact module in Drupal 8 core does allow you to create simple personal and site-wide contact forms, functionality is limited. This is where Webform module steps in. In the first part of this tutorial, we’ll use some Webform elements to create a simple but fully functioning form. We’ll show what you can do with the results of submissions and then add some additional elements. We’ll also demonstrate how one of the built-in JavaScript libraries can improve the look of form elements. In part two, we’ll add additional pages to our Webform, apply conditional logic, show how to create great layouts and much more!
Categories:

InternetDevels: Dockerize it, or why use Docker in Drupal development

Planet Drupal - Tue, 2017/08/01 - 6:26pm

The smart drop and the clever whale — there is no doubt that Drupal and Docker are highly compatible! It seems like their element is water, however, their true “element” is efficiency. Flexibility, security, and open-source standards are also worth mentioning. So after sharing a collection of useful links for working with Docker, we would like to take a closer look at this great “couple” and see why it’s worth using Docker to boost your Drupal development.

Read more
Categories:

Mediacurrent: Building Components: Breaking it down

Planet Drupal - Tue, 2017/08/01 - 6:25pm

By now it’s no secret that the recommended approach for building websites is using components.  Component-driven development is breaking entire web pages into smaller pieces and working with those pieces individually.  As Stephen Hay puts it in his talk on Responsive Design Workflow, “We’re not designing pages, we’re designing systems of components."

Categories:

Elevated Third: Setting the Stage: Hosting a Decoupled Drupal site

Planet Drupal - Tue, 2017/08/01 - 5:28pm
Setting the Stage: Hosting a Decoupled Drupal site Setting the Stage: Hosting a Decoupled Drupal site root Tue, 08/01/2017 - 09:28

We’ve launched many websites with Acquia, but a recent project for the ski industry is especially notable and worth spending some time with. Over the next month, through a series of posts, we will take a deep dive into decoupled Drupal. With our hosting partner, we will outline how Elevated Third, Hoorooh Digital, and Acquia worked together to create a decoupled site for the Powdr Resorts, one of the largest ski operators in North America.

 

Corey Wood, Technical Account Manager at Acquia, starts us off with...

Part 1: Setting the Stage: Hosting a Decoupled Drupal site.

Powdr Ski Resorts was facing a familiar challenge: the websites in their network of ski resorts were on a collection of disparate content management systems, which made it difficult to govern their digital properties across multiple brands and sites. Powdr needed a digital solution that provides each brand in the Powdr family the flexibility required to deliver customized web experience for their users.

Powdr turned to Elevated Third, Hoorooh Digital, and Acquia to build and design the first in the next generation of sites, a Decoupled Drupal 8 site for Boreal Mountain Resort. Elevated Third spearheaded the decoupled Drupal development; Hoorooh Digital supported the website’s frontend design; Acquia provided the cloud hosting, the technical account manager, and 24/7 global support.

This series will detail how the three teams worked together to bring the project to the finish line.

But first, a refresher.

What is Decoupled Drupal?

A decoupled CMS allows developers to utilize any technology to render the front-end experience (“the glass” where a user interacts with an application) in lieu of the theming and presentation layers that come with a coupled CMS out-of-the-box. In a decoupled Drupal architecture, the Drupal back end exposes content to other front-end systems, such as native mobile applications, conversational UIs, or applications built in JavaScript frameworks.

JavaScript frameworks are increasing in popularity due to the demand for more flexibility in the front end, in addition to the promise of increased productivity and maintainable code. Many JavaScript frameworks exist, but some of the most popular include Ember, React, and Angular.

Drupal can function as a services layer to allow content created in the Drupal CMS to be presented through a JavaScript framework. Drupal’s robust collection of web services and flexible APIs means that any system can consume data from Drupal with ease.

 

Read the entire article, including Corey’s take on hosting a decoupled Drupal project, here.

Categories:

Lullabot: Create SEO Juice From JSON LD Structured Data in Drupal

Planet Drupal - Tue, 2017/08/01 - 4:26pm
TL;DR:
  • Structured data has become an important component of search engine optimization (SEO).
  • Schema.org has become the standard vocabulary for providing machines with an understanding of digital data.
  • Google prefers Schema.org data as JSON LD over the older methods using RDFa and microdata. Also, JSON LD might be a better solution for decoupled sites.
  • Google provides tools to validate structured data to ensure you’re creating the right results.
  • You can use the Schema.org Metatag module to add Schema.org structured data as JSON LD in Drupal and validate it using Google’s tools.
Why does structured data matter to SEO?

Humans can read a web page and understand who the author and publisher are, when it was posted, and what it is about. But machines, like search engine robots, can’t tell any of that automatically or easily. Structured data is a way to provide a summary, or TL;DR (Too long; didn't read), for machines, to ensure they accurately categorize the data that is being represented. Because structured data helps robots do their job, it should be a huge factor in improving SEO.

Google has a Structured Data Testing Tool that can provide a preview of what a page marked up with structured data will look like in search results. These enhanced results can make your page stand out, or at least ensure that the search results accurately represent the page. Pages that have AMP alternatives, as this example does, get extra benefits, but even non-AMP pages with structured data receive enhanced treatment in search results.

undefined Who is Schema.org and why should we care?

Schema.org has become the de-facto standard vocabulary for tagging digital data for machines. It’s used and recognized by Google and most or all of the other search engines.

If you go to the main Schema.org listing page, you’ll see a comprehensive list of all the types of objects that can be described, including articles, videos, recipes, events, people, organizations, and much much more. Schema.org uses an inheritance system for these object types. The basic type of object is a Thing, which is then subdivided into several top-level types of objects:

  • Thing
    • Action
    • CreativeWork
    • Event
    • Intangible
    • Organization
    • Person
    • Place
    • Product

These top-level Things are then further broken down. For example, a CreativeWork can be an Article, Book, Recipe, Review, WebPage, to name just a few options, and an Article can further be identified as a NewsArticle, TechArticle, or SocialMediaPosting.

Each of these object types has its properties, like ‘name,' ‘description,' and ‘image,' and each inherits the properties of its parents, and adds their own additional properties. For instance, a NewsArticle inherits properties from its parents, which are Thing, CreativeWork, and Article. Finally, NewsArticle has some additional properties of its own. So it inherits ‘author’ and ‘description’ from its parents and adds a ‘dateline’ property that its parents don’t have.

undefined

Some properties are simple key/value pairs, like description. Other properties are more complex, such as references to other objects. So a CreativeWork object may have a publisher property, which is a reference to a Person or Organization object.

Further complicating matters, an individual web page might be home multiple, related or unrelated, Schema.org objects. A page might have an article and also a video. There could be other elements on the page that are not part of the article itself, like a breadcrumb, or event information. Structured data can include as many objects as necessary to describe the page.

Because there’s no limit to the number of objects that might be described, there's also a property mainEntityOfPage, which can be used to indicate which of these objects is the primary object on the page.

What are JSON LD, RDFa, and Microdata, where do they go, and which is better?

Once you decide what Schema.org objects and properties you want to use, you have choices about how to represent them on a web page. There are three primary methods: JSON LD, RDFa, and Microdata.

RDFa and Microdata use slightly different methods of accomplishing the same end. They wrap individual items in the page markup with identifying information.

JSON LD takes a different approach. It creates a JSON array with all the Schema.org information and places that in the head of the page. The markup around the actual content of the page is left alone.

Schema.org includes examples of each method. For instance, here’s how the author of an article would be represented in each circumstance:

RDFa <div vocab="http://schema.org/" typeof="Article"> <h2 property="name">How to Tie a Reef Knot</h2> by <span property="author">John Doe</span> The article text. </div> Microdata <div itemscope itemtype="http://schema.org/Article"> <h2 itemprop="name">How to Tie a Reef Knot</h2> by <span itemprop="author">John Doe</span> The article text. </div> JSON LD <script type="application/ld+json"> { "@context": "http://schema.org", "@type": "Article", "author": "John Doe", "name": "How to Tie a Reef Knot". “description”: “The article text”. } </script> Which is better?

There are advantages and disadvantages to each of these. RDFa and Microdata add some complexity to the page markup and are a little less human-readable, but they avoid data duplication and keep the item's properties close to the item.

JSON LD is much more human-readable, but results in data duplication, since values already displayed in the page are repeated in the JSON LD array.

All of these are valid, and none is really “better” than the other. That said, there is some indication that Google may prefer JSON LD. JSON LD is the only method that validates for AMP pages, and Google indicates a preference for it in its guide to structured data.

From the standpoint of Drupal’s theme engine, the JSON LD method would be the easiest to implement, since there’s no need to inject changes into all the individual markup elements of the page. It also might be a better solution for decoupled sites, since you could theoretically use Drupal to create a JSON LD array that is not directly tied to Drupal’s theme engine, then add it to the page using a front-end framework.

What about properties that reference other objects?

As noted above, many properties in structured data are references to other objects. A WebPage has a publisher, which is either an Organization or a Person.

There are several ways to configure those references. You can indicate the author of a CreativeWork either by using a shortcut, the string name or URL of the author, or by embedding a Person or Organization object. That embedded object could include more information about the author than just the name, such as a URL to an image of the person or a web page about them. In the following example, you can see several embedded references: image, author, and publisher.

<script type="application/ld+json">{ "@context": "http://schema.org", "@graph": [ { "@type": "Article", "description": "Example description.", "image": { "@type": "ImageObject", "url": "https://www.example.com/582753085.jpg", "width": "2408", "height": "1600" }, "headline": "Example Title", "author": { "@type": "Person", "name": "Example Person", "sameAs": [ "https://www.example-person.com" ] }, "dateModified": "2017-06-03T21:38:02-0500", "datePublished": "2017-03-03T19:14:50-0600", "publisher": { "@type": "Organization", "name": "Example.com", "url": "https://www.example.com//", "logo": { "@type": "ImageObject", "url": "https://www.example.com/logo.png", "width": "600", "height": "60" } } } ] }</script>

JSON LD provides a third way to reference other objects, called Node Identifiers. An identifier is a globally unique identifier, usually an authoritative or canonical URL. In JSON LD, these identifiers are represented using @id. In the case of the publisher of a web site, you would provide structured data about the publisher that includes the @id property for that Organization. Then instead of repeating the publisher data over and over when referencing that publisher elsewhere, you could just provide the @id property that points back to the publisher record. Using @id, the above JSON LD might look like this instead:

<script type="application/ld+json">{ "@context": "http://schema.org", "@graph": [ { "@type": "Article", "description": "Example description.", "image": { "@type": "ImageObject", "@id": "https://www.example.com/582753085.jpg" }, "headline": "Example Title", "author": { "@type": "Person", "@id": "https://www.example-person.com" }, "dateModified": "2017-06-03T21:38:02-0500", "datePublished": "2017-03-03T19:14:50-0600", "publisher": { "@type": "Organization", "@id": "https://www.example.com//" } } ] }</script> How can we be sure that Google understands our structured data?

Once you’ve gone to the work of marking up your pages with structured data, you’ll want to be sure that Google and other search engines understand it the way you intended. Google has created a handy tool to validate structured markup. You can either paste the URL of a web page or the markup you want to evaluate into the tool. The second option is handy if you’re working on changes that aren't yet public.

Once you paste your code into the tool, Google provides its interpretation of your structured data. You can see each object, what type of object it is, and all its properties.

If you’re linking to a live page rather than just providing a snippet of code, you will also see a ‘Preview’ button you can click to see what your page will look like in search results. The image at the top of this article is an example of that preview.

Schema.org doesn’t require specific properties to be provided for structured data, but Google has some properties that it considers to be “required” or “recommended.” If those are missing, validation will fail.

You can see what Google expects on different types of objects. Click into the links for each type of content to see what properties Google is looking for.

undefined How and where can we add structured data to Drupal?

The next logical question is what modules are available to accomplish the task of rendering structured data on the page in Drupal 8. Especially tricky is doing it in a way that is extensible enough to support that gigantic list of possible objects and properties instead of being limited to a simple subset of common properties.

Because of the complexity of the standards and the flexibility of Drupal’s entity type and field system, there is no one-size-fits-all solution for Drupal that will automatically map Schema.org properties to every kind of Drupal data.

The RDFa module is included in core and seems like a logical first step. Unfortunately, the core solution doesn’t provide everything needed to create content that fully validates. It marks up some common properties on the page but has no way to indicate what type of object a page represents. Is it an Article? Person? Organization? Event? There is no way to flag that. And there is no way to support anything other than a few simple properties without writing code.

There is a Drupal Summer of Code project called RDF UI. It adds a way to link a content type to a Schema.org object type and to link fields to Schema.org properties. Though the module pulls the whole list of possible values from Schema.org, some linkages aren’t possible, for instance, a way to identify the title or creation date as anything other than standard values. I tried it out, but content created using this module didn’t validate for me on Google’s tool. The module is very interesting, and it is a great starting point, but it still creates RDFa rather than JSON LD.

The architecture of the Schema.org Metatag module.

After looking for an existing solution for Drupal 8, I concluded there wasn’t a simple, valid, extensible solution available to create JSON LD, so I created a module to do it, Schema.org Metatag.

Most of the heavy lifting of Schema.org Metatag comes from the Metatag module. The Metatag module manages the mapping and storing of data is managed, allowing you to either input hard-coded values or use tokens to define patterns that describe where the data originates. It also has a robust system of overrides so that you can define global patterns, then override some of them at the entity type level, or at the individual content type level, and or even per individual item, if necessary. There is no reason not to build on that framework, and any sites that care about SEO are probably already using the Metatag module already. I considered it an ideal starting point for the Schema Metatag module.

The Schema.org Metatag module creates Metatag groups for each Schema.org object type and Metatag tags for the Schema.org properties that belong to that object.

The base classes created by the Schema.org Metatag module add a flag to groups and tags that can be used to identify those that belong to Schema.org, so they can be pulled out of the array that would otherwise be rendered as metatags, to be displayed as JSON LD instead.

Some Schema.org properties need more than the simple key/value pairs that Metatag provides, and this module creates a framework for creating complex arrays of values for properties like the Person/Organization relationship. These complex arrays are serialized down into the simple strings that Metatag expects and are unserialized when necessary to render the form elements or create the JSON LD array.

The primary goal was to make it easily and endlessly extensible. The initial module code focuses on the properties that Google notes as “Required” or “Recommended” for some basic object types. Other object types may be added in the future, but could also be added by other modules or in custom code. The module includes an example module as a model of how to add more properties to an existing type, and the existing modules provide examples of how to add other object types.

Also, there is a patch for the Metatag module to refactor it a bit to make it possible for a decoupled Drupal back end to share metatags with a front-end framework. Since this module is built on the Metatag model, hopefully, that change could be exploited to provide JSON LD to a decoupled front end as well.

This approach worked well enough in Drupal 8 that I am in the process of backporting it to Drupal 7 as well.

Enough talk, how do I get JSON LD on the page?

It’s helpful to understand how Schema.org objects and properties are intended to work, which is the reason for going into some detail about that here. It helps to figure out ahead of time what values you expect to see when you get done.

Start by scanning the Schema.org lists and Google’s requirements and recommendations to identify which objects and properties you want to define for the content on your site. If you’re doing this for SEO, spend some time reviewing Google's guide to structured data to see what interests Google. Not all content types are of interest to Google, and Google considers some properties to be essential while ignoring others.

Some likely scenarios are that you will have one or more types of Articles, each with images and relationships to the People that author them or the Organization that publishes them. You might have entity types that represent Events, or Organizations, or People or Places, or Products. Events might have connections to Organizations that sponsor them or People that perform in them. You should be able to create a map of the type of content you have and what kind of Schema.org object each represents.

Then install the Schema.org Metatag module and enable the sub-modules you need for the specific content types on your site. Use this module the same way you would use the Metatag module. If you understand how that works, you should find this relatively easy to do. See the detailed instructions for Metatag 8.x or Metatag 7.x. You can set up global default values using tokens, or override individual values on the node edit form.

In Conclusion

Providing JSON LD structured data on your website pages is bound to be good for SEO. But it takes a while to get comfortable with how structured data works and the somewhat confusing Schema.org standards, let alone Google’s unique set of requirements and recommendations.

No solution will automatically configure everything correctly out of the box, and you can’t avoid the need to know a little about structured data. Nevertheless, this article and the Schema.org Metadata module should enable you to generate valid JSON LD data on a Drupal site.

Categories:

Nextide Blog: Maestro Overview Video

Planet Drupal - Tue, 2017/08/01 - 3:13pm
Maestro Overview Video randy Tue, 08/01/2017 - 09:13

We've put together a Maestro overview video introducing you to Maestro for Drupal 8.  Maestro is a workflow engine that allows you to create and automate a sequence of tasks representing any business process. If it can be flow-charted, then it can be automated. Workflows typically include the movement of documents or forms for editing and review/approval. A number of condition checks (if tasks) can be incorporated through simple admin functions and without any coding.

Categories:

Chiranjeeb Mahanta | Blog: GSoC’17 Coding period | Week #9 | Drupal

Planet Drupal - Tue, 2017/08/01 - 3:01pm
GSoC’17 Coding period | Week #9 | Drupal chiranjeeb2410 Tue, 08/01/2017 - 09:01
Categories:

Vardot: Dr. Serkan Aygin Clinic Website, Turkey’s Top Hair Clinic

Planet Drupal - Tue, 2017/08/01 - 11:55am
Dr. Serkan Aygin Clinic Website, Turkey’s Top Hair Clinic Dmitrii Susloparov Tue, 08/01/2017 - 12:55 Overview

Dr. Serkan Aygin is one of the first hair transplant doctors in Turkey, and has been performing successful hair transplant operations through the Dr. Serkan Aygin Clinic since 2013. As a world renowned hair transplant specialist, Dr. Aygin travels to international conferences and engages with a global audience. The Dr. Serkan Aygin Clinic regularly serves patients from all around the world.

 

The Dr. Serkan Aygin Clinic had an old website, built on a CMS that didn’t satisfy today’s business needs. The website did not support multiple languages, a definite limiting factor to expanding its multinational and multilingual customer base. Also, the site was not responsive, resulting in a negative user experience for the predominantly mobile world today.

 

Vardot was approached by the Dr. Serkan Aygin Clinic to develop a new website with the mandate to increase sales and business growth. The Dr. Serkan Aygin Clinic signed up specifically with Vardot, a company headquartered in Jordan with offices in Jordan, USA, and Egypt, because of its expertise in developing multilingual websites (including Arabic language). The inclusion of Arabic in its website enables the Dr. Serkan Aygin Clinic to market more effectively to the Gulf region.

 

Vardot successfully built a multilingual website for the Dr. Serkan Aygin Clinic using Varbase, a custom optimized distribution based on Drupal 8 CMS. As part of the overall solution, Vardot also translated the web contents to Arabic. In addition to multilingual support, the new website features significant SEO enhancements which improve its visibility to search engines.

Why Drupal was chosen

Drupal is an industry-leading website development platform renowned for its support of multilingual websites. The new Dr. Serkan Aygin Clinic website currently supports 3 languages (English, Arabic, and Turkish). Over time, 6 more languages will be added.

 

Another advantage of using Drupal in this project is the ability to easily build unique landing pages for different marketing campaigns. This is critical for Dr. Serkan Aygin Clinic in order to satisfy the mandate to increase sales and expand its business.

 

Last but not least, customization is a competitive advantage to the Dr. Serkan Aygin Clinic to stay as the top hair transplant clinic in the region. Drupal, by design, is a modular framework. As a result, a Drupal-based website can be customized to fully satisfy unique business requirements, both now and in the future.

Describe the project (goals, requirements and outcome)
  • Design, UI and UX
    The user interface for the Dr. Serkan Aygin Clinic website was redesigned from scratch. The new interface was planned, first and foremost, with user experience in mind. A modern reality is that mobile web users outnumber their desktop counterparts. To maximize user experience, a mobile-first approach was adopted in the implementation of the Clinic website. This approach constituted a clean break from the antiquated model of first creating the desktop UI and later somehow fitting the interface on mobile devices.

 

  • The CMS foundation
    The new website was developed using Varbase, a Vardot base distribution built on top of the Drupal 8 CMS framework. Varbase provided out-of-the-box mobile-ready functionalities in standard-compliant modules. This made customization easy, resulting in the quicker development of the Dr. Serkan Aygin Clinic website.

 

  • Multilingual site
    The new Dr. Serkan Aygin Clinic website supports 3 languages (English, Arabic, and Turkish) with plans to add 6 more. Without software support, creating and maintaining the website with potentially 9 languages would have greatly strained developer and editor resources. The Drupal 8 framework coupled with Varbase customization laid a solid foundation of multilingual support, for both now and later. The Varbase pre-built configuration options enabled editors to easily translate the Clinic website into multiple languages.

 

  • SEO
    The Dr. Serkan Aygin Clinic website was redesigned and implemented altogether on a different CMS. From the search engine perspective, this was a migration project from one set of URLs to another. The SEO risk in the migration project was that organic traffic, painstakingly built up by the previous website, might be lost for the new one due to obsolete URLs or a drop in search ranking. To mitigate the risk, upon migration of the website, all URLs from the legacy site were imported, and redirects were set up in the Drupal CMS. In addition, descriptive meta tags were used to facilitate indexing by search engines such as Google, Yandex, and Bing. Language-aware XML sitemaps comprised another SEO tool to prop up webpage visibility. Furthermore, optimized markups were implemented to comply with the web accessibility standard WCAG 2.0 level AA. As a result of using meta tags, markups, XML sitemaps, and other tools, search ranking for the Dr. Serkan Aygin Clinic website was optimized for the migration.
     

  • The outcome
    In February of 2017, Vardot completed and delivered the multilingual SEO-friendly website for the Dr. Serkan Aygin Clinic on Varbase, an optimized Drupal 8 distribution. The newly minted website fully supports English, Arabic, and Turkish. The resounding success of the new website was measured quantitatively using objective verifiable web metrics. The new website experienced an 800% increase in organic traffic after the launch. Data analysis further showed that site visitors stayed longer and were more engaged in the new website than the old one. More specifically, the bounce rate dropped from 70% to 26%, and the pages viewed per session increased over 200% from 1.2 to 3.7. Overall, the relaunching of the Dr. Serkan Aygin Clinic website drove the mandated business growth via an engaging multilingual web presence.

Categories:

Agiledrop.com Blog: AGILEDROP: Our Drupal Blogs from July

Planet Drupal - Tue, 2017/08/01 - 6:34am
We've never been that fast. It's the first day of the new month and we are already giving you the overview of our blog activities in the past month. There has been plenty of action, so let us not waste any more time and take a look at our Drupal Blogs from July. We have started the month with the Most popular Drupal modules. It was a topic that we wanted to cover a long time ago, but it somehow always slipped away. Nevertheless, we have explored, which ones are the most downloaded ones and which ones are used by the most sites. The list includes Views, Token ... Since it is summer time,… READ MORE
Categories:

Chen Hui Jing: Drupal 101: Theming Drupal 8 with gulp

Planet Drupal - Tue, 2017/08/01 - 2:00am

Around two years ago, I wrote a post called Drupal 101: Theming Drupal 7 with gulp, which covered some basics about Sass and gulp. I’m not going to repeat myself, so if you can read that article if you’re interested. This one is going to cover the delta for the gulpfile.js setup in Drupal 8.

gulp-ify your Drupal theme

If you’re just starting out with Drupal 8 theming, you can read my previous post on exactly that right here. I’m going to cover the gulp tasks that are relevant to my way of working, which is a whole lot less than what most other people do with gulp.

I only use gulp to compile Sass, handle ES6...

Categories:

Chen Hui Jing: Drupal 101: Getting started with Drupal 8 theming

Planet Drupal - Tue, 2017/08/01 - 2:00am

Yes, I’ve finally got around to digging my mitts into Drupal 8, and building custom themes for Drupal 8. I have this bare-bones starter theme called Clarus that I developed back in the day when I was theming Drupal 7 sites willy-nilly. I thought I’d keep it, and develop a Drupal 8 branch rather than start a new project.

Drupal 8 has undergone quite a significant revamp under-the-hood, and the folder structure has changed quite a bit. Instead of placing your themes in the sites/all/themes folder, all user-created themes go into the themes folder. Well, that’s an upgrade on the intuitive-ness front.

The documentation for theming Drupal 8 is really good, and you should read that before anything...

Categories:

OSTraining: What to Expect in Drupal 8.4

Planet Drupal - Mon, 2017/07/31 - 8:48pm

Every six months, the Drupal team get to release new features.

This is a major change in Drupal 8. Whereas Drupal 7 never had any new features, Drupal 8 has had three significant updates, with Drupal 8.1Drupal 8.2 and Drupal 8.3.

We're now starting to get a clear view of what we can expect in Drupal 8.4.

This week, we'll get the the first Alpha version of 8.4. The final release is due on October 4.

So what new features will we see in 8.4? Here's our early overview of what might be included:

Categories:

Palantir: ¿Patacones o Tostones?

Planet Drupal - Mon, 2017/07/31 - 8:45pm
¿Patacones o Tostones? brandt Mon, 07/31/2017 - 13:45 Annie Schow and Michelle Jackson Jul 31, 2017

How Spanish-speaking site visitors navigate a site may vary significantly based on dialect, culture, and the region they are from. 

In this post we will cover...
  • Palantiri recommendations on integrating language and culture into the website redesign process

  • A Palantiri native Spanish speaker’s experience navigating her native tongue stateside and overseas

We want to make your project a success.

Let's Chat.

Do all Spanish-speaking countries and regions have the same words and terms? Does everyone agree on these terms across the board, or are there barriers? Business Development Representative Annie Schow shares her experience on navigating the diverse landscape of the Spanish language and Web Strategist Michelle Jackson provides some tips on how to better understand the language and culture of the audiences you are targeting.

Annie in Colombia as a young, biz-dev-rep in training.

Growing up in Colombia, my first language was Spanish. Eventually, my family made the move back to the United States, but while in Bogota I attended an American school and had American parents, so the move to an English-speaking country when I was 10 was not a huge transition. The biggest transition I experienced was getting accustomed to what seemed like a completely new Spanish language that was being spoken in Texas. Camioneta was now troca, torta was now pastel, and patacones were now tostones.

It may not seem like a huge adjustment to learn some of these terms, but what happens when you take the examples of trucks, cakes, and fried plantains and put these changes into the context of web design? How Spanish-speaking site visitors navigate a site may vary significantly based on dialect, culture, and the region they are from. Some words may even have a negative connotation. Mexican Spanish may not make the most sense for a site that is targeting multilingual audiences from different regions in Latin America. 

So what does this mean for your next project that focuses on a Spanish-speaking demographic as one of your audiences?

Michelle's recommendations: When in Roma …

Is the homepage portada (Chile) or inicio (Panama)? Will the navigation item for news say prensa (Spain) or noticias (Miami)? The answer depends on whom you are speaking with, where your client is based, and which audiences they serve. If the team is going to provide strategy or design expertise in Spanish or any language, use authentic idioms and terms consistent with the culture to build trust with clients.

  1. Review and take cues from the actual Spanish language site (if there already is one).
  2. If your client has members of the team that speak the language, take advantage of their expertise and seek advice on which terms to use in the navigation.
  3. Review websites in the region that target the same demographic. These can be competitor sites or other sites that people visiting your site might use in parallel markets. This will give you a sense of the actual lingo and what terms visitors may expect on your site.
  4. Run user tests on the menu and the actual site once it is built. Test with real visitors to see if the terms you and the client have selected make sense to the people who will be visiting the site.
Know your audience and avoid sweeping generalizations 

User experience practitioners sometimes make the mistake of creating a generic Spanish speaking persona. Building any site based on one individual and the language he or she speaks to guide the content strategy, design, and build of the site is risky. If one is building a Spanish language site or a site in another language, having multiple personas is best. Knowing the basics of the demographic the site are reaching out to is essential. This knowledge will ensure the site integrates cultural context into the content strategy, design, and technical build of the site. Here are some questions to better understand your audience:

  1. Who are the users (i.e. exchange students, U.S. citizens, etc.,.)?
  2. How old are they?
  3. Where were they born?
  4. What is their education level?
  5. Are they helping their parents or peers?
  6. Can they read English and Spanish?
  7. Can their parents read English and Spanish?
  8. Do their parents speak Spanish or a local dialect?
  9. If they can’t read Spanish, can they understand Spanish?
  10. Do they primarily access the web on their mobile phone or desktop?

This type of nuanced information not only plays a key role in shaping the direction of the project, but also leads to the development of accessible content that can lead to increased visitor engagement with the site. For example, leveraging video might be a solution for visitors with low literacy or for visitors who are reluctant to read a lot of text.

Lost in translation

Write the primary content in Spanish with the audience in mind. Avoid translating the English site word for word. Rather than using Google translate to engage visitors who speak another language, interpret the website goals and content and reflect these to the audiences you are targeting through the site design, content, and technical architecture. Design and build the site so it is authentic and frame content messaging in a way that speaks to them.

Consistency across sites

What do users get out of going to your website? Focus on the universal goals for the site and core user needs before focusing on language. Once you have a sense of what visitors want the most (i.e. apply for a Master’s degree program), you can prioritize supporting content (i.e. getting a visa). Avoid creating separate navigations for versions of the site that are merely the same iteration in another language. Many visitors are multilingual and may toggle between English and Spanish pages. They may get frustrated if the navigation or key content is missing from one site or located in a different places on another.

The Takeaway

Whether you’re moving to a new country or building a website, language and culture will vary. The best thing you can do is listen and learn. Patacones or tostones? You’ll never really know until you submerge yourself in the culture!

There is existing research around cultural and language needs, but words and idioms constantly evolve. Cultural norms are fluid. The only way to validate Spanish terms that you decide to use in the navigation and for key website content is to speak with real site visitors and to test the content and words with them.

 

Are you attending Drupal Camp Costa Rica? Don't miss out on sessions by Palantir CEOs Tiffany Farriss and George DeMet (neither of whom are Spanish speakers).

Queremos asegurar el éxito de su proyecto.

Hable con nosotros.
Categories:

Acquia Developer Center Blog: A Deep Dive into a Decoupled Drupal Project

Planet Drupal - Mon, 2017/07/31 - 8:41pm

How Elevated Third, Hoorooh, and Acquia worked together to create a decoupled site for the Powdr Resorts, one of the largest ski operators in North America

Tags: acquia drupal planet
Categories:

Lullabot: Three Things Every Drupal Site Needs to Kick Ass

Planet Drupal - Mon, 2017/07/31 - 7:06pm

You’ve built a beautiful Drupal site, but will it stand the test of time? If it’s slow, hacked, or unmaintainable, it may not be the success that you hoped for.

One of the services we offer our clients is a Lullabot Best Practices Audit. As a part of that audit, we look closely at three areas of your site: Security, Performance, and Stability. In this article, I will discuss some of the questions we ask and the tools we use to grade how well your site performs.

You’re no doubt already aware of these three areas. The reason they become a focus in our audit is that they are often the neglected parts of our sites. It's easy to get in a pattern of prioritizing cosmetics, features, and bug fixes without realizing how all of those affect the foundation the site is built on. When that happens, you risk losing customers, damaging your reputation, leaking sensitive information, or perpetuating broken processes, all of which—whether you like to admit it or not—ultimately cost money.

Security

Security is not a deliverable, it's a discipline. That means that having a secure website is not something we ever complete, but is an ongoing process to adhere to and improve. The costs of ignoring that process can be severe.

The security of your site and infrastructure is only as good as your security process. Here are a few questions we might ask about your Drupal security process as a portion of the audit:

  1. Is your security process well documented and followed?
  2. Who is monitoring Drupal Security Advisories and announcements? How?
  3. How often are security updates applied?
  4. What is the process in place for Zero-day vulnerabilities?
  5. How regular are security audits performed? 1. Are you using any automated tools to scan new work for common security vulnerabilities?
  6. Is HTTPS in use? Everywhere?

If you don't have good answers to those questions, it could mean your site and infrastructure are vulnerable to attack. In fact, it might have already been compromised without your knowledge.

Helpful tools to consider

There are some helpful tools out there to aid in performing your own audit of the security of your Drupal site.

  1. Security Review Module provides a status page on your Drupal site and Drush command to check for common security vulnerabilities such as file system permissions, XSS vulnerabilities, protection against arbitrary code execution, etc.  
  2. Hacked Module performs an audit of all core and contributed code to see if there have been modifications. 
  3. Coder Module does some basic checks to ensure that text is properly sanitized In addition to checking that coding standards are being followed.
  4. Qualys SSL Server Test is a free service that will perform a thorough analysis of a public SSL certificate and provide you with a graded result.

Some of these tools come with command line versions. By combining those with a continuous integration tool, you could set up regular and ongoing security testing of your code and configuration.

Performance

We all want fast sites. Among other things, a fast site means happier users and higher search engine rankings. If your site makes you or your organization money, having a slow site means higher page abandonment, and ultimately lost revenue.

None of us have slow sites on purpose. Performance issues can arise gradually over time without an obvious reason for how and when they began. Spending time or money to investigate and fix performance issues can be deemed less important than more desirable or “measurable” initiatives.

Here are a few questions we might ask as a part of an audit:

  1. Are frontend and backend performance being monitored? With what?
  2. What sort of caching layers are in place?
  3. Do you have analytics that show traffic patterns, such as country of origin, graphs of throughput over time, and the like?
  4. Have you had any recent site outages that you suspect are performance issues?
  5. Are you aware of slow pages or interactions on the site?
  6. Have users complained about any slowness?
  7. Are there any libraries or methods used to increase frontend performance?
  8. What sort of image optimizations are being done?
  9. Are there ways that you optimize performance for different screen sizes (mobile/tablet/desktop)?
Helpful tools to consider

There are some helpful tools out there to aid in performing your own audit of performance.

  1. XHProf or the Tideways PHP Profiler: PHP profiling tools that can help you identify bottlenecks on specific pages. XHProf works with PHP 5.6 and below, whereas the Tideways PHP profiler is compatible with PHP 7 and below, and can act as an XHProf replacement. There is an associated Drupal module that I recommend (along with this patch if you have a lot of AJAX interactions), or you can use either with xhguiTip: look at exclusive wall time to find the functions that are the slowest on a page.
  2. New Relic or similar: We love New Relic for being able to monitor traffic and performance in real time, create alerts for specific events, and dive deep into function traces to isolate bottlenecks. In addition, it gives you the ability to create customized dashboards to display pretty charts and graphs from performance data on your site. New Relic can monitor browser, application, server performance, and more. There are New Relic alternatives that likely offer similar features. Choose a tool and use it.
  3. Google's PageSpeed InsightsYSlow, or similar: Tools that give you practical advice on how to improve the front-end performance for your users. It may suggest reducing the number of requests by using image sprites or combining JavaScript files, or it might recommend simplifying the DOM to reduce the number of elements the browser needs to parse. It goes through a whole set of tests and gives you practical suggestions that can sometimes lead to easy performance gains.
Stability

When we investigate the stability of your site, we look at the architecture of the site, the breadth, and depth of developer documentation, the quality of the site's code, and the process by which that code gets written and deployed to production. When best practices aren't followed in these areas, it can result in a platform with a slow development cycle, fragile releases that require everyone to be present in case anything goes wrong, and vendor lock-in, forcing you to work with only developers that understand the unique complexities of your site. Even if nothing brings the site down during a release, that is a very expensive process, and optimizing it can save your organization time, money, and heartache.

Here are a few questions we might ask as a part of an audit:

  1. What documentation exists on the site architecture, development process, and deployment process? How well is it maintained? Who has access to it? 
  2. Does the development team have agreed upon coding standards?
  3. Do the developers peer review each other's code?
  4. Is there automated testing or human testing as a part of the development and deployment process? Does that testing happen before or after the code is merged in?
  5. How much of the release process is scripted or automated?
  6. How many people are typically present for a release?
  7. Does the site go down often? If so, are root cause analysis (RCA) documents provided by the development or infrastructure team?
  8. Does your team have a well-documented rollback procedure?
  9. How does your team deal with technical debt?
Helpful tools to consider 

Here are some tools we use that help us sleep at night.

  1. Linting tools can get all of your developers in agreement on code formatting, which helps tremendously in the peer review process, and ultimately in the stability of your site. EditorConfig is a nice emerging format that can be used to enforce agreed upon standards in your developer’s actual text editors or IDEs. In addition, Drupal Code Sniffer (which is a part of Coder module) can be used in those same text editors to ensure that Drupal code is following Drupal coding standards. While having your developers use these linting tools in their editors is fantastic, ideally they should also be a part of an automated test that runs on every pull request.
  2. Automated Testing using PHPUnit, Behat, Nightwatch, or other mixture of functional and unit testing tools can improve the stability of the platform immensely. While the initial investment may seem costly at first, the money saved over time is significant, and the peace of mind is priceless.
  3. Tugboat or another continuous integration tool can build complete working websites for new features or bug fixes before they get merged. That means your QA team or stakeholders can sign off on things before they ever make it into your codebase. In addition, it can run the linting and automated tests you implemented above and report the results back to the developer before that code gets reviewed or merged. Saved time is saved money.
Your website's success

Security, performance, and stability are the unsung heroes of your website's success. When they are neglected, it can cost dearly. Whether it's a damaged reputation, customers lost, services hacked, or just plain stress from the platform, these all ultimately mean lost revenue. Take some time to invest in your website's success by performing a Best Practices audit on your site.

Next steps

The above is a sample of some of the things we might investigate as a part of a Best Practices audit, but your website and needs are unique. We hope this article serves as either a blueprint to design your own audit, or the start of a conversation to get some help where you need it. We collaborate with you on our Best Practices audits to best fit your project’s needs.

If you're thinking of performing your own Best Practices Audit, let us know in the comments below. If you'd like some help from Lullabot, reach out—we'd love to partner with you in writing your website's success story.

Categories: