Skip to Content

Drupal

btmash.com: Saving and retrieving taxonomy terms programmatically for Drupal 8

Planet Drupal - 26 April 2016 - 9:52pm

Over the past month, I've been attempting to learn more about Drupal 8 by attempting to port the @font-your-face module which has a lot of different pieces; it touches on Content Entities, Config Entities, regular entities, views, classes, hooks, and more! I'll try and blog on my experiences with that in the near future but an interesting problem that I ran into is that I am using taxonomy terms to categorize Font Classifications, supported languages/subsets, and generic tags.

planet drupal
Categories: Drupal

PreviousNext: Using typey: a framework for working with typography on the web

Planet Drupal - 26 April 2016 - 7:00pm

typey has just turned 1.0, so I thought it would be a great time to show off some of its features.

Categories: Drupal

xjm: Join the Drupal 8 major triage at DrupalCon New Orleans

Planet Drupal - 26 April 2016 - 3:57pm
Join the Drupal 8 major triage at DrupalCon New Orleans Body

On April 20, five months after the launch of Drupal 8.0.0, we released Drupal 8.1.0, the first scheduled minor update. Drupal 8.1.0 comes with both new features and bug fixes that were not eligible for monthly patch releases. Now is a great time to try Drupal 8 if you haven't yet!

Drupal 8.1.0 is production-ready, but (like most software) still has known bugs that can cause issues for some modules or sites. Although we fixed hundreds of critical bugs during Drupal 8's development, and although only a handful of critical issues have been discovered since Drupal 8.0.0, there are still hundreds of less severe bug reports marked with "major" priority


Major issue triage sprint at DrupalCon Asia 2016. Photo credit: Amazee Labs.

500 major bugs

500 major bugs sounds like a lot, right? Many of these bug reports are still relevant and important to fix for Drupal 8 to be more robust. However, many other reports are outdated; they might already have been resolved, they might no longer be relevant, or they might be misfiled. As many Drupal contributors know, it can be hard to find the right issues.

Find the issues that matter

Finding (and fixing) the bugs that are most important is a group effort. We use a two-phase process:

  1. Contributors verify the current status of the major issues, make sure they are up to date, and close issues that are no longer relevant.
  2. Core committers and subsystem maintainers collaborate to assess the verified issues.

We call this process "issue triage". And phase 1 is where you come in! Help us sort through these major bug reports at DrupalCon New Orleans. This flowchart illustrates the workflow we will use at the major issue triage sprint:

(You can also read the detailed instructions in the major triage meta issue.)

Once the current state of these bug reports is verified, Drupal 8 core committers and subsystem maintainers will prioritize them, deciding which are indeed major, which are just normal bugs, and even which ones are critical issues in disguise.

Reasons to come to the major triage sprint
  1. Help squash bugs faster, so that Drupal 8 is even better for your next Drupal site.
  2. Become more familiar with Drupal 8 (and the kinds of bugs that still need fixing).
  3. Improve your git skills and learn git techniques that will help you in your own projects.
  4. Learn about how issues get solved in Drupal core and how to contribute effectively.
  5. Get to know a particular subsystem of Drupal 8 in more depth.
  6. Get credit on your Drupal.org profile when the issues you verify are eventually fixed.
  7. Collaborate with the amazing maintainers who've brought you Drupal 8.0.0, Drupal 8.1.0, and each bugfix release.
Sign me up!

Sounds awesome, right? You can sign up on the DrupalCon New Orleans sprint sheet under "Bugs-- // Drupal 8 criticals and majors". Longtime core mentors cilefen and valthebald will be helping lead the major triage. (New to Drupal contribution? Join the First-Time Sprinter Workshop.)

 

xjm Tue, 04/26/2016 - 22:57
Categories: Drupal

Evolving Web: Improving Drupal Speed with blackfire.io (Part 1)

Planet Drupal - 26 April 2016 - 2:21pm

Drupal core is pretty well optimized. But after you've finished building your Drupal 7 or 8 site, you might find some pages are loading slower than you'd like. That's not surprising—you've probably enabled scores of contrib modules, written custom code, and are running over 100 SQL queries per uncached request.

read more
Categories: Drupal

Aten Design Group: 404 Not Found: The Monster Under Your Bed

Planet Drupal - 26 April 2016 - 1:51pm

If you are working on a website redesign, 404s are the very real monsters under your bed. Ignore them, and they will wreak havoc on your website’s traffic. Worst of all, by the time you realize what’s happening it may already be too late.

What are 404s?

Very simply, 404s are broken links. More specifically, 404 is the HTTP response code for “Not Found,” signifying that a web page is not available at the provided URL. Reorganizing old content, changing old URLs and selectively discarding content that is no longer relevant are all common activities during website redesign projects that can result in 404s.

Why 404s Are so Bad

Your legacy content – the stuff that’s been around for 15 years, from the most up-to-date research articles, to blog posts written by employees long-gone, to PDF files in random folders off your webroot – has been quietly growing your website traffic, catching inbound links and increasing effectiveness of organic search. And the longer it has been around, the more valuable it has likely become, even if the content itself is no longer of much relevance to your organization. A quick scan of your Google Analytics will likely confirm this. Your organic search traffic probably has a very long tail: thousands or tens of thousands of pages with a few hits each, funneling users to your website.

If those URLs change, or that content is abandoned entirely, the potentially massive net you have been casting – and growing – for years will be damaged. Despite the very best user experience, the most on-target messaging and the most compelling design, years of search engine optimization (SEO) progress can be lost – all because of 404s. Your organic search rank will drop as search engines remove the now-broken URLs from their indexes. As a result, traffic will plummet. All of this can very quickly bring the success of your entire redesign project into question.

In website redesigns, 404s may very well be your worst enemy.

Combatting 404s Starts with Content Strategy

Dealing with 404s is an important, often overlooked component of effective content strategy. Communications teams frequently devote significant time to performing content audits, flagging content to be be reorganized, rewritten or abandoned altogether. Far less time – if any – is given to thinking through exactly what to do with content that is left behind. It is simply abandoned. Soon after launch, someone in marketing notices a drop in traffic and suddenly 404s are on everyone’s radar.

By Default, Keep Everything

When redesigning a website, we recommend keeping just about everything. That might be opposite of what you’ve heard before. It doesn’t lend itself to the “cleaning out the garage” or “moving to a new house” metaphors. In reality, though, your legacy content is one of your greatest assets. That junk in the garage is gold. Deal with it, but don’t abandon it.

For outdated content, channel users to more relevant offerings with good user experience design and carefully crafted messaging. Old content – even if outdated – represents an opportunity to connect with users you otherwise might miss entirely, communicating key changes in your organization or pointing to relevant, up-to-date resources. Again, dealing with legacy content is an important element of content strategy. It deserves design attention and good user experience. Craft a simple message that says “This resource is out of date. To see our more recent work in this area, see X, Y or Z.”

For content that is rewritten or moved to a new URL, use 301 redirects to redirect users automatically from old pages to their new equivalents. 301 redirects, or 301s, signal to search engines that a resource has not been eliminated; rather, it has been “Moved Permanently” and should be reindexed at its new location. 301s are hands-down the most important technical device for dealing with 404s.

(Note that 301s do not guarantee that your content will maintain its rank within search results. Rather, 301s indicate to search engines that the resource for a particular URL has been moved. Search engines will queue the new URL for reindexing, and search rank will once again be determined by a broad spectrum of factors like keyword density, page title, inbound links, etc.)

Add 301 Redirects for All Migrated Content

When migrating legacy content into your redesigned website, add a 301 redirect for every single resource, article or page being migrated. As of right now in Drupal 7, a patch for the redirect module makes this process easy: simply map the old URL to the special destination field “migrate_redirects” and the redirect module will take care of the rest.

In Drupal 8, the redirect module provides built-in support for migrating redirects from older versions of the Content Management System. A little bit of custom code in your scripted migration can take care of adding redirects for migrated nodes. (Need more info? Let us know in the comments or get in touch.)

Find and Prioritize All Legacy URLs

While adding 301 redirects for every migrated page is critical, it is not enough. Google has likely indexed large numbers of URLs for content that will not be included in your scripted migration process. Landing pages, listing pages, PDFs and anything you have specifically decided not to migrate will be omitted if your focus is solely on individual articles. To better understand the full scope of URLs that need to be dealt with, download a report of all pages from Google Analytics or whatever analytics platform you are using. This not only provides a thorough catalog of web pages, PDFs and other resources being viewed, but also shows a count of monthly page views and is incredibly helpful for establishing priority for specific pages to be redirected. Remember, your traffic has a long tail; the potentially thousands of pages that receive one or two views per month are still important.

Test All Legacy URLs In Your Redesigned Website

Once you have a list of all legacy URLs you need to test your new, redesigned website to see which URLs are resulting in “404 Not Found” errors. We have a few custom scripts that do exactly that, written in environments ranging from Drupal modules to standalone NodeJS apps. Regardless of the specific implementation, the script needs to do the following:

  1. Import a list of legacy URLs downloaded from your analytics service.
  2. Loop through the list of URLs and test each on the new website to see what HTTP status code is returned.
  3. If a 301, 302 or other redirect is returned, follow it to ensure it eventually results in a URL with an acceptable status (200 OK).
  4. Generate a report of returned status codes. We typically include page views from the originally downloaded analytics report in this CSV so we can see the status code directly beside the number of monthly views for each URL. Seeing the HTTP status code, URL and number of pageviews all side-by-side in spreadsheet format is incredibly helpful for gauging priority.

The first time you run your script, you will likely see a very high volume of 404s. That’s fantastic: you’re seeing them now, during the redesign, before they are anywhere close to impacting SEO or traffic.

Fix the 404s

Your report of returned status codes provides a prioritized list of 404s that need to be dealt with. You will likely see a mix of landing pages, listing pages, articles, PDF files and other resources. Each URL needs to be dealt with.

Often, large numbers of similar URLs can be redirected programmatically – that is, by matching patterns rather than specific addresses. For example, a collection of folders containing PDFs may have been moved to new locations. Or URLs for pages that show content by category may need to be mapped to new category ids. Depending on the complexity of the specific redirect pattern and the environment in which your website is hosted, programmatic redirects can be added to Drupal in a variety of ways, as follows:

Remaining URLs will simply need a single, manual redirect added. The redirect and path redirect import modules are excellent resources for manually adding 301s.

Watch Out for Index.html

If your legacy URLs are directory indexes (i.e. ending with “index.html” or “index.htm”) you will need to add an additional redirect for the version that does not include the file name.

Example: if your legacy URL is “http://example.com/path/to/file/index.html” and the new equivalent is “http://example.com/new/path/to/file”, you will need two redirects:

  • One from “http://example.com/path/to/file/index.html” to the new URL
  • Another form “http://example.com/path/to/file” (without index.html) to the new URL

We typically add additional redirects for directory indexes once all other redirect work is finished, using a simple custom script that scans the redirects table for index pages and generates the appropriate equivalent.

Test Again, Rinse and Repeat

Once all 404s have been dealt with in the ways outlined above, test your redesigned website again. You will likely find a few URLs that still need to be addressed. Rinse and repeat until the entire list of prioritized pages returns the acceptable status code of 200.

Not Quite Done

And that’s it. Almost. The final piece to combatting 404s is to monitor them closely after launch. The redirect module provides a simple admin page for doing exactly that. We strongly recommend monitoring 404s for several days after launch and adding 301s wherever appropriate.

Sit Back and Relax

Website redesign projects usually impact organizations at all levels, and we know you probably won’t be able to truly sit back and relax after launch. There will be final communications details, stakeholder reviews, content updates, ongoing bug fixes and likely a growing list of next-phase wishlist items. That said, dealing with 404s will help protect your investment in organic search and mitigate deleterious effects on web site traffic. There will still be a dip in the numbers as Google and other search engines update their indexes and re-crawl new content. This post doesn’t address SEO strategy in-depth, nor setting specific traffic goals and benchmarks as a part of planning and discovery for your website redesign. It does express the very clear need to accommodate modified URLs and abandoned pages. Without an effective redirect strategy, 404s will almost certainly wreak havoc on your organic search traffic. Good content strategy and 301 redirects are critical allies for fighting 404s and protecting your years-long investment in SEO.

Categories: Drupal

DrupalCon News: Come celebrate community in the exhibit hall

Planet Drupal - 26 April 2016 - 12:15pm

This DrupalCon we're cranking up the community exposure in the exhibit hall.

Categories: Drupal

OSTraining: How to Change the jQuery Version in Drupal 7

Planet Drupal - 26 April 2016 - 10:24am

One of our OSTraining members asked about changing JQuery, so we created this tutorial for him.

Below is quick guide to installing Drupal's Jquery plugin module.

Categories: Drupal

Acquia Developer Center Blog: Drupal 8 Module of the Week: Responsive and off-canvas menu

Planet Drupal - 26 April 2016 - 10:03am

Each day, more Drupal 7 modules are being migrated over to Drupal 8 and new ones are being created for the Drupal community’s latest major release. In this series, the Acquia Developer Center is profiling some of the most most prominent, useful modules, projects, and tools available for Drupal 8. This week an interesting mobile-usability helper: Responsive and off-canvas menu.

Tags: acquia drupal planetMotWdrupal 8D8UXmobilemenu
Categories: Drupal

Administration menu - Content languages

New Drupal Modules - 26 April 2016 - 8:42am

Provides a dropdown menu with available languages when adding content for all content types that default to the current language in the Administration menu.

This can be useful when the "Set current language as default for new content." multilingual setting is checked for a content type.

Requires the following modules:

Categories: Drupal

Acquia Developer Center Blog: 3 Media Challenges in Drupal, and How to Use the Media Module to Vanquish Them

Planet Drupal - 26 April 2016 - 7:07am

Drupal 7 out the box offers a good implementation for uploading media, but it has three significant challenges.

Challenge 1: Files should be entities

In Drupal, files should be entities so you can add additional fields to the file type. As an example, when you upload an image you will want your standard image alt attribute, which specifies alternate text for an image, if the image cannot be displayed, or the user is using a screen reader. But you may want to have additional fields, such as photo credit or image caption.

Tags: acquia drupal planet
Categories: Drupal

Drupalize.Me: Custom Drupal-to-Drupal Migrations with Migrate Tools

Planet Drupal - 26 April 2016 - 6:15am

Drupal 8.1 now provides a user interface (UI) for conducting a Drupal-to-Drupal migration. Since there is no direct upgrade path for Drupal 6 or 7 to 8, you should become familiar with the migrate system in Drupal, as it will allow you to migrate your content from previous versions to Drupal 8.

Categories: Drupal

Unimity Solutions Drupal Blog: How Drupal helped in launching an Enterprise Class Application

Planet Drupal - 25 April 2016 - 11:46pm

Here is a case study of how Drupal helped in implementing a customer portal for a major utility service provider in the US.

Categories: Drupal

Drupal governance announcements: Coding standards proposals for final discussion on 4/29

Planet Drupal - 25 April 2016 - 7:33pm

The TWG coding standards committee is announcing two coding standards changes for final discussion. These appear to have reached a point close enough to consensus for final completion. The new process for proposing and ratifying changes is documented on the coding standards project page.

The four new issues being proposed are:

Issues still open for comment:

These proposals will be re-evaluated during the next coding standards meeting currently scheduled for April 29th. This is a shorter window and a longer list than the committee generally provides and these issues will likely not be finalized until the following meeting (date TBD due to DrupalCon). The normal timeline was shifted by the arrival of committee member's babies, everyone's happy and healthy but timelines went whacky. At that point the discussion will likely be extended, or if clear consensus has been reached the policy may be dismissed or ratified and moved to the ‘update documentation’ step.

Categories: Drupal

groups.drupal.org frontpage posts: Google Summer of Code 2016 - Selected Projects

Planet Drupal - 25 April 2016 - 1:12pm

Did you know Drupal was accepted into Google Summer of Code 2016 and that 11 Drupal projects were accepted? In other words, Google is funding 11 people to contribute to Drupal for 10 weeks worth a total of $60,500 USD (thank you Google!). Congratulations to selected students who are collectively credited on more than 100 issues fixed in the past 3 months on drupal.org. Coding starts May 23rd and ends August 23rd.

Majority of projects are focused on work related to Drupal 8 contributed modules. Drupal's students are from 4 different continents and we currently have 26 mentors from 12 countries with over 150 years of experience on drupal.org. As always, we're excited about this summer and we hope community members will provide an extra helping hand if you see students in queues. Learn more about our projects below.

Project: Social API
Student: Getulio Sánchez "gvso" (Paraguay).
Mentors dahacouk (UK), e0ipso (Spain), pcambra (Spain).

Project: Solving content conflicts with merge algorithms in Drupal 8
Student: Rakesh Verma "rakesh_verma" (India).
Mentors: dixon (Sweden), timmillwood (UK), jeqq (Moldova).

Project: Port Mailhandler to Drupal 8
Student: Milos Bovan "mbovan" (Serbia).
Mentors: miro_dietiker (Switzerland), Primsi (Slovenia).

Project: CKEditor plugins for TMGMT
Student: Saša Nikolič "sasanikolic" (Slovenia)
Mentors: miro_dietiker (Switzerland), Berdir (Switzerland).

Project: Port search configuration module to Drupal 8
Student: Joyce George "joyceg" (India)
Mentors: naveenvalech (India), heykarthikwithu (India), neetu (India).

Project: Integrate Google Cloud Vision API to Drupal 8
Student: Arpit Jalan "ajalan065" (India)
Mentors: naveenvalech (India), penyaskito (Spain).

Project: Port Google Login Authenticator To Drupal 8
Student: Mehul Gupta "therealssj" (India)
Mentors: nerdstein (USA), attiks (Belgium).

Project: Media Solution Module
Student: Vijay Nandwani "royal121" (India)
Mentors: slashrsm (Slovenia), paranojik (Slovenia).

Project: Web Component-ize Drupal 8
Student: Tianlei Zheng "ztl8702" (Australia)
Mentors: skyredwang (China), Wimleers (Belgium).

Project: Add Password-based Public-key Encryption to Drupal 8
Student: Talha Paracha "talhaparacha" (Pakistan)
Mentors: nerdstein (USA), colan (Canada), jibran (Pakistan).

Project: Porting Comment alter module to Drupal 8
Student: Anchal Pandey "anchal29" (India)
Mentors: Boobaa (Hungary), czigor (Hungary).

Final call for mentors. Are you interested in helping any of the projects above? Contact Slurpee on drupal.org, find us in #drupal-google on Freenode, and join us at https://groups.drupal.org/google-summer-code.

A special "Thank you" goes out to Drupalize.me for providing all of our students a free account.

Categories: Drupal

DrupalCon News: Training Spotlight: Project Management & Team Building

Planet Drupal - 25 April 2016 - 12:19pm

Not a developer? Not a problem! Each year, we see an increased number of project managers and professionals in non-technical roles such as business development, sales, marketing and HR at DrupalCon. We have training opportunities for you, too!

Categories: Drupal

Video: Can we save the open web?

Dries Buytaert - 25 April 2016 - 11:50am

In March, I did a presentation at SxSW that asked the audience a question I've been thinking about a lot lately: "Can we save the open web?".

The web is centralizing around a handful of large companies that control what we see, limit creative freedom, and capture a lot of information about us. I worry that we risk losing the serendipity, creativity and decentralization that made the open web great.


While there are no easy answers to this question, the presentation started a good discussion about the future of the open web, the role of algorithms in society, and how we might be able to take back control of our personal information.

I'm going to use my blog to continue the conversation about the open web, since it impacts the future of Drupal. I'm including the video and slides (PDF, 76 MB) of my SxSW presentation below, as well as an overview of what I discussed.

Here are the key ideas I discussed in my presentation, along with a few questions to discuss in the comments.

Idea 1: An FDA-like organization to provide oversight for algorithms. While an "FDA" in and of itself may not be the most ideal solution, algorithms are nearly everywhere in society and are beginning to impact life-or-death decisions. I gave the example of an algorithm for a self-driving car having to decide whether to save the driver or hit a pedestrian crossing the street. There are many other life-or-death examples of how unregulated technology could impact people in the future, and I believe this is an issue we need to begin thinking about now. What do you suggest we do to make the use of algorithms fair and trustworthy?

Idea 2: Open standards that will allow for information-sharing across sites and applications. Closed platforms like Facebook and Google are winning because they're able to deliver a superior user experience driven by massive amounts of data and compute power. For the vast majority of people, ease-of-use will trump most concerns around privacy and control. I believe we need to create a set of open standards that enable drastically better information-sharing and integration between websites and applications so independent websites can offer user experiences that meet or exceeds that of the large platforms. How can the Drupal community help solve this problem?

Idea 3: A personal information broker that allows people more control over their data. In the past, I've written about the idea for a personal information broker that will give people control over how, where and for how long their data is used, across every single interaction on the web. This is no small feat. An audience member asked an interesting question about who will build this personal information broker -- whether it will be a private company, a government, an NGO, or a non-profit organization? I'm not really sure I have the answer, but I am optimistic that we can figure that out. I wish I had the resources to build this myself as I believe this will be a critical building block for the web. What do you think is the best way forward?

Ultimately, we should be building the web that we want to use, and that we want our children to be using for decades to come. It's time to start to rethink the foundations, before it's too late. If we can move any of these ideas forward in a meaningful way, they will impact billions of people, and billions more in the future.

Categories: Drupal

Dries Buytaert: Video: Can we save the open web?

Planet Drupal - 25 April 2016 - 11:50am

In March, I did a presentation at SxSW that asked the audience a question I've been thinking about a lot lately: "Can we save the open web?".

The web is centralizing around a handful of large companies that control what we see, limit creative freedom, and capture a lot of information about us. I worry that we risk losing the serendipity, creativity and decentralization that made the open web great.


While there are no easy answers to this question, the presentation started a good discussion about the future of the open web, the role of algorithms in society, and how we might be able to take back control of our personal information.

I'm going to use my blog to continue the conversation about the open web, since it impacts the future of Drupal. I'm including the video and slides (PDF, 76 MB) of my SxSW presentation below, as well as an overview of what I discussed.

Here are the key ideas I discussed in my presentation, along with a few questions to discuss in the comments.

Idea 1: An FDA-like organization to provide oversight for algorithms. While an "FDA" in and of itself may not be the most ideal solution, algorithms are nearly everywhere in society and are beginning to impact life-or-death decisions. I gave the example of an algorithm for a self-driving car having to decide whether to save the driver or hit a pedestrian crossing the street. There are many other life-or-death examples of how unregulated technology could impact people in the future, and I believe this is an issue we need to begin thinking about now. What do you suggest we do to make the use of algorithms fair and trustworthy?

Idea 2: Open standards that will allow for information-sharing across sites and applications. Closed platforms like Facebook and Google are winning because they're able to deliver a superior user experience driven by massive amounts of data and compute power. For the vast majority of people, ease-of-use will trump most concerns around privacy and control. I believe we need to create a set of open standards that enable drastically better information-sharing and integration between websites and applications so independent websites can offer user experiences that meet or exceeds that of the large platforms. How can the Drupal community help solve this problem?

Idea 3: A personal information broker that allows people more control over their data. In the past, I've written about the idea for a personal information broker that will give people control over how, where and for how long their data is used, across every single interaction on the web. This is no small feat. An audience member asked an interesting question about who will build this personal information broker -- whether it will be a private company, a government, an NGO, or a non-profit organization? I'm not really sure I have the answer, but I am optimistic that we can figure that out. I wish I had the resources to build this myself as I believe this will be a critical building block for the web. What do you think is the best way forward?

Ultimately, we should be building the web that we want to use, and that we want our children to be using for decades to come. It's time to start to rethink the foundations, before it's too late. If we can move any of these ideas forward in a meaningful way, they will impact billions of people, and billions more in the future.

Categories: Drupal

Chapter Three: Cache API in Drupal

Planet Drupal - 25 April 2016 - 10:30am
Cache API in Drupal

This is a very simple tutorial that could help you with the performance of your custom modules. I will show you how to use Cache API in Drupal 8 and Drupal 7.

Minnur Yunusov April 25, 2016
Categories: Drupal

Chapter Three: Cache API in Drupal

Planet Drupal - 25 April 2016 - 10:30am

This is a very simple tutorial that could help you with the performance of your custom modules. I will show you how to use Cache API in Drupal 8 and Drupal 7.

You don't have to perform heavy caluclations every time you need to pull data either from third-party API or from database. Instead run it once and cache it. I personally use caching when I need to run complex SQL queries and third-party integrations (Example: get a list of available forms from Hubspot, or available campaign lists from Mailchimp etc).

In Drupal 8 use the following code structure:

Categories: Drupal

DrupalEasy: Demystifying Drupal 8's breakpoints.yml file

Planet Drupal - 25 April 2016 - 9:36am

While working through a couple of Drupal 8 projects involving a custom theme, I've been curious about the themename.breakpoints.yml file. I've dutifully updated it with the proper breakpoint values, but I've been a bit mystified with its actual purpose. There's nothing in either of the base themes I've used (Neato and Bootstrap) that actually appears to utilize the data in the breakpoints.yml files. While the breakpoints are defined in this file, they are also defined in the theme's source Sass and LESS files, for use in the processed CSS. 

I decided to dig into the issue a bit more over the past few days in an effort to figure out exactly what the purpose of the breakpoints.yml file is. It turns out that the any module or theme can create a themename.breakpoints.yml or modulename.breakpoints.yml file. The Breakpoint module (included as part of Drupal 8 core) then reads these files and adds them to the site's configuration. At this point, other installed modules and themes can access this configuration and utilize it in their own functionality. This is exactly how the Responsive Image module (also part of Drupal 8 core) works. It accesses the installed theme's breakpoints configuration (via the themename.breakpoints.yml file) and serves up proper responsive images based on that configuration.

But, at this time, there is nothing in Drupal core that automatically allows breakpoints defined in the themename.breakpoints.yml file to be easily used in the theme's CSS. So, when a theme's breakpoints.yml file is modified, nothing will change on the site until the site's CSS is also modified. In effect, most theme's breakpoints will need to be defined in two places - the themename.breakpoints.yml file and the theme's CSS. 

There are methods available (and still being developed) to "link" breakpoints defined in the breakpoints.yml file with the theme's CSS - usually as part of a pre-processing task when working with LESS or Sass. 

Resources
Categories: Drupal
Syndicate content


Google+
about seo