Drupal's cache system is robust, feature full and extensible. It can be used to cache small blocks of rendered output or the results of more complex calculations. The cache can be stored in a for the page request, in a database or in a different cache system.
From the pages of 'crazy things you can do with Drupal 8' comes this idea that I recently had to implement on a site. This was on a site that had implemented translations, but they needed something a little extra. The central idea was that if you visited a page on the site in a particular language, and that language didn't exist, then to try and give the user a similar language.
For a long time the drupal_set_message() function has been a mainstay of Drupal development. You can use this function to print a message or an error response to a user. This is useful to do as it can be done almost anywhere before the final page rendering functions and will be printed into the same area of a Drupal page.
I recently wrote a post about setting up a multi-site configuration setup using the Configuration Split module. That post was written after I did research into how to set up configuration splits and use them to create multi-site setups in Drupal. One thing I realised when doing that research was that although it's quite easy to get setup with that kind of setup, it's also easy to get it wrong and create a setup that really doesn't work.
Setting up a Drupal 8 site for a multi-site environment with a common configuration isn't too hard, it just requires a little bit of forethought and some planning to get things right. You need to have a default configuration in mind, and then think about how each site can override this configuration in different ways. I have seen it done wrong a few times recently and once you go down the wrong path, getting things back in line again can be a difficult.
When developing sites in Drupal 7 I found the hook_init() hook was a good way of quickly testing certain things in code. By adding little blocks of code it was possible to build complex SQL queries, inspect internal configuration, or even test complex node interactions.
The Shield module prevents access to a Drupal site by putting a Apache authentication system across the entire website. This means that to access the site you need a username and password.
This is useful in a number of different situations, but I use it most for protecting dev and staging sites from access. It's not the most complex authentication system in the world, but it's enough to prevent the embarrassment caused by having staging sites being spidered by search engines.
Drupal 8's comment system has the ability to be threaded so that users can reply directly to other users comments and create threads of conversation. I have always found this difficult to use and difficult to read so I wanted to turn it off when I set up this site. The only issue I had was I could turn off the threading but couldn't alter the ordering of the comments.
The Search API Solr Search module has a bunch of controls for boosting certain fields. This allows you to give more weight (i.e. boost) to the title and less weight to the body, which means that when a search term appears in the title of a page it has more weight than a page that only has the term in the body. This weight value is ultimately used to calculate the score of the page and this directly effects the ordering of results.
I was struggling with a problem on a Drupal 8 project that was in development recently where a block used to show information to anonymous users was cached for the first user who saw it. This meant that the special message meant for the first user was then being seen by all subsequent users who visited that page. This only happened when page caching was turned on, but as it's best practice to do that I didn't want to turn that off just to solve one little problem.