Category Archives: Drupal

Adding a Javascript library to Drupal 8

This evening at our local Drupal meetup, in Bellingham, WA,  Trebor and I dug into Javascript in Drupal 8. In Drupal 7 we use drupal_add_js() hooks. Drupal 8 changed this and several other aspects of how one adds JS to a site.

The move away from drupal_add_js() is well documented in the change record, back on December 4th, 2014. Though adding JS now takes a little more work, the pay-off is worth it. As I understand the rendering system, helpfully drawn out in this image, every entity is now cacheable, per entity. This means if one entity changes on a page, the whole page does not need to have the cache flushed, just that one entity will reload.

I messed around with the core Bartik theme to get this working. The end result is having the search box become sticky on very long posts, so as you scroll down, the search box sticks with you in the upper left.

We modify two files and create one brand new one.

Step 1:

Modify bartik.libraries.yml found in /core/themes/bartik/bartik.libraries.yml. Within that file add the following code at the bottom.

stickyjs:
  version: 1.0.0
  js:
    sticky/bartik.js: {}
    sticky/jquery.sticky.js: {}
  dependencies:
    - core/jquery

The first line declares to Drupal how we can access the components using the new attach_library function. You can call it whatever you want, I chose to name it the same as the library I want to add.

I don’t know what the version is for, but it seems to need it. You can put whatever you want where 1.0.0 is. Then you tell Drupal that stickyjs has a few javascript files and a dependency on jquery. What you are adding here to the .yml file is what used to live in the .info file for a module or theme. You can see where this is roughly outlined within the following Defining a Library section on drupal.org.

Step 2:

Modify this file: /core/themes/bartik/templates/block–search-form-block.html.twig

Here we need to actually tell Drupal to load this library, when this block is present on the page being requested.

{% block content %}
    {{attach_library('bartik/stickyjs')}}
  <div{{ content_attributes.addClass('content', 'container-inline') }}>
    {{ parent() }}
  </div>
{% endblock %}

The file in unmodified form does not include the second line {{attach_library()}}. What attach_library() does is load the file when this search block is present. The argument in the function is the theme or module name, in this case, bartik. Then the / name you used in the yml file to tell Drupal about your javascript. We end up with bartik/stickyjs.

Step 3:

Download the JS library and add in a .js file that we can invoke with Drupal behavior. For this example we used the awesome stickyjs jquery plugin.

We extracted the download to /core/themes/bartik/sticky. We then created a new file in there named bartik.js, which we defined earlier in the .yml file. I dropped in this snippet of code to invoke the sticky js plugin.

(function ($) {
  Drupal.behaviors.bartik = {
    attach: function (context, settings) {
     $("#block-bartik-search").sticky({topSpacing:60});
    }
  };
})(jQuery);

This is a fairly standard Drupal 7 looking behavior, so not much to see here. This will fire when the page with the search block loads.

Step 4:

Clear the cache by going to your website then to admin/config/development/performance and click the big Clear all Caches button. Go to a page that has the search box on it, add some gibberish to the post, so it is lengthy, and then when you save and the page reloads you will see the search box sticking to the top of the page as you scroll down. On my test site it looks like this:

A nearly blank webpage with a search box in the upper left corner.

Conclusion:

At first it seems like a lot more work but I can see how this opens up a lot of flexibility for developers. Once you get the hang of .yml files replacing .info files it begins to make a bit more sense. I think this is well worth it for the improved cache capabilities. I look forward to using D8 in production.

Caveat: I know you don’t modify core. I did it this way as I was exploring the D8 core codebase. If you want to do the above in production, do it in your own theme, not core.

Sample code: Replace your core bartik with this to see this completed example in action.

bartik-with-stickyjs

Sessions I find most intriguing

DrupalCon Los Angeles kicks off in a few days. I am lucky to have an opportunity to partake. I’ll be sprinting Sunday and Friday. The higher-ed summit should be great and I am humbly leading a few table discussions at that.

Here are sessions I find intriguing, the ones with an asterix are where I’ll most likely be.

Sunday

  • Sprints

Monday

Tuesday

Wednesday

Thursday

Friday

The aegir logo, a wave with the word aegir to the right of the wave.

Aegir site migration failure and success – say it ain’t so!

When using Aegir to upgrade production websites I follow a method very similar to the one outlined by Omege8cc – Safe Workflow

The safe workflow technique is nice as it lets you migrate sites into production without having to bring your live site down to basically test the migration. Occasionally, during the test migration Aegir reports that the migration has failed. However, if I look at my files it has successfully moved the entire site to the new platform but could not delete the settings.php file from the old platform and site. The important thing to check is that everything is now actually on your intended platform and is properly setup, vhost files, files dir, settings.php, etc…

If everything is peachy, Aegir did everything besides deleting the old settings.php file correctly. So, to clean up your Aegir interface you first want to delete the site that failed not using the delete button but by clicking the edit tab on the site and then in the URL changing the word edit to delete, and press enter. Confirm the deletion of the site.

Then on the server, delete the remaining old files off of the original platform. On the new platform navigate to your recently migrated site and change the file permissions on settings.php to 664. When you do your final migration Aegir will set the permissions back to the proper settings.

Next, go to the platform you migrated your site onto and verify the platform. Aegir will pick up the site, import it and you will be ready to finish your migrations.