A plan for media management in Drupal 8

Posted by Dries Buytaert on November 8, 2016 at 9:23am

Today, when you install Drupal 8.2, the out-of-the-box media handling is very basic. For example, you can upload and insert images in posts using a WYSIWYG editor, but there is no way to reuse files across posts, there is no built-in media manager, no support for "remote media" such as YouTube videos or tweets, etc. While all of these media features can be added using contributed modules, it is not ideal.

This was validated by my "State of Drupal 2016 survey" which 2,900 people participated in; the top two requested features for the content creator persona are richer image and media integration and digital asset management (see slide 44 of my DrupalCon New Orleans presentation).

This led me to propose a "media initiative" for Drupal 8 at DrupalCon New Orleans. Since then a dedicated group of people worked on a plan for the Drupal 8 media initiative. I'm happy to share that we now have good alignment for that initiative. We want to provide extensible base functionality for media handling in core that supports the reuse of media assets, media browsing, and remote media, and that can be cleanly extended by contributed modules for various additional functionality and integrations. That is a mouthful so in this blog post, I'll discuss the problem we're trying to solve and how we hope to address that in Drupal 8.

Problem statement

While Drupal core provides basic media capabilities, contributed modules have to be used to meet the media management requirements of most websites. These contributed modules are powerful — look at Drupal's massive adoption in the media and entertainment market — but they are also not without some challenges.

First, it is hard for end-users to figure out what combination of modules to use. Even after the right modules are selected, the installation and configuration of various modules can be daunting. Fortunately, there are a number of Drupal distributions that select and configure various contributed modules to offer better out-of-the-box experience for media handling. Acquia maintains the Lightning distribution as a general purpose set of components including media best practices. Hubert Burda Media built the Thunder distribution and offers publishers strong media management capabilities. MD Systems created the NP8 distribution for news publishers which also bundles strong media features. While I'm a big believer in Drupal distributions, the vast majority of Drupal sites are not built with one of these distributions. Incorporating some of these media best practices in core would make them available to all end-users.

Second, the current situation is not ideal for module developers either. Competing solutions and architectures exist for how to store media data and how to display a library of the available media assets. The lack of standardization means that developers who build and maintain media-related modules must decide which of the competing approaches to integrate with, or spend time and effort integrating with all of them.

The current plan

In a way, Drupal's media management today is comparable to the state of multilingual in Drupal 7; it took 22 or more contributed modules to make Drupal 7 truly multilingual and some of those provided conflicting solutions. Multilingual in Drupal 7 was challenging for both end-users and developers. We fixed that in Drupal 8 by adding a base layer of services in Drupal 8 core, while contributed modules still cover the more complex scenarios. That is exactly what we hope to do with media in a future version of Drupal 8.

The plan for the Drupal 8 media initiative is to provide extensible base functionality for media handling in core that supports the reuse of media assets, media browsing, and remote media, and that can be cleanly extended by contributed modules for various additional functionality and integrations.

In order to do so, we're introducing a media entity type which supports plugins for various media types. We're currently aiming to support images and YouTube videos in core, while contributed modules will continue to provide more, like audio, Facebook, Twitter, etc. To facilitate media reuse, WYSIWYG image embedding will be rebuilt using media entities and a media library will be included to allow selecting from pre-existing media.

We consider this functionality to be the minimum viable product for media in Drupal 8 core. The objective is to provide a simple media solution to make Drupal 8 easy to use out of the box for basic use cases. This would help users of sites large and small.

Media library prototype A work-in-progress prototype of the proposed media library.

Expected timeline and call for help

We believe this could be achieved in a relatively short time — to be included in Drupal 8.3 or Drupal 8.4 as experimental modules. To help make this happen, we are looking for organizations to help fund two dedicated code sprints. The existing contributors are doing an amazing job but dedicated in-person sprints would go a long way to make the plans actually happen. If you are willing to help fund this project, let me know! Looking to help with the implementation itself? The media team meets at 2pm UTC every Wednesday. I also recommend you follow @drupalmedia for updates.

I tried to make a list of all people and organizations to thank for their work on the media initiative but couldn't. The Drupal 8 initiative borrows heavily from years of hard work and learnings on media related modules from many people and organizations. In addition, there are many people actively working on various aspects of the Drupal 8 media initiative. Special thanks to everyone who has contributed now and in the past. Also thank you to Gábor Hojtsy, Alex Bronstein and Janez Urevc for their contributions to this blog post.

A plan for media management in Drupal 8

Posted by Dries Buytaert on November 8, 2016 at 9:23am

Today, when you install Drupal 8.2, the out-of-the-box media handling is very basic. For example, you can upload and insert images in posts using a WYSIWYG editor, but there is no way to reuse files across posts, there is no built-in media manager, no support for "remote media" such as YouTube videos or tweets, etc. While all of these media features can be added using contributed modules, it is not ideal.

This was validated by my "State of Drupal 2016 survey" which 2,900 people participated in; the top two requested features for the content creator persona are richer image and media integration and digital asset management (see slide 44 of my DrupalCon New Orleans presentation).

This led me to propose a "media initiative" for Drupal 8 at DrupalCon New Orleans. Since then a dedicated group of people worked on a plan for the Drupal 8 media initiative. I'm happy to share that we now have good alignment for that initiative. We want to provide extensible base functionality for media handling in core that supports the reuse of media assets, media browsing, and remote media, and that can be cleanly extended by contributed modules for various additional functionality and integrations. That is a mouthful so in this blog post, I'll discuss the problem we're trying to solve and how we hope to address that in Drupal 8.

Problem statement

While Drupal core provides basic media capabilities, contributed modules have to be used to meet the media management requirements of most websites. These contributed modules are powerful — look at Drupal's massive adoption in the media and entertainment market — but they are also not without some challenges.

First, it is hard for end-users to figure out what combination of modules to use. Even after the right modules are selected, the installation and configuration of various modules can be daunting. Fortunately, there are a number of Drupal distributions that select and configure various contributed modules to offer better out-of-the-box experience for media handling. Acquia maintains the Lightning distribution as a general purpose set of components including media best practices. Hubert Burda Media built the Thunder distribution and offers publishers strong media management capabilities. MD Systems created the NP8 distribution for news publishers which also bundles strong media features. While I'm a big believer in Drupal distributions, the vast majority of Drupal sites are not built with one of these distributions. Incorporating some of these media best practices in core would make them available to all end-users.

Second, the current situation is not ideal for module developers either. Competing solutions and architectures exist for how to store media data and how to display a library of the available media assets. The lack of standardization means that developers who build and maintain media-related modules must decide which of the competing approaches to integrate with, or spend time and effort integrating with all of them.

The current plan

In a way, Drupal's media management today is comparable to the state of multilingual in Drupal 7; it took 22 or more contributed modules to make Drupal 7 truly multilingual and some of those provided conflicting solutions. Multilingual in Drupal 7 was challenging for both end-users and developers. We fixed that in Drupal 8 by adding a base layer of services in Drupal 8 core, while contributed modules still cover the more complex scenarios. That is exactly what we hope to do with media in a future version of Drupal 8.

The plan for the Drupal 8 media initiative is to provide extensible base functionality for media handling in core that supports the reuse of media assets, media browsing, and remote media, and that can be cleanly extended by contributed modules for various additional functionality and integrations.

In order to do so, we're introducing a media entity type which supports plugins for various media types. We're currently aiming to support images and YouTube videos in core, while contributed modules will continue to provide more, like audio, Facebook, Twitter, etc. To facilitate media reuse, WYSIWYG image embedding will be rebuilt using media entities and a media library will be included to allow selecting from pre-existing media.

We consider this functionality to be the minimum viable product for media in Drupal 8 core. The objective is to provide a simple media solution to make Drupal 8 easy to use out of the box for basic use cases. This would help users of sites large and small.

Media library prototype A work-in-progress prototype of the proposed media library.

Expected timeline and call for help

We believe this could be achieved in a relatively short time — to be included in Drupal 8.3 or Drupal 8.4 as experimental modules. To help make this happen, we are looking for organizations to help fund two dedicated code sprints. The existing contributors are doing an amazing job but dedicated in-person sprints would go a long way to make the plans actually happen. If you are willing to help fund this project, let me know! Looking to help with the implementation itself? The media team meets at 2pm UTC every Wednesday. I also recommend you follow @drupalmedia for updates.

I tried to make a list of all people and organizations to thank for their work on the media initiative but couldn't. The Drupal 8 initiative borrows heavily from years of hard work and learnings on media related modules from many people and organizations. In addition, there are many people actively working on various aspects of the Drupal 8 media initiative. Special thanks to everyone who has contributed now and in the past. Also thank you to Gábor Hojtsy, Alex Bronstein and Janez Urevc for their contributions to this blog post.

NP8 and Woodwing Content Station together support content creation process at Netzmedien

Posted by MD Systems blog on November 8, 2016 at 8:41am
In the last two months we released four portals for the Swiss tech publisher Netzmedien. All four websites are driven by the NP8 media distribution and their content is created and curated via Woodwing, a centralized multi-channel publishing platform.

Membership campaign recap from September-October 2016

Posted by Drupal Association blog on November 7, 2016 at 10:48pm
Thanks to all who helped

Many people contribute to our membership campaigns and the recent campaign is no different. Thanks to Andrey, Ricardo, Martha, Ivo, and Tom, for sharing your stories. To everyone who joined or renewed, thank you for your support. And, to our members and supporters who answered the call to share our message, thank you too.

You not only help the community by growing our membership, you give us motivation too.

Focus on grants

Members fund our Community Cultivation Grants program. The grants help grow communities and build local relationships for Drupal. This connection made the grants program an appropriate focus for a membership campaign.

This campaign was based on an idea: you feel more connected within the Drupal community when you receive a grant. Participants told their stories because this idea resonated with them. We shared their stories about feeling connected and how the member-funded grant inspired them to make a local impact for Drupal.

Results

We didn't meet the specific goals of 265 new members and $10,918 in revenue. New member growth did not happen to the degree we wanted for this campaign. We got to 45% of goal for number of new members who joined. Our revenue from the new members made it to 73% of our goal for funds raised. However, this is accounting for all new membership in the time period, and not specifically attribution to the campaign itself.

The breakdown went like this:

  • 120 signups by new members (100 Individual Members/ 20 Organization Members)
  • $8,050 revenue raised ($3730 Individual Members/ $4330 Organization Members)

For more details, see the data here.

We had three other concurrent places for sign ups. Our main ADO page, DrupalCon Dublin registration, and a page for DrupalCamp Atlanta were available. Thanks Eric, Dave, Shellie, and the whole Atlanta team for the pilot run.

During the 52-day period, 520 members joined or renewed and we raised $35,348 in total revenue. So if the goals I had set were for new, renewing, and reactivated members, we'd have been successful. Call this a good lesson in goal setting!

The first landing page on drupal.org

We had a team effort to create a well-designed landing page for this campaign. We used new design tools to create the first landing page for membership on drupal.org.  We'll use the tools again to add visual interest to our campaigns and we'll continue testing to find what works and what doesn't.

Landing page header with grey backgroundsecond section of landing page with Ricardo story and photo

More testing is needed

In our last campaign, the landing page on assoc.drupal.org had 16K pageviews. This campaign had only 25% of that traffic. This disproved the hypothesis that drupal.org would bring more traffic to a membership landing page.

We can see the banner launch and takedown had an impact on page traffic based on the data below. The hill showing on the graph shows the period we ran the banner (September 9-17). However, when we reintroduced the banner on September 28 through October 29, we saw no significant bump in traffic.

Google analytics show a single traffic bump during first run of the banner only
Traffic was 25% of the previous campaign landing page.

Social sharing makes a difference

Traffic spikes occurred around days we emailed to ask members to share the campaign. Not only do we see engagement from members, but there were spikes in membership sign-ups too.

Google analytics graph shows traffic bumps

Membership sales spike around the time of traffic bumps

We used a story-based approach

I used a storymapping exercise to think through this campaign concept to ensure we were telling a story that left readers satisfied. A story moves along a bell curve from exposition, to problem, to rising action, crisis, resolution, and falling action before the end. I'll try this again for the next campaign. The story-based approach helps to get our narratives into the bigger world and people are left with something they can remember and share.

Coming next

We are taking a deep look at how the drupal.org engineering team has made an impact in the community for our next campaign. We begin with the premise that the work the team does has helped increase the velocity of the innovation of Drupal. The team reduces the friction in the contribution journey and by doing so, we all benefit from their work. More on this to come on drupal.org in a few months.

Personal blog tags: Membership

Cracking the Shell at BADCamp

Posted by Mediacurrent on November 7, 2016 at 9:26pm
Illustration of Drupal logo on a blackboard

On October twenty-third I had the pleasure of speaking at BADCamp X, the tenth Bay Area Drupal Camp in Berkeley California. BADCamp is my favorite Drupal event not only because I can drive to it, but also because of the great people and quality of the camp, I never miss it.

Using Display Suite in Drupal 8: How to Use Display Suite Fields

Posted by Web Wash on November 7, 2016 at 9:00pm
In the previous tutorial, you learnt how to customize content pages by using a Display Suite layout. Today, I want to show you how to use Display Suite fields. Display Suite fields shouldn’t be confused with the standard field system. The best way to think of a field in Display Suite is as just a fancy formatter. The field will only render content. You can’t use it to store values or define a widget like you can with the standard field system. You’ve already seen this fields in action. If you select a layout you’ll notice a bunch of new fields appear. These are Display Suite fields which are implemented by the module. A field can be created in two fields: in code or through the Display Suite user interface (UI). Today we’ll look at how to create fields using the Display Suite UI. In a future tutorial, you’ll learn how to implement a field in code.

Migrating my blog from Drupal 6 to 8

Posted by Kris Vanderwater on November 7, 2016 at 7:52pm
Migrating my blog from Drupal 6 to 8 Kris Vanderwater 7 November 2016

Drupal 8 has been out for over a year at this point. I worked extensively on helping to improve portions of core during the Drupal 8 cycle, but maintaining your own site is radically different from trying to develop the platform that site(s) will reside upon. Upgrading my blog is especially exciting for me because I was still on Drupal 6. Getting to jump directly from Drupal 6 to Drupal 8 is a pretty big win and the fact that Drupal 8 supports this out of the box was amazing. Now granted this is just my blog, it's not even 100 nodes, but still...

Anatomy of a (terrific) Drupal 8 theme

Posted by Zivtech on November 7, 2016 at 6:18pm

The Bearskin 8 theme is built for Drupal 8 to streamline front-end development and add value for clients in the process.

Because Drupal 8 is brand new to everyone, we learn as we go, and implement best practices as they’re created. We’ve covered our bases with the available resources online (drupal.org, blog posts, code forums, internal discussions and code sharing), not to mention attending and presenting sessions at Drupal events.

With new systems, and specifically open source ones, best practices generally evolve rapidly, from experiment to consensus; patch to accepted contribution and solution to standard.

New does not have to be scary. It can also be exciting, and sometimes the hurdle is more about spreading this feeling, especially to clients.

But let’s be honest, Drupal for a front-end developer is far from a joy ride. Markup is barely accessible without knowing your preprocess functions, or by adding contributed modules that will help you do that through the UI. You add more weight to the code base and often have to export settings through features. That’s just the beginning. You see where I am going with this? Configuration management clusters, database synchronisation requirements, code maintainability conflicts across teams, and so on.

The good news is that Drupal 8 enables a front-end developer to separate the theme layer in a way that makes sense, maintaining autonomy while leveraging parts of site building that a front end developer should control.

Hell, we may see the emergence of a new breed of Drupalers. We can call them the Templaters.

Site builders out there: dive into TWIG if you have not done so already! Need convincing? Here are highlights:

  1. Component based approach to templating though specific inheritance functions (includes, extends and embeds) Increased security (default secure HTML output) Powerful, expressive (semantic) template language; easy syntax coupled with great features
  2. Front-end devs in charge of markup without having to dive into PHP preprocess functions or rely on back-end devs
  3. Integration (Pattern Lab)
  4. Easy to debug (devel, kint) and well documented
  5. Avoids Panels; build and register your own layouts; uses TWIG for the logic and Display Suite for UI management

How can we be sure that the path to develop Bear Skin was the right one?

We developed our early version of the Bear Skin theme for D8 prior to the official release. For that first attempt, we basically just ported our existing D7 theme layer.

While it worked, we quickly realized that we were not taking advantage of the new configuration under the hood in D8. In parallel we were experiencing difficulties in streamlining our design/wireframe/prototype/development process.

A robust website is composed (or at least should be, by modern standards) of more than 70% reusable components. The code base is smaller and more flexible, because the architecture relies on elements that can be reused throughout instead of being replicated in various contexts.

We had integrated an atomic design approach to our flow and defined our comprehensive hierarchy of the web components we usually use, but we weren’t quite sure how it could effectively translate to a Drupal build. Welcome Pattern Lab! Originally written for mustache, it was quick to be adapted for TWIG and guess what, TWIG is our new friend.

We studied, asked questions, researched, stole, shared, listened and were able to narrow down our conceptions on what was right (for us, that is). Many shops/people developed this concept early on and helped confirm the proper approach, each with their own variations (phase2, Forum One, Aleksi Peebles and John Albin with Zen).

How about a living styleguide that serves as the source for our Drupal theme layer?

We built a styleguide, defined our atoms, created the templates (TWIG), wrote our styles and eventually told Drupal to use (and reuse) them. It’s not sorcery, and seeing many Drupal shops and developers working in this direction made us feel comfortable investing the time to go further.

Afraid of templates? Don’t be. D7 gave them a bad reputation, but let’s move on! The problem is in defining a solid front-end architecture so that a site does not get over-templated. And let’s remember that everything is already templated by default. So why not have these templates at hand, living comfortably in a style guide where you have access to all of them at a glance, organized within a hierarchy you or your team have defined?

This is not only an improvement in output and scalability, but it also respects that this workflow forces us to implement good practices, and Pattern Lab has become our safeguard during the front end planning and implementation.

Let’s Dive in, Shall we?

https://www.drupal.org/project/bear_skin
https://github.com/zivtech/bear_skin/tree/8.x-2.x
https://www.drupal.org/project/bear_skin/releases/8.x-2.x-dev

Here is what our root looks like:


/bear_skin
|-- README.md
|-- backstop.json
|-- bear_skin.breakpoints.yml
|-- bear_skin.info.yml
|-- bear_skin.layouts.yml
|-- bear_skin.libraries.yml
|-- bear_skin.theme
|-- bin
|-- bower.json
|-- components
|-- config
|-- css
|-- default.gulpfile.yml
|-- docs
|-- favicon.ico
|-- fonts
|-- gulp-tasks
|-- gulpfile.js
|-- gulpfile.yml
|-- images
|-- js
|-- logo.png
|-- logo.svg
|-- node_modules
|-- out.txt
|-- package.json
|-- pattern-lab
|-- screenshot.png
|-- templates
|-- theme-settings.php

For those familiar with a D8 theme, Bear Skin includes the following:

  • a .info file for meta-data about your theme (bear_skin.info.yml)
  • a libraries file for defining all of your asset libraries (bear_skin.libraries.yml)
  • a breakpoints config file (bear_skin.breakpoints.yml)
  • a .theme file for conditional logic, preprocessing, and basic theme settings (bear_skin.theme)
  • a theme-settings.php file for modifying the theme settings form (theme-settings.php)
  • a logo file (logo.png)
  • a favicon file (favicon.ico)
  • a screenshot file that is shown on the Appearance page (screenshot.png)
  • a typical theme folder structure that includes directories for css, .js, templates, images, and fonts
In addition, our setup also includes:
  • a bin directory for shell script on post install
  • a component dir (we will go into detail about this one later in this post)
  • a config dir that sets up default settings when installing the theme, such as block placement and theme settings
  • a docs dir that details the steps to install and use the theme
  • a gulp task dir (usually a gulp file) to componentize and separate tasks for better (re)-usability. Our gulpfile.js calls for all these submodules
  • a pattern-lab dir that contains config files for pattern lab
  • a .bowerrc file that contains a path for bower to install dependencies
  • .sass-lint and .eslintrc contain the default settings for our javascript and sass linting tasks
  • a backstop.json file that contains the config for our css regression tests
  • a layouts.yml file that registers templates used by the layouts modules and display suite
  • a default.gulpfile.yml file (to be copied as a gulpfile.yml) that configures the various options for browsersync, pattern-lab, paths and more
  • a package.json file that contains our NPM packages dependencies

/bear_skin/components
|-- _annotations
|-- _data
|-- _layouts
|-- _macros
|-- _meta
|-- _patterns
|  |-- 0-Atomic-Design-Plan
|  |-- 00-utilities
|  |-- 01-atoms
|  |-- 02-molecules
|  |  |-- banner
|  |  |-- banner-with-page-title
|  |  |-- blocks
|  |  |-- comments
|  |  |-- messages
|  |  |  |-- _messages.scss
|  |  |  |-- messages.json
|  |  |  |-- messages.twig
|  |  |  |-- messages~error.json
|  |  |  |-- messages~warning.json
|  |  |-- navigation
|  |-- 03-organisms
|  |-- 04-layouts
|  |-- 05-pages
|-- _twig-components
|-- bear_skin.scss

What we did here is organize our components using the atomic design concept, and each of them has a directory containing a .twig, .json and .scss file. We also included a yeoman script to facilitate generating components.

The .twig file is our reusable template. It is going to be picked by pattern lab (Drupal only reads html.twig files).

The .json will add static data with either strings or includes from other patterns.

The .scss file will be the stylesheet for this component (only). Additional .yml or .md files can be added to display different types of information about the pattern.

The additional .json files with the ~ symbol are duplicating the component with different data provided by the json code. This is useful if you don’t want to create many TWIG files that have the same purpose but different data attributes, for instance.

The next step is to include, embed or extend this template on the drupal side with a .html.twig file, which will get picked up by the Drupal twig engine system.

We place these in the “templates” directory, following the same atomic structure.

/bear_skin/templates
|-- 01-atoms
|-- 02-molecules
|  |-- block--main-search.html.twig
|  |-- block--system-branding-block.html.twig
|  |-- block--system-menu-block.html.twig
|  |-- block.html.twig
|  |-- breadcrumb.html.twig
|  |-- details.html.twig
|  |-- form.html.twig
|  |-- menu-local-tasks.html.twig
|  |-- menu.html.twig
|  |-- pager.html.twig
|  |-- status-messages.html.twig
|-- 03-organisms
|-- 04-layouts
|-- 05-pages
|-- html.html.twig

This model basically follows the MVP architectural pattern, which helps separate concerns between logic and presentation. In our case the data model is Drupal, the presenter is our native twig files in Pattern Lab, and finally the passive view is the drupal templates.

Let’s discuss the massive advantages of doing things this way.

  • A style guide organized with these principles essentially becomes a comprehensive map for all developers working on the project, and clients alike.
  • Front end developers have much more control over the markup (structure, classes, other data attributes etc).
  • The front end developer does not need to wait to be handed the site once back end devs are done with a build. Development can be conducted in a parallel process.
  • Prototype: the living styleguide can easily become a way for you to prototype components or pages for your clients.
  • The site is prepared for scalability: a living styleguide approach enables us (and forces us) to consider how reusable each new component may be, and where it falls in our overall front end architecture.
  • We style once, we build once: CSS and templates are shared between Pattern Lab and Drupal.
  • Components: when styling, separating components helps avoiding over-nesting the Sass. We just don’t dump the CSS in a large files that already have one, two, or three parent selectors. We end up with more manageable and clean code.
  • We minimize the code output. One template can serve many pieces of content when reused, with or without a modifier.
Nothing is set in stone and we are likely to see this process evolve further, but these are great improvements over D7 and reasons to get excited about D8 builds. As a team it allows our vision about front end architecture and development to come to life, but also expands it as we keep discovering ways to streamline a shared development environment and offer our clients solutions that fit them best.

Special thanks to James Cole, Sean Wolfe and Stephanie Semerville for building this along with me. It’s a labor of love that accepts your contributions as well :) Found a bug? send your pull requests over here.

Meet Paul Johnson, the face behind @drupal, #celebr8d8, and more

Posted by Acquia Developer Center Blog on November 7, 2016 at 5:51pm
Drupal social media lead, Paul Johnson, and Jeffrey A. "jam" McGuire talk Drupal social media, community, and more.

I sat down with Drupal Social Media Lead, Paul Johnson at Drupal Camp London 2016, a few weeks after DrupalCon Asia in Mumbai. Paul runs the official community social media accounts on Twitter and elsewhere. I feel Paul is a kindred soul, since he and I both love highlighting and celebrating the Drupal community's stories and achievements.

The @drupal Twitter account alone has more than 65 thousand followers and Paul uses his powers for good. "I get so much satisfaction out of it. There's nothing I like more than to hear that it's made a difference to somebody, or I've heard something and made other people aware of it privately and that's maybe solved a problem. Social media is used for quite a lot of things ... It's not just a marketing channel."

Our conversation

Follow Drupal on social media!

Here are the accounts Paul runs:

Here is the Drupal Association Social Media Request Form that Paul mentions during our conversation.

And here is the full, official Drupal social media directory.

Mentioned in the conversation
Celebrate D8!

Images used in the podcast video
Podcast series: Drupal 8Skill Level: BeginnerIntermediateAdvanced

Drupal Accepted into Google Code-In 2016

Posted by groups.drupal.org frontpage posts on November 7, 2016 at 5:11pm

Proud to announce that Drupal was officially accepted to participate in Google's Code-In 2016 contest. More info @ https://codein.withgoogle.com/

At this point, Drupal needs mentors. Please contact me directly if interested in mentoring a few tasks or many tasks over next few months. We need all the help we can find. Tasks for GCI are meant to be easier for students ages 13-17. Amount of effort to mentor a few tasks is actually easy and enjoyable.

Not interested in mentoring, but have tasks for students? Do you want someone to write/test patches or create video tutorials for your module? Ping me for access to our task spreadsheet and add as many tasks as you want.

Chat with us in real time on IRC @ Freenode in #drupal-google

Using Configuration Management and Git in Drupal 8

Posted by Evolving Web on November 7, 2016 at 2:55pm
How to export and track Drupal 8 configuration on Git

Drupal 8 Configuration Managment (CM) is a "killer feature" for a web Content Management System (CMS). When setting up a Drupal site, we spend a lot of time on site configuration: Roles, Permissions, Content Types, Menus, Vocabularies, etc. In most CMS's, all these changes are stored in their databases, making it hard to deploy, track, reuse and rollback important changes.

read more

Using Configuration Management and Git in Drupal 8

Posted by Evolving Web on November 7, 2016 at 2:55pm
How to export and track Drupal 8 configuration on Git

Drupal 8 Configuration Managment (CM) is a "killer feature" for a web Content Management System (CMS). When setting up a Drupal site, we spend a lot of time on site configuration: Roles, Permissions, Content Types, Menus, Vocabularies, etc. In most CMS's, all these changes are stored in their databases, making it hard to deploy, track, reuse and rollback important changes.

read more

Dropcast: Episode 25: The Good, The BadCamp and The Ugly

Posted by Mediacurrent on November 7, 2016 at 1:48pm

Recorded October 26th

This episode we are all back in the ‘studio’ to talk about the great time most of us had at BADCamp the weekend prior. Ryan didn’t go so he won’t have much to say, but he will of course have his Final Bell, along with some Blog Mentions, Drupal News and a variety of failed humor.

Habitat for Humanity launches new website in Drupal 8

Posted by Mediacurrent on November 7, 2016 at 1:38pm
Mediacurrent launches new Drupal 8 site for Habitat for Humanity

Habitat for Humanity wanted to explore new ways to further highlight volunteer opportunities, broaden international reach, increase donations, and build an engaging desktop and mobile presence through its website, Habitat.org. Habitat undertook a new digital and content strategy to better help users find the information they are looking for to achieve these goals. The new Habitat.org recently was launched using Drupal 8 as its content management system.

Things I Learned from the DrupalTwig Slack: Volume 2

Posted by Annertech on November 7, 2016 at 1:15pm
Things I Learned from the DrupalTwig Slack: Volume 2

Welcome to Volume 2 of my adventures in learnings from the DrupalTwig Slack, a resource that continues to be the best source of (frontend) knowledge for Drupal. Again, if you haven't joined, do so. (Volume 1 is here.)

And without further ado, here's some things I've learned (or helped others to learn):

Things I Learned from the DrupalTwig Slack: Volume 2

Posted by Annertech on November 7, 2016 at 1:15pm
Things I Learned from the DrupalTwig Slack: Volume 2

Welcome to Volume 2 of my adventures in learnings from the DrupalTwig Slack, a resource that continues to be the best source of (frontend) knowledge for Drupal. Again, if you haven't joined, do so. (Volume 1 is here.)

And without further ado, here's some things I've learned (or helped others to learn):

Drupalcon - My First Encounter

Posted by Ixis.co.uk - Thoughts on November 7, 2016 at 11:05am

 

 

 

Palantir.net's Guide to Digital Governance: Organization

Posted by Palantir on November 7, 2016 at 3:09am
Palantir.net's Guide to Digital Governance: Organization Palantir.net's Guide to Digital Governance brandt Sun, 11/06/2016 - 21:09 Scott DiPerna Nov 7, 2016Illustrated collage of website icons

This is the seventh installment of Palantir.net’s Guide to Digital Governance, a comprehensive guide intended to help get you started when developing a governance plan for your institution’s digital communications.

In this post we will cover...
  • Why organization is important to site visitors
  • Questions you should consider regarding your main site and subsites
  • Some tools for creating good test-driven information architecture

We want to make your project a success.

Let's Chat.

A website’s organization is one of the most important factors in determining how effective and useful the site is for its visitors. Sites that are well-organized, in a manner that visitors intuitively understand, will be more effective and useful than those which aren’t. Therefore, it is important to define for your institution who will have the authority and responsibility to determine your website’s organization, and how they will make those decisions.

Here are some questions to consider with regard to main websites and subsites within the main site.

Main Website

  • Who determines the overall organizational hierarchy of the main website?
  • Who determines the top-level menu options? How are those decided?
  • Who determines the subsequent levels of navigation, order, labeling, etc.? How are those established?
  • Who determines other navigational structures, such as utility menus, topic-based menus, etc.?
  • Are there site-wide taxonomies to be maintained? Who determines and edits those?
  • What role does usage data, analytics, and user-testing play in those decisions?
  • Are there limits to the size, quantity, or depth of navigation?
  • Are there any site-wide standards for how navigation and sub-navigation are displayed?
  • Is there a process for addressing concerns or proposed changes to the site’s organization?
  • Who has the ability to make changes to the website’s overall structure?
  • Is there a review or approval process that needs to be followed?

Subsites

  • Who determines the organizations of sub-sites within the larger website?
  • Are there any guidelines or services for website owners who must create their own site organization?
  • Are there limits to the size, quantity, or depth of navigation?
  • Are there any site-wide standards for how navigation and sub-navigation are displayed?
  • Are there any site-wide standards for where navigation and sub-navigation are displayed on sub-site pages?
  • Are there rules for the labeling of navigation?
  • Are there sub-site specific taxonomies? How are those determined and edited? Must they conform to any site-wide standards or rules?

These questions cover only the definition of responsibility surrounding website organization, which presumes that you have good information architecture in place already. For more information on creating good, test-driven information architecture, Optimal Workshop has both advice and tools for conducting your own card sorts (OptimalSort) and menu “tree” tests (TreeJack). We use these tools regularly in our work.

 

This post is part of a larger series of posts, which make up a Guide to Digital Governance Planning. The sections follow a specific order intended to help you start at a high-level of thinking and then focus on greater and greater levels of detail. The sections of the guide are as follows:

  1. Starting at the 10,000ft View – Define the digital ecosystem your governance planning will encompass.
  2. Properties and Platforms – Define all the sites, applications and tools that live in your digital ecosystem.
  3. Ownership – Consider who ultimately owns and is responsible for each site, application and tool.
  4. Intended Use – Establish the fundamental purpose for the use of each site, application and tool.
  5. Roles and Permissions – Define who should be able to do what in each system.
  6. Content – Understand how ownership and permissions should apply to content.
  7. Organization – Establish how the content in your digital properties should be organized and structured.
  8. URLs – Define how URL patterns should be structured in your websites.
  9. Design – Determine who owns and is responsible for the many aspects design plays in digital communications and properties.
  10. Personal Websites – Consider the relationship your organization should have with personal websites of members of your organization.
  11. Private Websites, Intranets and Portals – Determine the policies that should govern site which are not available to the public.
  12. Web-Based Applications – Consider use and ownership of web-based tools and applications.
  13. E-Commerce – Determine the role of e-commerce in your website.
  14. Broadcast Email – Establish guidelines for the use of broadcast email to constituents and customers.
  15. Social Media – Set standards for the establishment and use of social media tools within the organization.
  16. Digital Communications Governance – Keep the guidelines you create updated and relevant.

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

Building a layout system for Paragraphs

Posted by PreviousNext on November 6, 2016 at 10:37pm

A recent Drupal 8 project of ours had some great requirements around it’s landing pages, aimed at reusing existing components in a range of layouts and combinations. Paragraphs quickly established itself as the site-building tool of choice and Flexbox always wins for me as the CSS grid/layout approach, so we looked at how the two could be combined to give the client the flexibility they needed, without over-complicating the editor experience.

Pages

Subscribe with RSS Subscribe to Drupal.org aggregator - Planet Drupal