I'm working on a project now in which a particular role is restricted to a single text format. I was surprised to find that (even when a role is restricted to a single text format) the 'About text formats' link still shows.

There are many different ways to include assets in Drupal 8, and there were probably just as many or more ways in Drupal 7, but the recommended method in Drupal 8 is to use your theme's theme.libraries.yml file. I'm going to explain a method that I have been using to include css and js libraries and how we get them into version control. This is the best method, for our use case(s), that I have discovered so far, but I'm sure there are many other ways and I would be very excited to hear anyone's opinions or suggestions.

At the university that I currently work at, one of the Webteam's responsibilities is managing the content of many of the sites we develop and maintain. This can sometimes turn into a huge time sink since requests are constantly streaming in. We have a student worker that can handle most of these tasks, but there are occasionally content tasks that require a better understanding of Drupal or are simply a waste of her time.

I ran into a recent surprise while working with some content editors on an academic catalog website. I sat down with them to walk through some issues they experienced with speciic content editing tasks. To my surprise, when they went into the Edit view, ex. /node/1/edit, the university theme was still being used instead of the admin theme (I think I was using Seven or Admininal). I was pretty sure that I clicked the checkbox to use the admin theme on content editing pages on the Admin > Appearance page. Let me paste a screenshot below.

Features allows you to bundle entities, and their configurations, into a feature module that is written to code. So, what is so great about that? Can't you accomplish the same functionality by building out your views, content types, etc. through the Drupal admin UI. Yes, you can, but all of the entities and configuration will be saved in the database, as opposed to in code. Saving your entities and configuration to code is an immense benefit, if not necessary, for Drupal sites that are deployed across multiple environments, and even more if there are multiple developers working on the site.

I first published this blog to jordanpagewhite.github.io around January 10, 2016. I started this blog for a lot of reasons, but some of the main reasons are (in no particular order):

I am developing a Drupal 8 site right to manage scholarships and scholarship applications at the university. I wanted to add a bunch of custom fields to User and group them with the field_group module, but field_group generated an error that caused White Screen of Death (WSOD) upon adding a field group. I reported the error to the module maintainer, but he seemed to denounce the possibility that it generated an error in his response to me.