The default _global component as recommended by Compony.

Feel free to clone this component and adapt for your own use how you see fit.

Some extra's for aggregator-item components.

Extra template suggestions

Added a more specific template suggestion depending on the name of the feed the aggregator-item is from.

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'aggregator_item' -->
<!-- FILE NAME SUGGESTIONS:
   X aggregator-item--wikipedia.html.twig
   * aggregator-item.html.twig
-->

In above example:

• wikipedia is the name of the feed.

Better classes

The classes on aggregator-items has been changed to:

{%
  set classes = [
    'aggregator-item',
    feed ? 'aggregator-item--' ~ feed|clean_class,
  ]
%}

Which gives you the following classes:

.aggregator-item {}
.aggregator-item--wikipedia {}

Making more variables available in Twig

Aggregator items are not exposed in Drupal's Field UI, therefor it's tricky to reach the right variables. In this component 2 variables have been added that are available in the template:

• {{ feed }} can be used to show the name of the feed.
• {{ adapted_time }} can be used to show the aggregator-item was last updated.

This component specifically themes ajax-loading states of Drupal form buttons.

Better classes

Every button that can trigger ajax-behaviour will receive an extra class:

.ajax-button {}

If the form can't use Ajax, but you would like to mimic it using Ajax, you could fake the behaviour with Fake slow submitting form component.

This component overrides Drupal's progress indicator and replaces it completely with a js-loading class. This means we can more easily theme the component that triggered the ajax-call.

The Button with ajax-loading-state is an excellent example of building on top of this altered progress indication. 

Some extra's for block components.

Better classes

The classes on block has been changed to:

{%
  set classes = [
    'block',
    'block--' ~ configuration.provider|clean_class,
    'block--' ~ plugin_id|clean_class,
    'block--' ~ elements['#id']|clean_class,
  ]
%}

Which gives you the following classes:

.block {}
.block--my-custom-module {}
.block--my-block-id-block {}
.block--myblockid {} 

Extra functions

Create the possibility to have plugin-specific preprocess functions.

So inside block--page-title-block.theme you could now have this function:

<?php

/**
 * Implements template_preprocess_hook().
 */
function compony_preprocess_block__page_title_block(&$variables, $hook) {
  // Do custom preprocessing here, 
  // only for the page-title block. 
}

(Docs: Extending hooks yourself)

Some very basic breadcrumb theming

This component is an alternative to showing breadcrumbs on your page in a smooth mobile way without wrapping to multiple lines.

This component doesn't use JS, so everything is CSS-only!

Separator

All links are separated by a /. Feel free to adapt this to your design.

Smaller screens

On smaller screens there is a horizontal scroll, with the scrollbar hidden in the browser. 

To indicate there is a horizontal scroll possible, we are using a scroll-helper that shows a white-gradient on top of the content on the right side. 

Bigger screens

On bigger screens it is less common to horizontally scroll, so we disable the scroll there.

Instead, we are showing all the links next to each other again, but clipping the text of the links with the css property of text-overflow: ellipsis, when there is not enough vertical space. On hover, the link grows until all text is shown. 

A brick is a horizontal section of a website, many website designs are using horizontal stacked background to separate content vertically from each other.

This component is merely a css-class that can be applied to any html element to divide up a page visually in to bricks.

// brick.scss

.brick {
  display: block;
  width: 100%;
  position: relative;
}

.brick__inner {
  margin: 0 auto;
  max-width: 100%;
  width: 980px;
  padding: 50px 20px;
  .brick--no-horizontal-padding > & {
    padding-top: 0;
    padding-bottom: 0;
  }
}

.brick--gray {
  background: #333;
  color: #FFF;
}

Flexible data in a table design, without using table semantics.

Extra template suggestions

Added a more specific template suggestion based upon the id of the data-table. 

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'data_table' -->
<!-- FILE NAME SUGGESTIONS:
   x data-table--my-special-id.html.twig
   x data-table.html.twig
-->

Because tables are hard to design, each table-id will get it's unique template suggestion, so you can make them as custom as they need to be.

Better classes

Some classes are available on the data-table component:

{%
  set table_classes = [
    'data-table',
    id ? 'data-table--' ~ id|clean_class,
  ]
%}

Which gives you the following classes:

.data-table {}

// If you define a id for your data-table
.data-table--my-custom-id {}

Default theming and some extra's for Drupal's file links.

Making more variables available in Twig

In this component 4 extra variables have been added that are available in the template: 

• {{ file_uri }} contains the url where the link has to point as a string.
• {{ mime_type }} contains the type of the file.
• {{ filename }} contains the name of the file as a string.
• {{ size }} the size of the file in Kilobytes.

Some extra's for media components.

Better classes

The classes on taxonomy-terms has been changed to:

{%
  set classes = [
    'media',
    'media--' ~ elements['#media'].bundle()|clean_class,
    elements['#view_mode'] ? 'media--' ~ elements['#media'].bundle()|clean_class ~ '--' ~ elements['#view_mode']|clean_class,
    not elements['#media'].isPublished() ? 'media--unpublished',
  ]
%}

Which gives you the following classes:

.media {}
.media--file {}
.media--file--teaser {}
.media--unpublished {} 

Extra functions

Create the possibility to have media-type-specific preprocess functions.

So inside media--file.theme you could now have this function:

<?php

/**
 * Implements template_preprocess_hook().
 */
function compony_preprocess_media__file(&$variables, $hook) {
  // Do custom preprocessing here, 
  // only for media files. 
}

(Docs: Extending hooks yourself)

Some basic styling for local menu inks with a toggle for smaller screens.

This component implements Micromodal.js, a lightweight, configurable and a11y-enabled modal library written in pure JavaScript.

Some extra's for node components.

Better classes

The classes on node has been changed to:

{%
  set classes = [
    'node',
    'node--type-' ~ node.bundle|clean_class,
    node.bundle|clean_class,
    node.isPromoted() ? node.bundle|clean_class ~ '--promoted',
    node.isSticky() ? node.bundle|clean_class ~ '--sticky',
    not node.isPublished() ? node.bundle|clean_class ~ '--unpublished',
    view_mode ? node.bundle|clean_class ~ '--' ~ view_mode|clean_class,
  ]
%}

Which gives you the following classes:

.node {}
.node--type--faq {}
.faq {}
.faq--promoted {} 
.faq--sticky {} 
.faq--unpublished {} 
.faq--full {} 

Extra functions

Create the possibility to have content-type-specific preprocess functions.

So inside node--faq.theme you could now have this function:

<?php

/**
 * Implements template_preprocess_hook().
 */
function compony_preprocess_node__faq(&$variables, $hook) {
  // Do custom preprocessing here, 
  // only for FAQ nodes. 
}

(Docs: Extending hooks yourself)

A flat implementation of the Onomasticon output..

Extra template suggestions: one for entity type and one for the content type.

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'page' -->
<!-- FILE NAME SUGGESTIONS:
   x page--node--article.html.twig
   * page--node--37.html.twig
   * page--node--%.html.twig
   x page--node.html.twig
   * page.html.twig
-->

In above example:

• article is the content type of the node entity type 
• page--node.html.twig is already in place by Drupal, but doesn't always follow the correct BEM naming structure. For taxonomy-terms, Drupal will output page--taxonomy--term instead of page--taxonomy-term.

Some very basic theming for the pager component.

Some extra's for paragraph components.

Better classes

The classes on paragraph has been changed to:

{%
  set classes = [
    'paragraph',
    'paragraph--' ~ paragraph.bundle|clean_class,
    view_mode ? 'paragraph--' ~ paragraph.bundle|clean_class ~ '--' ~ view_mode|clean_class,
  ]
%}

Which gives you the following classes:

.paragraph {}
.paragraph--cta {}
.cta--teaser {}

Extra functions

Create the possibility to have paragraph-type-specific preprocess functions.

So inside paragraph--cta.theme you could now have this function:

<?php

/**
 * Implements template_preprocess_hook().
 */
function compony_preprocess_paragraph__cta(&$variables, $hook) {
  // Do custom preprocessing here, 
  // only for CTA paragraphs. 
}

(Docs: Extending hooks yourself)

Some extra's for region components.

Better classes

The classes on paragraph has been changed to:

{%
  set classes = [
    'region',
    'region--' ~ region|clean_class,
  ]
%}

Which gives you the following classes:

.region {}
.region--footer {}

A flat approach to theming Drupal's status messages by the use of emoji SVG's.

Some extra's for taxonomy-term components.

Extra template suggestions

Added 2 more specific template suggestions. One for view mode and one for vocabulary name and view-mode for all taxonomy terms

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'taxonomy_term' -->
<!-- FILE NAME SUGGESTIONS:
   x taxonomy-term--faq--full.html.twig
   x taxonomy-term--full.html.twig
   * taxonomy-term--556.html.twig
   * taxonomy-term--faq.html.twig
   * taxonomy-term.html.twig
-->

In above example:

• full is the view-mode
• faq is the vocabulary name

Better classes

The classes on taxonomy-terms has been changed to:

{%
  set classes = [
    'taxonomy-term',
    'taxonomy-term--' ~ term.bundle|clean_class,
    view_mode ? 'taxonomy-term--' ~ view_mode|clean_class,
    view_mode ? term.bundle|clean_class ~ '--' ~ view_mode|clean_class,
  ]
%}

Which gives you the following classes:

.taxonomy-term {}
.taxonomy-term--faq {}
.taxonomy-term--full {}
.faq--full {} 

Extra functions

Create the possibility to have vocabulary-specific preprocess functions.

So inside taxonomy-term--faq.theme you could now have this function:

<?php

/**
 * Implements template_preprocess_hook().
 */
function compony_preprocess_taxonomy_term__faq(&$variables, $hook) {
  // Do custom preprocessing here, 
  // only for FAQ taxonomy-terms. 
}

(Docs: Extending hooks yourself)

Defines a custom dropdown component that can be used to hide content on page load but keep it available under a toggle.

Make the pager of the views infinite scroll module have an ajax-loading-state.

Some extra's for views-view components.

Extra template suggestions

Added 2 more specific template suggestions. One for the name of the view and one for the display name of that view.

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'views_view' -->
<!-- FILE NAME SUGGESTIONS:
   x views-view--articles--last-published.html.twig
   x views-view--articles.html.twig
   * views-view.html.twig
-->

In above example:

• articles is the name of the view
• last-published is the name of the display used of the articles view

Better classes

The classes on taxonomy-terms has been changed to:

{%
  set classes = [
    'views-view',
    'views-view--' ~ id|clean_class,
    'views-view--' ~ id|clean_class ~ '--' ~ display_id,
    dom_id ? 'js-view-dom-id-' ~ dom_id,
  ]
%}

Which gives you the following classes:

.views-view {}
.views-view--articles {}
.views-view--articles--overview {}

// Drupal-supplied unique idendifier to be used by JS
.js-view-dom-id-683eb5bba {} 

Removes divs without classes, when using unformatted list in your view settings (screenshot 1) in combination with no views row classes (screenshot 2).

Webforms in Drupal are user-generated forms mostly, To support consistent form theming, we are taking the same approach as the form component , where everything has to live in a fieldset.

Added the webform title

The webform title is now available in the template to print as follows:

{{ title }}

Better theme-able HTML

{{ attach_library('compony/form') }}
<form{{ attributes.addClass('form') }}>
  {{ attach_library('compony/fieldset') }}
  <fieldset class="js-form-wrapper form-wrapper fieldset">
    <h3 class="legend">
      <span class="fieldset-legend">{{ title }}</span>
    </h3>

    {{ title_prefix }}

    {{ children }}

    {{ title_suffix }}
  </fieldset>
</form>

The webform is now by default also using the form component and the fieldset component.

This is a CSS-only component to theme the output of wysiwyg.

This component can be loaded in conditionally from other components. 

It can be used for both frontend as backend when people are working in the wysiwyg.