Newsfeeds

Jeff Geerling's Blog: Composer BoF at DrupalCon Baltimore

Planet Drupal - 25 April 2017 - 1:07pm

Tomorrow (Wednesday, April 25), I'm leading a Birds of a Feather (BoF) at DrupalCon Baltimore titled Managing Drupal sites with Composer (3:45 - 4:45 p.m. in room 305).

I've built four Drupal 8 websites now, and for each site, I have battle scars from working with Composer (read my Tips for Managing Drupal 8 projects with Composer). Even some of the tools that I use alongside composer—for project scaffolding, managing dependencies, patching things, etc.—have changed quite a bit over the past year.

As more and more Drupal developers adopt a Composer workflow for Drupal, we are solving some of the most painful problems.

For example:

Categories: Drupal

WizKids Announces Defenders Team Pack For Dice Masters

Tabletop Gaming News - 25 April 2017 - 1:00pm
Well, we’ve got the Avengers/Defenders War set coming for HeroClix. Might as well have some Defenders show up in Dice Masters, too, eh? WizKids has announced that they’ll be coming out with a Defender’s Team Pack for the game, including such heroes as The Hulk, Iron Fist, and Luke Cage. From the announcement: WizKids is […]
Categories: Game Theory & Design

Creator of DDoS program used against Minecraft and RuneScape sentenced to prison

Social/Online Games - Gamasutra - 25 April 2017 - 12:58pm

The program has been used in more than 1.7 million DDoS attacks, including some against Sony, Microsoft, TeamSpeak, Minecraft, and RuneScape. ...

Categories: Game Theory & Design

Twig Blocks

New Drupal Modules - 25 April 2017 - 12:54pm

Twig Blocks adds a Twig function to render blocks in Twig by passing in the block machine name.

To render a block, call the function in your Twig template:

{{ render_block('machine_name_of_your_block') }}

Categories: Drupal

Flying Frog Taking Pre-Orders For Shadows of Brimstone: Derelict Ship OtherWorld Expansion

Tabletop Gaming News - 25 April 2017 - 12:00pm
When Shadows of Brimstone first came out, it was all about the Weird West where you’d head down into a mine in search of the monsters that’d been coming out. It’s since branched out, with those tunnels leading to strange and fantastic worlds. The next tunnel you go down doesn’t lead to a world, though. […]
Categories: Game Theory & Design

Valuebound: How to add Custom JS / CSS to Drupal 7 page in theme for a better user experience

Planet Drupal - 25 April 2017 - 11:25am

Adding JS adds dynamic presentation effects to a theme for a better user experience.

In One of the project when i had been asked to display a custom error message to the User login page, when user tried with 3 or more failed attempt. On the other hand we can handle the error using form_set_error or drupal_set_message. What if we want to include that error message to be displayed on specific position.there comes add_js into picture. I have created a hook_form_alter inside that called a custom form validation. Under that custom form validation by checking the user login count, calling an js to the user page. Sleek and simple way to do the JS

Categories: Drupal

Podcast Roundup

Tabletop Gaming News - 25 April 2017 - 11:00am
I don’t know about you, but my Monday went by in a flash. It seemed I’d just clocked in when it was already almost time to go. But having a very busy day will do that. And that means this whole week is going to rush by, since I’m certainly busy. And while I work […]
Categories: Game Theory & Design

aleksip.net: Does Drupal have a minor upgrade problem?

Planet Drupal - 25 April 2017 - 10:47am
Drupal 8 has a new upgrade model, and the promise is to make upgrades easy forever. The idea behind the upgrade model is great, and has already been proven in other projects like Symfony. However, there might still be some issues that need to be solved, as demonstrated by the recent 8.3 release and the security release that followed it.
Categories: Drupal

CiviCRM Blog: New field types in CiviCRM Entity - Picking the right tool for the job!

Planet Drupal - 25 April 2017 - 10:41am

CiviCRM Entity is a contributed module for tightly integrating and extending CiviCRM with Drupal. This module exposes CiviCRM API entities as proper Drupal entity types. This is HUGE as it allows you to make CiviCRM data available within your favorite Drupal tools such as Rules, Views, and EntityReference. I’d like to present another advantage of Drupal entity types, and that is Drupal fields.

By enabling CiviCRM Entity, you can add Drupal fields and associate with CiviCRM entity types such as Contacts and Events. In fact, any of the hundreds of Drupal field types can be used with CiviCRM Entity.  You may be asking yourself, “Shouldn’t I use a CiviCRM custom field? Why would you want to use Drupal fields?” The correct answer is, you should choose the right tool for the job.

CiviCRM is great at having the business logic and infrastructure to support event registrations. CiviCRM has price sets, price fields, and custom fields for collecting information from users when they register for events, as well as the logic and structure that goes with payment processing and financial accounting. You would want to use a CiviCRM custom field to collect data for a specific user. This will be helpful because they data can be accessed via Reports.

Drupal, on the other hand, is much better at organizing and presenting content than CiviCRM. There are tons of modules that can be leveraged to give you the functionality you desire. Need a mobile responsive slideshow? Add a Drupal Image field, configure it to work with Flexslider slideshow. Images are perfect example of picking the right tool for the job. The images in the slideshow for an event is not related to any data that someone may need for reporting, so there is no point to make it a custom field in CiviCRM, so let Drupal do what it does well, store and present this kind of data.

What do I get out of the box?

When you install CiviCRM Entity, you get Drupal based view page and edit forms for all exposed entities. We will limit our examples to Events in this article, but the same applies for all entity types. You can create, update, and display CiviCRM Events, and never leave Drupal. The view page has the path “<site_root>/civicrm-event/[id]” where [id] is the event id, and <site_root> is the base url of your Drupal website. The edit form is “/civicrm-event/[id]/edit” and new events can be created at “/civicrm-event/add”.

This view page and edit form are “standard Drupal”, meaning that all fields and properties that are displayed can be managed in typical Drupal fashion.  We highly recommend installing the Display Suite (DS) module, and its submodule Display Suite Forms to take full advantage of the possibilities, as you can configure field groups, layouts, and use the provided Display Suite field formatters for many of CiviCRM’s properties. With DS Forms you can also choose to hide properties from the edit form, although you will be forced to include any API required properties.

For more information on how to add and manage fields and managing the Display with CiviCRM Entity, please continue read the full article on Skvare.com.

Download CiviCRM Entity

ToolsCiviCRMCiviEventDrupalExtensions
Categories: Drupal

Stellar Chaos Sci-Fi RPG Up On Kickstarter

Tabletop Gaming News - 25 April 2017 - 10:00am
In the future, humanity has spread out among the stars. Various planets and systems have all gotten new colonies. Then, all communication with the home planet, Earth, was lost. Nobody was quite sure why, but any expedition sent to figure out what happened has never come back or been heard from again. With the lack […]
Categories: Game Theory & Design

Drupal is API-first, not API-only

Dries Buytaert - 25 April 2017 - 9:59am

More and more developers are choosing content-as-a-service solutions known as headless CMSes — content repositories which offer no-frills editorial interfaces and expose content APIs for consumption by an expanding array of applications. Headless CMSes share a few common traits: they lack end-user front ends, provide few to no editorial tools for display and layout, and as such leave presentational concerns almost entirely up to the front-end developer. Headless CMSes have gained popularity because:

  • A desire to separate concerns of structure and presentation so that front-end teams and back-end teams can work independently from each other.
  • Editors and marketers are looking for solutions that can serve content to a growing list of channels, including websites, back-end systems, single-page applications, native applications, and even emerging devices such as wearables, conversational interfaces, and IoT devices.

Due to this trend among developers, many are rightfully asking whether headless CMSes are challenging the market for traditional CMSes. I'm not convinced that headless CMSes as they stand today are where the CMS world in general is headed. In fact, I believe a nuanced view is needed.

In this blog post, I'll explain why Drupal has one crucial advantage that propels it beyond the emerging headless competitors: it can be an exceptional CMS for editors who need control over the presentation of their content and a rich headless CMS for developers building out large content ecosystems in a single package.

As Drupal continues to power the websites that have long been its bread and butter, it is also used more and more to serve content to other back-end systems, single-page applications, native applications, and even conversational interfaces — all at the same time.

Headless CMSes are leaving editors behind This diagram illustrates the differences between a traditional Drupal website and a headless CMS with various front ends receiving content.

Some claim that headless CMSes will replace traditional CMSes like Drupal and WordPress when it comes to content editors and marketers. I'm not so sure.

Where headless CMSes fall flat is in the areas of in-context administration and in-place editing of content. Our outside-in efforts, in contrast, aim to allow an editor to administer content and page structure in an interface alongside a live preview rather than in an interface that is completely separate from the end user experience. Some examples of this paradigm include dragging blocks directly into regions or reordering menu items and then seeing both of these changes apply live.

By their nature, headless CMSes lack full-fledged editorial experience integrated into the front ends to which they serve content. Unless they expose a content editing interface tied to each front end, in-context administration and in-place editing are impossible. In other words, to provide an editorial experience on the front end, that front end must be aware of that content editing interface — hence the necessity of coupling.

Display and layout manipulation is another area that is key to making marketers successful. One of Drupal's key features is the ability to control where content appears in a layout structure. Headless CMSes are unopinionated about display and layout settings. But just like in-place editing and in-context administration, editorial tools that enable this need to be integrated into the front end that faces the end user in order to be useful.

In addition, editors and marketers are particularly concerned about how content will look once it's published. Access to an easy end-to-end preview system, especially for unpublished content, is essential to many editors' workflows. In the headless CMS paradigm, developers have to jump through fairly significant hoops to enable seamless preview, including setting up a new API endpoint or staging environment and deploying a separate version of their application that issues requests against new paths. As a result, I believe seamless preview — without having to tap on a developer's shoulder — is still necessary.

Features like in-place editing, in-context administration, layout manipulation, and seamless but faithful preview are essential building blocks for an optimal editorial experience for content creators and marketers. For some use cases, these drawbacks are totally manageable, especially where an application needs little editorial interaction and is more developer-focused. But for content editors, headless CMSes simply don't offer the toolkits they have come to expect; they fall short where Drupal shines.

Drupal empowers both editors and application developers This diagram illustrates the differences between a coupled — but headless-enabled — Drupal website and a headless CMS with various front ends receiving content.

All of this isn't to say that headless isn't important. Headless is important, but supporting both headless and traditional approaches is one of the biggest advantages of Drupal. After all, content management systems need to serve content beyond editor-focused websites to single-page applications, native applications, and even emerging devices such as wearables, conversational interfaces, and IoT devices.

Fortunately, the ongoing API-first initiative is actively working to advance existing and new web services efforts that make using Drupal as a content service much easier and more optimal for developers. We're working on making developers of these applications more productive, whether through web services that provide a great developer experience like JSON API and GraphQL or through tooling that accelerates headless application development like the Waterwheel ecosystem.

For me, the key takeaway of this discussion is: Drupal is great for both editors and developers. But there are some caveats. For web experiences that need significant focus on the editor or assembler experience, you should use a coupled Drupal front end which gives you the ability to edit and manipulate the front end without involving a developer. For web experiences where you don't need editors to be involved, Drupal is still ideal. In an API-first approach, Drupal provides for other digital experiences that it can't explicitly support (those that aren't web-based). This keeps both options open to you.

Drupal for your site, headless Drupal for your apps This diagram illustrates the ideal architecture for Drupal, which should be leveraged as both a front end in and of itself as well as a content service for other front ends.

In this day and age, having all channels served by a single source of truth for content is important. But what architecture is optimal for this approach? While reading this you might have also experienced some déjà-vu from a blog post I wrote last year about how you should decouple Drupal, which is still solid advice nearly a year after I first posted it.

Ultimately, I recommend an architecture where Drupal is simultaneously coupled and decoupled; in short, Drupal shines when it's positioned both for editors and for application developers, because Drupal is great at both roles. In other words, your content repository should also be your public-facing website — a contiguous site with full editorial capabilities. At the same time, it should be the centerpiece for your collection of applications, which don't necessitate editorial tools but do offer your developers the experience they want. Keeping Drupal as a coupled website, while concurrently adding decoupled applications, isn't a limitation; it's an enhancement.

Conclusion

Today's goal isn't to make Drupal API-only, but rather API-first. It doesn't limit you to a coupled approach like CMSes without APIs, and it doesn't limit you to an API-only approach like Contentful and other headless CMSes. To me, that is the most important conclusion to draw from this: Drupal supports an entire spectrum of possibilities. This allows you to make the proper trade-off between optimizing for your editors and marketers, or for your developers, and to shift elsewhere on that spectrum as your needs change.

It's a spectrum that encompasses both extremes of the scenarios that a coupled approach and headless approach represent. You can use Drupal to power a single website as we have for many years. At the same time, you can use Drupal to power a long list of applications beyond a traditional website. In doing so, Drupal can be adjusted up and down along this spectrum according to the requirements of your developers and editors.

In other words, Drupal is API-first, not API-only, and rather than leave editors and marketers behind in favor of developers, it gives everyone what they need in one single package.

Special thanks to Preston So for contributions to this blog post and to Wim Leers, Ted Bowman, Chris Hamper and Matt Grill for their feedback during the writing process.

Categories: Drupal

Dries Buytaert: Drupal is API-first, not API-only

Planet Drupal - 25 April 2017 - 9:59am

More and more developers are choosing content-as-a-service solutions known as headless CMSes — content repositories which offer no-frills editorial interfaces and expose content APIs for consumption by an expanding array of applications. Headless CMSes share a few common traits: they lack end-user front ends, provide few to no editorial tools for display and layout, and as such leave presentational concerns almost entirely up to the front-end developer. Headless CMSes have gained popularity because:

  • A desire to separate concerns of structure and presentation so that front-end teams and back-end teams can work independently from each other.
  • Editors and marketers are looking for solutions that can serve content to a growing list of channels, including websites, back-end systems, single-page applications, native applications, and even emerging devices such as wearables, conversational interfaces, and IoT devices.

Due to this trend among developers, many are rightfully asking whether headless CMSes are challenging the market for traditional CMSes. I'm not convinced that headless CMSes as they stand today are where the CMS world in general is headed. In fact, I believe a nuanced view is needed.

In this blog post, I'll explain why Drupal has one crucial advantage that propels it beyond the emerging headless competitors: it can be an exceptional CMS for editors who need control over the presentation of their content and a rich headless CMS for developers building out large content ecosystems in a single package.

As Drupal continues to power the websites that have long been its bread and butter, it is also used more and more to serve content to other back-end systems, single-page applications, native applications, and even conversational interfaces — all at the same time.

Headless CMSes are leaving editors behind This diagram illustrates the differences between a traditional Drupal website and a headless CMS with various front ends receiving content.

Some claim that headless CMSes will replace traditional CMSes like Drupal and WordPress when it comes to content editors and marketers. I'm not so sure.

Where headless CMSes fall flat is in the areas of in-context administration and in-place editing of content. Our outside-in efforts, in contrast, aim to allow an editor to administer content and page structure in an interface alongside a live preview rather than in an interface that is completely separate from the end user experience. Some examples of this paradigm include dragging blocks directly into regions or reordering menu items and then seeing both of these changes apply live.

By their nature, headless CMSes lack full-fledged editorial experience integrated into the front ends to which they serve content. Unless they expose a content editing interface tied to each front end, in-context administration and in-place editing are impossible. In other words, to provide an editorial experience on the front end, that front end must be aware of that content editing interface — hence the necessity of coupling.

Display and layout manipulation is another area that is key to making marketers successful. One of Drupal's key features is the ability to control where content appears in a layout structure. Headless CMSes are unopinionated about display and layout settings. But just like in-place editing and in-context administration, editorial tools that enable this need to be integrated into the front end that faces the end user in order to be useful.

In addition, editors and marketers are particularly concerned about how content will look once it's published. Access to an easy end-to-end preview system, especially for unpublished content, is essential to many editors' workflows. In the headless CMS paradigm, developers have to jump through fairly significant hoops to enable seamless preview, including setting up a new API endpoint or staging environment and deploying a separate version of their application that issues requests against new paths. As a result, I believe seamless preview — without having to tap on a developer's shoulder — is still necessary.

Features like in-place editing, in-context administration, layout manipulation, and seamless but faithful preview are essential building blocks for an optimal editorial experience for content creators and marketers. For some use cases, these drawbacks are totally manageable, especially where an application needs little editorial interaction and is more developer-focused. But for content editors, headless CMSes simply don't offer the toolkits they have come to expect; they fall short where Drupal shines.

Drupal empowers both editors and application developers This diagram illustrates the differences between a coupled — but headless-enabled — Drupal website and a headless CMS with various front ends receiving content.

All of this isn't to say that headless isn't important. Headless is important, but supporting both headless and traditional approaches is one of the biggest advantages of Drupal. After all, content management systems need to serve content beyond editor-focused websites to single-page applications, native applications, and even emerging devices such as wearables, conversational interfaces, and IoT devices.

Fortunately, the ongoing API-first initiative is actively working to advance existing and new web services efforts that make using Drupal as a content service much easier and more optimal for developers. We're working on making developers of these applications more productive, whether through web services that provide a great developer experience like JSON API and GraphQL or through tooling that accelerates headless application development like the Waterwheel ecosystem.

For me, the key takeaway of this discussion is: Drupal is great for both editors and developers. But there are some caveats. For web experiences that need significant focus on the editor or assembler experience, you should use a coupled Drupal front end which gives you the ability to edit and manipulate the front end without involving a developer. For web experiences where you don't need editors to be involved, Drupal is still ideal. In an API-first approach, Drupal provides for other digital experiences that it can't explicitly support (those that aren't web-based). This keeps both options open to you.

Drupal for your site, headless Drupal for your apps This diagram illustrates the ideal architecture for Drupal, which should be leveraged as both a front end in and of itself as well as a content service for other front ends.

In this day and age, having all channels served by a single source of truth for content is important. But what architecture is optimal for this approach? While reading this you might have also experienced some déjà-vu from a blog post I wrote last year about how you should decouple Drupal, which is still solid advice nearly a year after I first posted it.

Ultimately, I recommend an architecture where Drupal is simultaneously coupled and decoupled; in short, Drupal shines when it's positioned both for editors and for application developers, because Drupal is great at both roles. In other words, your content repository should also be your public-facing website — a contiguous site with full editorial capabilities. At the same time, it should be the centerpiece for your collection of applications, which don't necessitate editorial tools but do offer your developers the experience they want. Keeping Drupal as a coupled website, while concurrently adding decoupled applications, isn't a limitation; it's an enhancement.

Conclusion

Today's goal isn't to make Drupal API-only, but rather API-first. It doesn't limit you to a coupled approach like CMSes without APIs, and it doesn't limit you to an API-only approach like Contentful and other headless CMSes. To me, that is the most important conclusion to draw from this: Drupal supports an entire spectrum of possibilities. This allows you to make the proper trade-off between optimizing for your editors and marketers, or for your developers, and to shift elsewhere on that spectrum as your needs change.

It's a spectrum that encompasses both extremes of the scenarios that a coupled approach and headless approach represent. You can use Drupal to power a single website as we have for many years. At the same time, you can use Drupal to power a long list of applications beyond a traditional website. In doing so, Drupal can be adjusted up and down along this spectrum according to the requirements of your developers and editors.

In other words, Drupal is API-first, not API-only, and rather than leave editors and marketers behind in favor of developers, it gives everyone what they need in one single package.

Special thanks to Preston So for contributions to this blog post and to Wim Leers, Ted Bowman, Chris Hamper and Matt Grill for their feedback during the writing process.

Categories: Drupal

New interface allows more efficient, faster technique to remotely operate robots

Virtual Reality - Science Daily - 25 April 2017 - 9:43am
A new interface allows users to simply point and click on an item, then choose a grasp, to control a robot remotely.
Categories: Virtual Reality

Legendary Games Releases 2099 Wasteland RPG Book

Tabletop Gaming News - 25 April 2017 - 9:00am
I’ve posted many times that I love when a Kickstarter funds, then goes on sale to the general public. Now, most games that do that are months after the projected release date. Well, Legendary Games is doing something not a lot of Kickstarters can claim: releasing 2 months early. So if you want to get […]
Categories: Game Theory & Design

Responsive Image Formatter Link to Image Style

New Drupal Modules - 25 April 2017 - 8:55am

This module provides an additional formatter for image core field to link to an image style.

Installation

Install as you would normally install a contributed Drupal module.
See: drupal.org/documentation/install/modules-themes/modules-8 for further information.

Categories: Drupal

Aten Design Group: Using BrowserSync with Drupal 8

Planet Drupal - 25 April 2017 - 8:15am

TLDR: Just here for Browsersync setup? Skip to the steps.

I’m always looking for ways to reduce the time between saving a file and seeing changes on the screen.

When I first started working with Drupal, back in the day, I would ftp changes to a server and refresh the page. Once I found Transmit, I could mount a remote directory locally and automatically save files to the server. At the time, my mind was blown by the efficiency of it. In hindsight, it seems so archaic.

Then I started working with development teams. Servers were typically managed with version control. If I wanted to make changes to the server, I had to commit code and push it up. It was time to act like a grown up and develop with a local server.

The benefits of developing locally are too numerous to list here, but the most obvious is not having to push changes to a remote server to see the effects. I could just save a file, switch to the browser and refresh! What was taking minutes was reduced to seconds.

My progression of development practices went something like this.

“Oy, hitting cmd+r is so tedious. What’s this? LiveReload? OH MY GOD! It refreshes the page immediately upon saving! It even injects my CSS without refreshing the page! I’m so super fast right now! Whoa! Less! I can nest all my CSS so it matches the DOM exactly! Well that was a terrible idea. Not Less’s fault but ‘Hello Sass!’. Because Compass! And Vertical Rhythm! And Breakpoint! And Susy! Holy crap, it’s taking 8-12 seconds to compile CSS? Node sass you say?. That’s so much faster! Back down to 3 seconds. Wait a minute, everything I’m using Compass for, PostCSS handles. BOOM! Milliseconds!”

This boom and bust cycle of response times of mine has been going on for years and will continue indefinitely. Being able to promptly see the effects of your changes is incredibly important.

In 1968, Robert Miller published a paper in which he defined 3 thresholds of human-computer response times.

  • .1 sec. To feel like you are directly manipulating the machine
  • .1 - 1 sec. To feel like you are uninhibited by the machine, but long enough to notice a delay
  • > 10 sec. At this point, the user has lost focus and is likely to move onto another task while waiting for the computer.

In short, less than a second between making a file change and seeing the result is ideal. More than that and you’re likely to lose focus and check your email, Slack or Twitter. If it takes longer than 10 sec. to compile your code and refresh your browser, your productivity is screwed.

One of my favorite tools for getting super fast response times is Browsersync. Browsersync is a Node.js application that watches your files for changes then refreshes your browser window or injects new CSS into the page. It’s similar to LiveReload but much more powerful. The big difference is that Browsersync can be run in multiple browsers and on multiple devices on the same LAN at the same time. Each connected browser will automatically refresh when code changes. It also syncs events across browsers. So if you scroll the page in one browser, all your connected browsers scroll. If you click in one browser, all browsers will load the new page. It’s incredibly useful when testing sites across devices.

For simple sites, Browsersync will boot up its own local http server. For more complex applications requiring their own servers, such as Drupal, Browsersync will work as a proxy server. Setup is pretty simple but I’ve run into a few gotchas when using Browsersync with Drupal.

Setting up Browsersync Local dev environment

First things first, you’ll need a local dev environment. That’s beyond the scope of this post. There are a few great options out there including DrupalVM, Kalabox and Acquia Dev Desktop.

For this tutorial, we’ll assume your local site is being served at http://local.dev

Install Node

Again, out of scope. If you don’t already have node installed, download it and follow the instructions.

Install Browsersync

Browsersync needs to be installed globally.

npm install browser-sync -g

Change directories to your local site files.

cd wherever/you/keep/your/drupal/docroot

Now you can start Browsersync like so:

browser-sync start --proxy "local.dev" --files "**/*.twig, **/*.css, **/*.js”

The above will start a browsersync server available at the default http://localhost:7000. It will watch for changes to any Twig templates, CSS or JS files. When a change is encountered, it will refresh any browsers with localhost:7000 open. In the case of CSS, it will inject just the changed CSS file into the page and rerender the page rather than reloading it.

Making Drupal and Browsersync play nicely together

There’s a few tweaks we’ll need to do to our Drupal site to take full advantage of our Browsersync setup.

Disable Caching

First we want to make sure page caching is disabled so when we refresh the page, it’s not serving the old cached version.

Follow the steps outlined under “Enable local development settings” in the Disable Drupal 8 caching documentation.

Now when you change a Twig template file, the changes will be reflected on the page without having to rebuild the cache. Keep in mind, if you add a new file, you’ll still need to rebuild the cache.

Avoid loading CSS with @import statements

This gotcha was much less obvious to me. Browsersync will only recognize and refresh CSS files that are loaded with a link tag like so:

<link rel="stylesheet" href="/sites/.../style.css" media="all">

It does not know what to do with files loaded via @import tags like this:

<style> @import url('/sites/.../style.css'); </style>

This is all well and good as Drupal uses link tags to import stylesheets unless you have a whole lot of stylesheets, more than 31 to be exact. You see, IE 6 & 7 had a hard limit of 31 individual stylesheets. It would ignore any CSS files beyond that. It’s fairly easy to exceed that maximum when CSS aggregation is turned off as any module or base theme installed on your site can potentially add stylesheets. Drupal has a nice workaround for this by switching to the aforementioned @import statements if it detects more than 31 stylesheets.

We have two ways around this.

1. Turn preprocessing off on specific files

The first involves turning CSS aggregation (a.k.a. CSS preprocessing) on for your local site and manually disabling it for the files you are actually working with.

In settings.local.php, set the following to TRUE:

$config['system.performance']['css']['preprocess'] = TRUE;

Then in your [theme_name].libraries.yml file, turn preprocessing off for any files you are currently working on, like in the following example.

global: version: 1.0.x css: theme: build/libraries/global/global.css: { preprocess: false }

This will exclude this file from the aggregated CSS files. This approach ultimately leads to a faster site as your browser loads considerably fewer CSS files. However, it does require more diligence on your part to manage which files are preprocessed. Keep in mind, if you commit the above libraries.yml file as is, the global.css file will not be aggregated on your production environment as well.

2. Use the Link CSS module

The easier alternative is to use the Link CSS module. When enabled, this module will override Drupal’s @import workaround and load all files via the link tag regardless of how many. The only downside to this approach is the potential performance hit of still loading all the unaggregated CSS files which may not be a big deal for your environment.

Add a reload delay if needed

In some cases, you may want to add a delay between when Browsersync detects a change and when it attempts to reload the page. This is as simple as passing a flag to your browsersync command like so.

browser-sync start --proxy "d8.kbox.site" --files "**/*.twig, **/*.css, **/*.js" --reload-delay 1000

The above will wait 1 second after it detects a file change before reloading the page. The only time I’ve ever needed this is when using Kalabox as a local development environment. Your mileage may vary.

In addition to the reload delay flag, Browsersync has a number of other command line options you may find useful. It’s also worth noting that, if the command line approach doesn’t suit you, Browsersync has an api that you can tie into your Gulp or Grunt tasks. Here at Aten we use Browsersync tied into gulp tasks so a server can be started up by passing a serve flag to our build task. Similar to the following gulp compile --watch --serve

Categories: Drupal

Address USPS Validation Widget

New Drupal Modules - 25 April 2017 - 8:13am

Provides field widget for Address field validation using USPS Web Tools API.

Categories: Drupal

WizKids Previews Captain America For HeroClix

Tabletop Gaming News - 25 April 2017 - 8:00am
One of the bigger announcements in comic books in the past year or so was the revelation that Captain America had always been a deep-cover Hydra agent this whole time. Spoilers: it’s not that they retconned all of Steve’s backstory from the beginning. It’s that Red Skull is having some fun with the Cosmic Cube […]
Categories: Game Theory & Design

I Released My 5-Year Project Today (And I Feel Sick) - by Thomas Brush

Gamasutra.com Blogs - 25 April 2017 - 7:55am
After 5 years of obsessive development, my game about Hell is officially ready to be judged by the world.
Categories: Game Theory & Design

Playing with Viruses - by Ruslev Berg

Gamasutra.com Blogs - 25 April 2017 - 7:51am
Learn what online threats hang over present-day gamers and how they can stay safe.
Categories: Game Theory & Design

Pages

Subscribe to As If Productions aggregator