Drupal Planet

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

ADCI Solutions: Top-10 responsive Drupal e-commerce themes

August 2, 2017 - 1:00am

Who cares about shopping offline if one can do it online? Thanks to attractive ready-to-use commerce templates, the process of selling and buying things in the Interner is becoming more smooth and pleasant day by day. For this article we chose ten Drupal e-commerce themes which can be used for different kind of stores. 

Retail, fashion, food store - Drupal can do it all.

 

Read the full article and choose your theme.

 

Categories: Blogs

ActiveLAMP: Migrating Drupal 7 redirects to Drupal 8

August 1, 2017 - 11:00pm

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

Read more...
Categories: Blogs

PreviousNext: Testing sort order with BrowserTestBase

August 1, 2017 - 7:39pm

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

Categories: Blogs

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

August 1, 2017 - 3:10pm
Week 9: Finishing Base Social Auth Implementer And Work on Social Post Implementer himanshu-dixit Tue, 08/01/2017 - 23:40
Categories: Blogs

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

August 1, 2017 - 2: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: Blogs

Web Wash: Getting Started with Webform in Drupal 8

August 1, 2017 - 2: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: Blogs

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

August 1, 2017 - 1: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: Blogs

Mediacurrent: Building Components: Breaking it down

August 1, 2017 - 1: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: Blogs

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

August 1, 2017 - 12: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: Blogs

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

August 1, 2017 - 11:26am
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: Blogs

Nextide Blog: Maestro Overview Video

August 1, 2017 - 10:13am
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: Blogs

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

August 1, 2017 - 10:01am
GSoC’17 Coding period | Week #9 | Drupal chiranjeeb2410 Tue, 08/01/2017 - 09:01
Categories: Blogs

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

August 1, 2017 - 6: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: Blogs

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

August 1, 2017 - 1: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: Blogs

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

July 31, 2017 - 9:00pm

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: Blogs

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

July 31, 2017 - 9:00pm

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: Blogs

OSTraining: What to Expect in Drupal 8.4

July 31, 2017 - 3: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: Blogs

Palantir: ¿Patacones o Tostones?

July 31, 2017 - 3: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: Blogs

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

July 31, 2017 - 3: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: Blogs

Pages