Drupal

City of Boston launches Boston.gov on Drupal

Dries Buytaert - 21 July 2016 - 9:50am

Yesterday the City of Boston launched its new website, Boston.gov, on Drupal. Not only is Boston a city well-known around the world, it has also become my home over the past 9 years. That makes it extra exciting to see the city of Boston use Drupal.

As a company headquartered in Boston, I'm also extremely proud to have Acquia involved with Boston.gov. The site is hosted on Acquia Cloud, and Acquia led a lot of the architecture, development and coordination. I remember pitching the project in the basement of Boston's City Hall, so seeing the site launched less than a year later is quite exciting.

The project was a big undertaking as the old website was 10 years old and running on Tridion. The city's digital team, Acquia, IDEO, Genuine Interactive, and others all worked together to reimagine how a government can serve its citizens better digitally. It was an ambitious project as the whole website was redesigned from scratch in 11 months; from creating a new identity, to interviewing citizens, to building, testing and launching the new site.

Along the way, the project relied heavily on feedback from a wide variety of residents. The openness and transparency of the whole process was refreshing. Even today, the city made its roadmap public at http://roadmap.boston.gov and is actively encouraging citizens to submit suggestions. This open process is one of the many reasons why I think Drupal is such a good fit for Boston.gov.

More than 20,000 web pages and one million words were rewritten in a more human tone to make the site easier to understand and navigate. For example, rather than organize information primarily by department (as is often the case with government websites), the new site is designed around how residents think about an issue, such as moving, starting a business or owning a car. Content is authored, maintained, and updated by more than 20 content authors across 120 city departments and initiatives.

The new Boston.gov is absolutely beautiful, welcoming and usable. And, like any great technology endeavor, it will never stop improving. The City of Boston has only just begun its journey with Boston.gov - I’m excited see how it grows and evolves in the years to come. Go Boston!

Last night there was a launch party to celebrate the launch of Boston.gov. It was an honor to give some remarks about this project alongside Boston Mayor Marty Walsh (pictured above), as well as Lauren Lockwood (Chief Digital Officer of the City of Boston) and Jascha Franklin-Hodge (Chief Information Officer of the City of Boston).
Categories: Drupal

Dries Buytaert: City of Boston launches Boston.gov on Drupal

Planet Drupal - 21 July 2016 - 9:50am

Yesterday the City of Boston launched its new website, Boston.gov, on Drupal. Not only is Boston a city well-known around the world, it has also become my home over the past 9 years. That makes it extra exciting to see the city of Boston use Drupal.

As a company headquartered in Boston, I'm also extremely proud to have Acquia involved with Boston.gov. The site is hosted on Acquia Cloud, and Acquia led a lot of the architecture, development and coordination. I remember pitching the project in the basement of Boston's City Hall, so seeing the site launched less than a year later is quite exciting.

The project was a big undertaking as the old website was 10 years old and running on Tridion. The city's digital team, Acquia, IDEO, Genuine Interactive, and others all worked together to reimagine how a government can serve its citizens better digitally. It was an ambitious project as the whole website was redesigned from scratch in 11 months; from creating a new identity, to interviewing citizens, to building, testing and launching the new site.

Along the way, the project relied heavily on feedback from a wide variety of residents. The openness and transparency of the whole process was refreshing. Even today, the city made its roadmap public at http://roadmap.boston.gov and is actively encouraging citizens to submit suggestions. This open process is one of the many reasons why I think Drupal is such a good fit for Boston.gov.

More than 20,000 web pages and one million words were rewritten in a more human tone to make the site easier to understand and navigate. For example, rather than organize information primarily by department (as is often the case with government websites), the new site is designed around how residents think about an issue, such as moving, starting a business or owning a car. Content is authored, maintained, and updated by more than 20 content authors across 120 city departments and initiatives.

The new Boston.gov is absolutely beautiful, welcoming and usable. And, like any great technology endeavor, it will never stop improving. The City of Boston has only just begun its journey with Boston.gov - I’m excited see how it grows and evolves in the years to come. Go Boston!

Last night there was a launch party to celebrate the launch of Boston.gov. It was an honor to give some remarks about this project alongside Boston Mayor Marty Walsh (pictured above), as well as Lauren Lockwood (Chief Digital Officer of the City of Boston) and Jascha Franklin-Hodge (Chief Information Officer of the City of Boston).
Categories: Drupal

Mediacurrent: Think First, Then Design

Planet Drupal - 21 July 2016 - 8:01am

There are many talented designers with the ability to create a fabulous, responsive, web design worthy of the term “screen candy.” But looks aren’t everything and website design is not just art. When a website fails to engage the visitor, it’s often due to the designer’s failure to plan strategically.

Categories: Drupal

Node Authorization

New Drupal Modules - 21 July 2016 - 6:17am

Node Authorization allows users to add simple HTTP authorization to individual nodes. This is not a replacement for the user and content access system, just a lightweight alternative to create simple access restrictions on per-node basis. Note that HTTP authorization is not a totally secure system, particularly on non-HTTPS sites. If you require robust security to protect sensitive node content, please use Drupal's more established content access system.

Categories: Drupal

Drupalize.Me: Why Is Learning Drupal Hard?

Planet Drupal - 21 July 2016 - 6:00am

When it comes to learning Drupal I have a theory that there's an inverse relationship between the scope of knowledge that you need to understand during each phase of the learning process, and the density of available resources that can teach it to you. Accepting this, and understanding how to get through the dip, is an important part of learning Drupal.

Categories: Drupal

FFW Agency: The Power of Extending Twig Templates

Planet Drupal - 21 July 2016 - 12:06am
The Power of Extending Twig Templates David Hernandez Thu, 07/21/2016 - 07:06

Extending in Twig is a method by which one template can inherit content from another template, while still being able to override parts of that content. This relationship is easy to imagine if you are familiar with Drupal’s default system of template inheritance.

A theme can have multiple page templates, many node templates, even more field templates, and a plethora of block and Views template. And it is common for those templates to largely be identical, save for a snippet of markup or some logic. The advantage in extending templates is reducing this duplication, thereby simplifying architecture and easing maintenance.

Let’s say, for example, you want to change the template for a specific block, adding a wrapper div around the main content area. This might be done by copying the standard block template and giving it a name specific to your block.

Classy’s block.html.twig template
{%
  set classes = [
    'block',
    'block-' ~ configuration.provider|clean_class,
    'block-' ~ plugin_id|clean_class,
  ]
%}
<div{{ attributes.addClass(classes) }}>
  {{ title_prefix }}
  {% if label %}
    <h2{{ title_attributes }}>{{ label }}</h2>
  {% endif %}
  {{ title_suffix }}
  {% block content %}
    {{ content }}
  {% endblock %}
</div>

Copied to block--my-special-block.html.twig
{%
  set classes = [
    'block',
    'block-' ~ configuration.provider|clean_class,
    'block-' ~ plugin_id|clean_class,
  ]
%}
<div{{ attributes.addClass(classes) }}>
  {{ title_prefix }}
  {% if label %}
    <h2{{ title_attributes }}>{{ label }}</h2>
  {% endif %}
  {{ title_suffix }}
  {% block content %}
    <div class=”content-wrapper”>{{ content }}</div>
  {% endblock %}
</div>

This accomplishes your goal. You have a template specific to this particular block, and a wrapper div just where you need it. Following the same method, and with a complex site, you can end up with lots of different block templates (or node templates, or field templates, or … you get the idea.)

But, now you have a different problem. The majority of the template is duplicated. All the CSS classes, the outer wrapper, the markup for the block title, etc. If any of that needs to be changed, like changing all block titles from H2s to H3s, you have to update every single one of those templates.

Even if this happens infrequently enough not to be considered time consuming, it is still prone to errors. You might make a mistake in one template, miss one that needs changing, or even change one that should not be changed.

This is where {% extends %} comes in

Extending templates allows you to reference the original template, and only override the parts that are unique to the child template.

In the block example, we can create a block--my-special-block.html.twig template with this content:

{% extends "block.html.twig" %}
{% block content %}
  <div class=”content-wrapper”>{{ parent() }}</div>
{% endblock %}

That’s it. That is the whole template. Twig uses the original block.html.twig template as the main template, and only uses what we override in the more specific block--my-special-block.html.twig template.

The parent() function simply returns all of the content within the {% block %} tags in the original template. This saves us from having to duplicate that content; keeping the template simple, and future proofing it. If any of that content changes in the original template, we don’t have to update the block--my-special-block.html.twig template.

In this example, the content in the original template is fairly simple, only printing the content variable, but imagine if there was a large amount of multiline html and Twig code wrapped in those block tags.

Twig blocks, not Drupal blocks!

This overriding is done by using Twig blocks. (Terminology is fun!) The Twig block is what you see identified by the {% block %} and {% endblock %} tags. The word "content" is the identifier for the block. You can have multiple blocks in a single template.

In the block--my-special-block.html.twig template file, we can do anything we want inside the block tags. Twig will replace the original templates “block” with the one in block--my-special-block.html.twig.

What else?

Well, you have access to pretty much everything in the main template, except the printed markup. So, for example, you can modify the variables it uses.

{% extends "block.html.twig" %}
{% set attributes = attributes.addClass(‘super-special’) %}

This template will add a CSS class called "super-special" to the attributes printed in the outer wrapper of the original block template. The alternative would be to copy the content of the entire block.html.twig template just to add this class to the ‘classes’ array at the top of the file.

You can also just set a variable that will be used by the original template.

{% extends "block.html.twig" %}
{% set foo = 'yellow' %}

Imagine a series of variant field or content type templates that set variables used by the original template for classes, determining structure, etc.

You can even add Twig logic.

{% extends "block.html.twig" %}
{% block content %}
  {% if foo %}
    <div class=”content-wrapper”>{{ parent() }}</div>
  {% else %}
    {{ parent() }}
  {% endif %}
{% endblock %}

Pretty much anything you still might want to do with Twig, inside or outside of the block tags, you can still do.

Things to note

Before you jump right in, and bang your head against a wall trying to figure out why something isn’t working, there a few things to know.

  • The {% extends %} line needs to be at the top of the file.
  • When overriding markup, you can only change what is within block tags in the original template. So add {% block %} tags around anything you might want to modify.
  • You cannot print additional things outside of the overriding block tags. You will have an extends line. You can set variables, add comments, add logic, and override blocks. You cannot put other pieces of markup in the template. Only markup that is inside a block.
  • If Drupal does not extend the correct template, based on what you expect from template inheritance, you may have to explicitly state the template you want.
    Example: {% extends "@classy/block/block.html.twig" %}
Additional Resources Tagged with Comments
Categories: Drupal

Taxonony MaxDepth

New Drupal Modules - 20 July 2016 - 9:30pm
Categories: Drupal

ePayco for Ubercart

New Drupal Modules - 20 July 2016 - 2:15pm

This module integrates ePayco payment solution with Ubercart e-commerce module.

This module is being developed by micoworker.

Categories: Drupal

GVSO Blog: [GSoC 2016: Social API] Week 8: Social Post implementer

Planet Drupal - 20 July 2016 - 1:36pm
[GSoC 2016: Social API] Week 8: Social Post implementer

Week 8 is over and we are just one month away from Google Summer of Code final evaluation. I mentioned in my last weekly summary that I would work on documentation about implementing a Social Auth integration.

gvso Wed, 07/20/2016 - 16:36 Tags Drupal Drupal Planet GSoC 2016
Categories: Drupal

Third & Grove: Drupal GovCon: Day 1 Recap

Planet Drupal - 20 July 2016 - 11:03am
Drupal GovCon: Day 1 Recap abby Wed, 07/20/2016 - 14:03
Categories: Drupal

Into my Galaxy: GSoC’ 16: Port Search Configuration module; coding week #8

Planet Drupal - 20 July 2016 - 10:50am

I have been porting Search Configuration module from Drupal 7 to 8 as part of this year’ s Google Summer of Code (GSoC). This summer program is an opportunity for university students to work on projects connected with open source organisation. I have been really lucky to be a part of this initiative. I could explore deep of more technologies, version control systems as part of my project in Drupal. This gives young students a platform where they are assigned mentors who are experts and experienced in various software.

Last week, I could learn some of the Drupal concepts as part of this module port. So, let me begin with the Drupal 7 property. The t function translates a string to the current language or to a given language. This makes the strings used in Drupal translatable. This generally takes up the format:

t($string, array $args = array(), array $options = array());

Here, $string is the string containing the English text to get translated.

$args: An associative array of replacements to make after translation.

$options: An optional associative array of additional options, with the following elements: lang code and context.

This t function has got some alteration in the Drupal 8. It has been replaced by the $this->t() by making use of \Drupal\Core\StringTranslation\StringTranslationTrait. 

 The translatable markup returns a string as a result of this process.

Another important aspect which I dealt was the roles. This is an important feature  for any module as it  deals with the security constraints of the module. Roles are often manipulated to grant certain permissions. What we have to do is that, initially, load the particular role to be manipulated and then provide the permission which is to be granted.

$role = Role::load('access page.'); $role->grantPermission('access comments'); $role->save();

These role functions help us to load the roles and manipulate the permissions assigned to it quite easily. Thus, turns out to be really helpful in dealing with permissions.

I have been also dealing with writing the simple test for my module. In one of my previous blog posts, I have introduced the PHP unit testing.  The simple test tests the web oriented functionality of the module. It needs a good understanding of the behaviour of the module to write an effective test. Tests are often really important to identify the flaws of a functionality and to correct it accordingly. I will be writing the simple tests for my module in the coming days. I will be sharing you the concept of this mode of testing in my next blog post.

Stay tuned for further developments on this blog post.

 

 

 


Categories: Drupal

Drupal core announcements: Drupal 8.2.0 will be released October 5; beta begins week of August 3

Planet Drupal - 20 July 2016 - 9:23am

Drupal 8.2.0, the next planned minor release of Drupal 8, is scheduled for Wednesday, October 5, 2016. Minor releases include new features, usability improvements, and backwards-compatible API improvements. Here's what this means for core patches.

Drupal 8.2.0-beta1 will be released the week of August 3
  • In preparation for the minor release, Drupal 8.2.x will enter a beta phase the week of August 3.
  • Developers and site owners can begin testing the beta.
  • The 8.3.x branch of core will be created, and future feature and API additions will be targeted against that branch instead of 8.2.x.
  • All outstanding issues filed against 8.2.x will be automatically migrated to 8.3.x once it is opened.
  • During the beta phase, core issues will be committed according to the following policy:
    1. Most issues that are allowed for patch releases will be committed to all supported minor branches (8.1.x, 8.2.x, and 8.3.x) for the duration of the beta. Drupal 8.0.x is not supported anymore and changes are not made to that branch.
    2. Issues specific to added 8.2.x functionality, or disruptive changes that have a positive impact outweighing their disruption, will be committed to both 8.2.x and 8.3.x. (Such issues can be moved back to the 8.2.x branch after the automatic migration.)
    3. Most issues that are only allowed in minor releases will be committed to 8.3.x only.
Drupal 8.2.0-rc1 will be released September 7
  • The release candidate phase for the minor release begins on September 7, and starting on that date, the 8.2.x branch will be subject to release candidate restrictions, with only critical fixes and certain other limited changes allowed.
  • September 7 is also the final scheduled patch release window for 8.1.x, and it will not receive further development or support after that date aside from its final security release window on September 21.
  • All outstanding issues filed against 8.1.x will be automatically migrated to 8.2.x after the final 8.1.x patch release. Bug reports after September 7 should be targeted against the 8.2.x branch.
  • Minor versions may include changes to user interfaces, translatable strings, themes, internal APIs like render arrays and controllers, etc. (See the Drupal 8 backwards compatibility and internal API policy for details.) Developers and site owners should test the release candidate to prepare for these changes.
  • 8.3.x will remain open for new development during the 8.2.x release candidate phase.

See the Drupal core release cycle overview, Allowed changes during the Drupal 8 release cycle, and Drupal 8 backwards compatibility and internal API policy for more information.

As a reminder, we have until the start of the beta to add great new features to Drupal 8.2.x. Stabilizing experimental modules (such as Migrate and BigPipe), new features for workflows, and usability and bugfixes are all priorities for 8.2.0. Help with these feature requests and initiatives now for a great Drupal 8.2.0!

Categories: Drupal

ThinkShout: Drupal 8 Routing Tricks for Better Admin URLs

Planet Drupal - 20 July 2016 - 7:30am

We recently launched a new case tracker for foster ed youth designed to improve their educational outcomes in partnership with The National Center for Youth Law (NCYL). The web application replaces their existing platform, Goal Book, which lacked the flexibility they needed to meet their requirements. A web application differs from a website in that a website primarily provides content where a web application primarily provides tools.

The project presented us with an opportunity to do extensive custom development with our favorite new platform, Drupal 8. D8’s many developer experience improvements, including standardized object-oriented development methods, allowed us to meet NCYL’s requirements efficiently and with a level of quality that would have been more difficult on Drupal 7. In addition, we were able to accelerate the release of RedHen CRM on Drupal 8, which lives at the heart of the application managing all of the contacts, organizations, and relationships.

To enhance the utility of the application, we made an early decision to customize every URL a user would interact with. As most of the functionality would revolve around nodes, we wanted to make sure we avoided URLs like /node/256/edit that don’t give the user any indication of which part of the application they’re using.

Implementation

If you wanted to customize URLs in Drupal 7, you could use the Pathauto module. You can still do that in Drupal 8, but D8’s routing system can be coaxed into doing something similar. It works on admin pages, too, which was perfect for NCYL’s needs.

Overriding Existing Node Paths

As an example, let’s say you have a node type specifically for storing information about schools: a School Node. The standard admin path for adding a School Node would be something like this:

/node/add/school

But, add a custom module with route configuration and you can have this:

/school/add

For simplicity, we’ll call our module school.module. The directory structure looks like this:

modules/ school/ school.module school.routing.yml

The route configuration sits inside school.routing.yml and looks like this:

school.add: path: '/school/add' defaults: _controller: '\Drupal\node\Controller\NodeController::add' _title: 'Add School' node_type: 'school' requirements: _node_add_access: 'node:school'

Line by line:

school.add:

This is the name of the route. Route names should be unique and usually start with the name of your module.

path: '/school/add'

The path the route points to. This is the part that comes after your site’s base URL.

_controller: '\Drupal\node\Controller\NodeController::add'

This tells the route to use the NodeController, provided by the Node module. No need for a custom controller here.

_title: 'Add School'

This sets the page title of the node add form.

_node_add_access: 'node:school'

This is an access handler that ensures the user has permission to add a node of type “school.”

Providing a custom path to edit School Nodes is even easier:

school.edit: path: '/school/{node}/edit' defaults: _entity_form: 'node.edit' requirements: node: \d+ _entity_access: 'node.update'

We no longer need to tell the route which controller to use or what type of node we’re using. Drupal 8’s Entity API figures it out using the node ID passed in the URL.

Line by line again:

path: '/school/{node}/edit'

The path now contains a placeholder, {node}, which represents the node ID in the URL.

_entity_form: 'node.edit'

The form we want to use to edit the node.

node: \d+

Some validation to ensure the URL contains the right data type for a node ID. By specifying the regular expression pattern \d+, we are telling Drupal to only use this route when {node} is one or more digits. The route will match a URL like /school/32/edit, but will not match /school/lincoln-high/edit.

_entity_access: 'node.update'

An access handler, ensuring the user has permission to update this node. No need to specify the node type, as we did when adding a node.

Finally, a route for viewing the node:

school.view: path: '/school/{node}' defaults: _controller: '\Drupal\node\Controller\NodeViewController::view' requirements: node: \d+ _entity_access: 'node.view'

Very similar to the node edit route, just with a different path and controller.

For a more thorough explanation of routes and route options not covered here, check out the official docs.

Custom Controllers

What if you want to provide a custom controller for adding a node and still take advantage of Drupal’s permissions system? Routes can do that, too.

Let’s introduce a Teacher Node and an accompanying module.

modules/ school/ teacher/ src/ Controller/ TeacherController.php teacher.module teacher.routing.yml

teacher.routing.yml looks like this:

teacher.add: path: '/teacher/add' defaults: _controller: '\Drupal\teacher\Controller\TeacherController::addTeacher' _title: 'Add Teacher' node_type: 'teacher' requirements: _node_add_access: 'node:teacher'

Very similar to the route we used to add School Nodes, but with a custom controller.

TeacherController.php looks like this:

<?php namespace Drupal\teacher\Controller; use Drupal\node\NodeTypeInterface; class TeacherController extends ControllerBase { public function addTeacher(NodeTypeInterface $node_type) { } }

The addTeacher function is where you would add your custom code for adding Teacher Nodes.

That’s how you can use core Drupal 8 functionality to make your Drupal admin pages a little more user friendly.

Categories: Drupal

WP-like admin

New Drupal Modules - 20 July 2016 - 6:26am

Make the Drupal admin panel look a little bit like Wordpress.
This is useful for showing the aggregated sidebar menu for content managers and using the admin menu (or smth) for admins.

Categories: Drupal

Commerce Open Payment Platform

New Drupal Modules - 20 July 2016 - 2:24am

This module integrates PAY.ON Open Payment Platform with Drupal Commerce, integrating their COPYandPAY widget in Drupal Commerce checkout flow.

Requirements

Commerce Open Payment Platform depends on Drupal Commerce of course, given a strict dependency on commerce_payment sub module.

This module is only available for the Drupal 8 version of Drupal Commerce!

Categories: Drupal

Localize.drupal.org: Looking for translation teams to test the User Guide translation process

Planet Drupal - 20 July 2016 - 2:02am

There has been some amazing work on a User Guide for Drupal 8 for about a year now, and the English version is in pretty good shape -- it's in the stage now of copy editing and image refinement, and it will find its home under drupal.org/documentation. To start the translation process off, we need to figure out a translation workflow that will make sense for translation teams. It doesn't make sense to use the same workflow as is used on https://localize.drupal.org for the short strings that are part of Drupal and contributed modules, themes, and distributions (see https://www.drupal.org/node/2762261 for details) -- the guide is about 100 pages of formatted text prose, not a bunch of short strings.

We are looking for one or two teams initially to start using a proposed process for translation and provide honest feedback to improve the flow. This will help get the guide translated to as many languages as possible eventually.

More information and contact details at https://groups.drupal.org/node/512691

News tags: D8MI newsDrupal planetSite news
Categories: Drupal

wp like admin

New Drupal Modules - 20 July 2016 - 1:44am

Closed due to copyrights infringement.
——
Make the Drupal admin panel look a little bit like Wordpress.
This is useful for showing the aggregated sidebar menu for content managers and using the admin menu (or smth) for admins.

Categories: Drupal

Don't Panic: A blog about Drupal: Adding language id to the body class in Drupal 8

Planet Drupal - 20 July 2016 - 12:06am

When I started making sites with Drupal 8 I missed a special body class that I sometime need for theming as well as other times, and that's the language body class. When making multilingual sites this comes in handy sometimes. For Drupal 7 this was made possible by the Internationalization (i18n) module, but since that module has been moved into core in Drupal (source) that special body-class-adding-thingamajig seems to have vanished.

After facing the need of language id when making this site I started to search for a solution, but came up with very few answers. When I solved it I thought I could make a short entry to spread the knowledge.

My needs

Basically, I had two needs for the language class to be added to my theme. 

  1. I wanted to hide some of the meny items depending on which language the content was presented in. (I later solved this in another way in my theme, but that was the initial need for a body class representing the current language.)
  2. I have two different RSS-feeds, one for posts in English and one for posts in Swedish. To make it work 100%, the path to the feed needed the language id as well. This was the latter need for me, and also the need that made it to the final site.
The theme

The themes I've used for Drupal 8 haven't had the language flag/path, but some themes may have implemented it, so if you have the path in the body class then you probably don't need to read this.

The example I'm going to show you is from the the Bootstrap Clean Blog, which I use for this site, and I will show you the code for adding the language id to it.

The files

In the theme folder of Bootstrap Clean Blog you need to locate two files:

  • bootstrap_clean_blog.theme, which is in the root of the theme folder called bootstrap_clean_blog and
  • html.html.twig which is located in the templates folder.

In bootstrap_clean_blog.theme (or any other .theme-file you might have in the theme you're using/developing) add the following code snippet to it:

function bootstrap_clean_blog_preprocess_html(&$variables) { $language = \Drupal::languageManager()->getCurrentLanguage()->getId(); $variables['language'] = $language; }

If you're using a different theme than Bootstrap Clean Blog, the name of the theme-file is something like XYZ.theme, where XYZ is the name (lowercase with underscores) of the theme. For example, if you're using the Pixture Reloaded theme, the theme-file is called pixture_reloaded.theme.

The code above calls for the language by getCurrentLanguage() and assigns the value to the variable $language. After that the value of $language is assigned to the global variable array $variables['language'].
You could shorten this down to

function bootstrap_clean_blog_preprocess_html(&$variables) { $variables['language'] = \Drupal::languageManager()->getCurrentLanguage()->getId(); }

but I wrote it on two separate rows to make it more clear. The shorter code snippet is quite allright, though, and you can use that in your .theme-file.

Next up: The TWIG-file

Allright, so far we've collected the language and stored it in a global variable. Now it's time to make it visible on the webpage, to print it. This is done via TWIG, a fast and secure template engine that Drupal 8 started using. To print the $variables['language'] you write the following "twig code" in your template where you want it to be printed.

{{ language }}

So, in my example, if we want to print it in the body class, I open up the template html.html.twig in the templates folder of the theme and search for the line where the body is set. It looks like this:

<body{{ attributes.addClass(body_classes) }}>

It prints the following HTML when rendered in a browser:

<body class="user-logged-in path-frontpage">

Though, we can't just add {{ language }} to the body tag since it won't be a part of the {{ attributes.addClass(body_classes) }}. Those are set a couple of lines up, but it's easy to fix it. They look like this:

{% set body_classes = [ logged_in ? 'user-logged-in', not root_path ? 'path-frontpage' : 'path-' ~ root_path|clean_class, node_type ? 'node--type-' ~ node_type|clean_class, ] %}

In i similar way we add:

language ? 'lang-' ~ language|clean_class,

so the final result looks like this:

{% set body_classes = [ logged_in ? 'user-logged-in', not root_path ? 'path-frontpage' : 'path-' ~ root_path|clean_class, node_type ? 'node--type-' ~ node_type|clean_class, language ? 'lang-' ~ language|clean_class, ] %}

Now comes the thing that's very important. After saving your theme-files, you must clear cache for the changes to appear. Click Configuration > Performance > Clear all cache. Then reload the page and check the source code of it et voilà - it works and the source code looks like this:

<body class="user-logged-in path-frontpage lang-en">

That's that. You can now use the class lang-en to distinguish your English pages and on your pages in another language it might look something like this:

<body class="user-logged-in path-node node--type-article lang-sv">

You can also use {{ language }} anywhere else, for example is you have the same need as I, to make a link language-dependant: 

<a href="/{{ language }}/feed">RSS</a>

which gives you the following complete HTML

<a href="/sv/feed">RSS</a>

or

<a href="/en/feed">RSS</a>

if the visitor is on the English part of the site.

Hope this helped you in some way. Happy drupaling!

Categories: Drupal

Miloš Bovan: GSoC ‘16 - Week #9: Mailhandler report

Planet Drupal - 19 July 2016 - 11:13pm
GSoC ‘16 - Week #9: Mailhandler report

During the 8th week of Google Summer of Code 2016, we have started with adding support for posting comments via email. After getting the feedback from my mentors, there was some space to improve proposed solution. The suggestions were accepted and briefly explained below.

Comments in a submodule

As comments are supported through new handler plugin (MailhandlerComment), we decided to move it into a submodule - mailhandler_d8_comment. Following this approach, we can avoid too many dependencies on the main module. The submodule features: Inmail config entity that represents the handler, the plugin class and the related test coverage.

Configurable referenced entity type

With configurable referenced entity type of processed comments, we can support not only node entities but all the other “commentable” entities. In my opinion, this is a nice feature for site administrators in case they want to allow posting comments (for their articles or custom entities) as easy enough as sending an email.

Strict validation

Validation is the important topic in software development in general. In Drupal 8, there is an API made specifically for entity validation - Entity Validation API. It is recommended to use it before saving an entity. However, entity validation does not work as expected in a case of creating comments via API. The referenced entity ID and its bundle were not validated which required us to find a different approach. To accomplish this, we had to implement custom validation checks. They consist of:

  • Entity type validation - entity type is “commentable”

  • Referenced entity ID validation - referenced entity with provided ID actually exists

  • Bundle validation - identified entity bundle supports comments


Last week, besides the improvements made on the comment feature, I was working on the demo module improvements. The pull request has been submitted on Github and available for review. This module serves as an example module to show features of Mailhandler. It creates a sample “Mailhandler” content type (with a body field) and a new user with permissions to add content for “Mailhandler” content type and post comments. The GPG key field of this user was populated  with a sample key (both public and private GPG keys were added to the module) as well. Since last week, the example messages - sample comment and PGP clear-signed, MIME and MIME HTML emails are part of the demo module too. By enabling mailhandler_d8_demo, exploring Mailhandler features becomes very straightforward.

Drupal 8 module demo: Mailhandler from Milos Bovan on Vimeo.

Also, the demo module adds a sample article attached to the front page. The idea is to have a descriptive article about Mailhandler features. Its content will be extended during the “documentation week”. Next week, I will be working on improving overall user experience and user interface of Mailhandler.

 

 

Milos Wed, 07/20/2016 - 08:13 Tags Open source Google Summer of Code Drupal Drupal Planet Add new comment
Categories: Drupal

DrupalCon News: Six Trainings Announced to Level Up your Drupal Skills

Planet Drupal - 19 July 2016 - 2:58pm

This is the first European DrupalCon since Drupal 8 was launched and we are excited to offer six solid trainings that will really help level up your skills. There is a little something for everyone with trainings that span job functions and skill levels.  Check out the training courses that we will be offer ong 26 September from 9:00-17:00 at DrupalCon Dublin.  

Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal