Whilst searching for an answer to a problem the other day I found a comment that details a command that prints out all of the FieldWidgets available in Drupal 8. This is useful if you are looking for all of the field widget classes in Drupal8.
Here is the command:
I perform a lot of Drupal updates, and they mostly go very well. The code updates without incident and the database updates apply whatever updates they need without a hitch. Every now and then, however, I will come across a project that hasn't received updates in a while, which means there are a lot of database updates to run through.
Having Drupal run 100+ database updates across modules and core can be a bit problematic. Some modules will require core updates to happen first, and when this happens out of order the database update update fails spectacularly.
Drupal's hook system allows modules to interact with various parts of a Drupal application and is part of the power of the application.
One common issue I have found is altering things that have been added by other modules during the hooks process. For example, a hook might be called that involves gathering data from one or more modules. If you need to intercept this configuration there is no guarantee that your module will be called after the module you are trying to intercept.
This problem came out of a recent project I was working on. I had to perform a bunch of API lookups on behalf of a user that could take a minute or so to complete. The results of the API lookups were cached and so once it was done the site would be very quick, unfortunately the initial API lookup slowed down the page load quite considerably so this created a problem.
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.
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.