Feeds

Author

May 14 2019
May 14
Oct 22 2018
Oct 22

This week I want to share some findings on the different ways to display an SVG inside the DOM using a simple Twig technique.

I am sure you will agree with me when I say that SVG is a very powerful thing when it comes to transforming a webpage from an ordinary, even boring I might say, into the work of art. And rather fast at that! Nevertheless, there are some tips & tricks that every developer should be aware of. Here is one of them: If you want to get the most out of SVGs, inline them!

This opens up a whole new universe of options and extra effects: A large palette of animations, changing SVGs’ colors based on some rules set in your Twig templates, using them as a clipping mask or similar, and lastly, very interesting and eye candy visual effects. How you go about doing this is however the main topic of this article. In general, there are two ways how you can implement this on your website.

The first and most straightforward solution is to simply insert your SVG code directly into the Twig template. Extremely simple, yet also “dirty” solution to this problem.

A more appropriate (and a suggested) way of doing this goes as follows: Include an SVG using the Twig “include” function, just the way you would include a typically Twig template inside another Twig template. This will automatically inline your SVG to your DOM, allowing you to do animations using CSS or JavaScript animation libraries, while keeping your Twig file clean and simple to understand.

You can do this using a following syntax (FYI, I use a custom “Emulsify” Drupal theme):

{% include "@type_of_component/component-name/your-svg-filename.svg" %}

If you are using a non-PatternLab Drupal theme, you should use Twig namespaces, e.g.:

{% include "@theme_machine_name/your-svg-filename.svg" %}

Example above is when your SVG is placed under the “templates” directory tree, if it’s outside of it, use “..” to return one step back, e.g. (when SVG is right under theme root directory):

{% include "@theme_machine_name/../your-svg-filename.svg" %}

And that’s it.

By using the Twig’s “include” function for an SVG, you also avoid a rather unpleasant issue. You probably already know that some “general rules of web development” suggest placing your icons and images into a single directory which we typically name “images” directly under a theme’s directory tree.

If you’re using a Drupal theme which comes with PatternLab, there may be situations where you already know that you’ll be using, for example, an SVG image just in a single place on your website. Placing it in a specific component directory actually helps you to keep your directory structures simple and (relatively) tidy.

There is just one, small catch: PatternLab’s side of a theme, unlike Drupal’s, uses different paths for files inside of a theme. That’s because of the different interpretations of a theme’s root directory between PatternLab and Drupal. Consequently, even if you implement your SVG through CSS or insert it’s path inside Twig, JSON or yml file, you won’t see the SVG both in PL and Drupal, but instead just in one of them. There are some ways around this, as nicely demonstrated in the article by Brian Lewis. A more straightforward solution however is to add SVGs with the “include” function, which is a really simple, yet powerful solution that works both in Drupal and PL. In other words, your SVGs will be displayed correctly both in Drupal and PL.

I should mention that you can also make your SVGs highly configurable by inserting Twig variables directly in SVGs. This way you can put variables for different pieces of SVG and manipulate them from within Twig templates. Consequently, you can change colors or some other SVG attributes in an easy and practical way.

Example:

- with your favorite IDE or text editor put this variable somewhere in your SVG file, for example, somewhere when some color is applied):

fill:{{ custom_color }}

- after that in a Twig file in which you already included this SVG, enter appropriate value in “custom_color” variable. End result will be something like:

(for PL Drupal theme)

{% include "@type_of_component/component-name/your-svg-filename.svg" with {
        custom_color: “#fe055e”,
} %}

(for non-PL Drupal theme)

{% include "@theme_machine_name/your-svg-filename.svg" with {
        custom_color: “#fe055e”,
} %}

Don’t forget to clear caches for changes to take effect!

Hope you will find these advices useful and feel free to share them with others.

Do you know of or use any other technique in situation like this one? If so, please share your thoughts and ideas!

Have a nice coding day! :)

Oct 04 2018
Oct 04

When I was starting my journey with PL/Drupal 8, one of the things that gave me some headache was related to the responsive images and their implementation.

As you already know (if you read my previous article) I'm using Emulsify Drupal theme. It's an amazing theme made by the folks over at Four Kitchens.

The theme comes preloaded with a bunch of ready to use components that can be used in your work or as a good practical example. The theme developers really tried to explain many complicated things that you might be facing regarding the PatternLab. However, implementing responsive images still continues to trouble many developers.

If you take a better look at the Emulsify theme, you'll see that they already made a fully functioning PL component for responsive images. You can easily use that in your PL components, you just need to enter your own data into corresponding yml file and that's pretty much it. Sounds simple, yet there is a "but”: In order to connect their PL component with your Drupal installation, you might think that you need to replace each variable value found in responsive-image.twig with that in corresponding Drupal twig template. That would be a process that undoubtedly results in growing out grays among web developers. :)

But there is a solution to this! In situations where you are required to incorporate a component which has many variables, you should actually just leave it to Drupal to render variables in its own way. How you wonder? Simply use an already available PL component for responsive images and then use Drupal variables you obtain with tools such as Kint, Symfony var-dumper or, my all-time favorite debugging tool - xDebug, in your Drupal twig template.

Let me show you how to make your life easier.

If you have a "card" component and want to use responsive images in it, a good way to accomplish this on a Drupal site is to make a Paragraph bundle for it. In there you will probably have fields for title, responsive image (obviously), text, and maybe a link.

I will not describe every step of making PL component for this "card" component in this article because it would be too long to digest and you can analyze already made card component in Emulsify.

It's really a simple task to connect and map component pieces like title, text and link in Drupal twig template.

Next, make a Twig block around the part of the component where responsive image is placed. That way, you get more freedom to modify it in the Drupal Twig template file using embed tag (more about that here & here).

That part of code will now look something like this (change your component variable name part of variable with your own name/term):

{% block image_content %}
  {% include "@atoms/04-images/00-image/responsive-image.twig" with {
    "responsive_image_base_class": your_component_variable_name_image_base_class,
    "responsive_image_modifiers": your_component_variable_name_image_modifiers,
    "responsive_image_blockname": your_component_variable_name_image_blockname,
    "img_srcset": img_srcset|default(img_element['#attributes'].srcset),
    "img_sizes": img_sizes|default(img_element['#attributes'].sizes),
    "img_src": img_src|default(img_element['#uri']),
    "img_alt": img_alt|default(img_element['#alt']),
    "output_image_tag": "TRUE",
  } %}
{% endblock %}

If you find this BEM function confusing, read this article by Evan Willhite (one of the Emulsify theme creators).

And now, you can simply swap everything inside that Twig block in your Drupal template file, so it should look like this (change machine name of responsive image field with your machine name of that field):

{% block image_content %}
  {{ content.field_machine_name_of_responsive_image_field[0] }}
{% endblock %}

And that is pretty much it!

Now, you may ask yourself: "What if I need to change something in the responsive image itself, maybe add a class or something like that?"

If that’s the case, you can make a theme suggestion for responsive images because there is just one theme suggestion at the moment of writing this article (Drupal 8.6).

Doing so you will simply modify the corresponding template file to fit your needs (in most cases, I add a desired class name).

You can use this code in your themename.theme for more theme name suggestions:

function themename_theme_suggestions_responsive_image_alter(&$suggestions, $vars, $hook) {
  $img_style_id = $vars['responsive_image_style_id'];
  $suggestions[] = 'responsive_image__' . $img_style_id;
}

Don't forget to change themename with the name of your theme and clear the cache so that changes take an effect.

Alternatively, you can simply insert a <div> wrapper around the responsive image piece of component and call it a day. That might not be the BEM way of doing things, but sometimes you need to break the rules in order to get things to work quickly.

If you want to read and learn more about the same topic, but with a different approach for other PL-ready themes, you can read the article from Mark Conroy.

Until next time, have a nice Drupal day! :)

Oct 02 2018
Oct 02

Not so long ago I wrote a short "How to" for using Emulsify Drupal theme with Docksal development environment (which you can also read in the official Emulsify wiki page).

In my humble opinion, Docksal is an amazing Docker powered environment for web development. It works blazing fast and is highly customizable. Give it a try!

In some other Docker based environments which I tried, I came across the obstacle. That obstacle was the use of the npm and its packages from dockerized environment simply because port 3000 wasn't opened for usage. Because I'm using the Emulsify Drupal theme, port 3000 is very important for me.

Guys behind Docksal fix that gap really fast so I switched all my projects to Docksal development environment.

Ok, let's start shall we.

Position yourself in the project root directory:

cd [project_root_dir]

Install Emulsify theme using Docksal's Composer (Composer instance installed and configured in Docksal image):

fin exec composer require fourkitchens/emulsify

NOTE!!! I recommend using the docksal/cli:2.0 or newer images (e.g. docksal/cli:2.0-php7.1). Docksal now exposes port 3000 for NodeJS apps by default so you can use Browsersync and similar node applications directly from Docksal containers. This means that it is no longer necessary to have node.js, nvm or/and yarn installed on your local OS.

Next, enable Emulsify and its dependencies. Drush 8.x users should use the following command but before that, position yourself in the web root directory ("web" or "docroot" in most cases) or use your drush aliases:

cd [web_root_dir]
fin exec drush en emulsify components unified_twig_ext -y

Drush 9.x users should use the following commands:

cd [web_root_dir]
fin exec drush en components unified_twig_ext -y
fin exec drush theme:enable emulsify

Optionally, create a custom clone of the Emulsify (you need to run the following command from within the Emulsify directory; replace "your_theme_name" with your theme name):

cd themes/contrib/emulsify
php emulsify.php "your_theme_name"

(Run php emulsify.php -h for other available options)

I like to use this clone command with the following arguments (replace Your Theme Name with your theme name):

fin exec php emulsify.php "Your Theme Name" --machine-name your-theme-name --path custom --description "Your Theme Name is a clone of Emulsify theme"

Next, run the following command from your theme directory if you're going to use your custom clone of the Emulsify theme (I always make a "custom" directory for custom themes, e.g. custom/your_theme_name):

cd ../..
cd custom/[your_theme_name]

If you plan on using the Emulsify theme (which is not recommended!), just stay in the contrib/emulsify directory.

If you already don't have your Github auth token globally defined you should do this now with (replace "YOUR_TOKEN" with the token generated on your Github account):

fin exec composer config --global github-oauth.github.com your_token

This step is necessary, otherwise, you'll get this error after executing command in the following step: "Failed to clone the [email protected]:drupal-pattern-lab/patternengine-php-twig.git repository".

Then run npm or yarn install command:

fin exec npm install

or

fin exec yarn install

After a successful installation you can start your Gulp tasks by running:

fin exec npm start

or

fin exec yarn start

There are 2 access URLs and you'll use the second one (external URL).

Finally, don't forget to set your theme as a default one. If you created a cloned theme, disable the original Emulsify theme (works on Drush 8.x):

fin exec drush pmu emulsify -y

or with:

fin exec drupal theme:uninstall emulsify

then enable and set to default your new theme in Drupal (you can do that with the Drupal console command or via the Drupal UI):

fin exec drupal theme:install [your_name_theme] --set-default

You're now ready to use your PL theme.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web