Drupal configuration is normally changed or removed through the configuration import and export process. For example, the process I follow is to make the change in the configuration locally, export the configuration into the source code, deploy the source code to a remote server and import the configuration. Using this mechanism, configuration changes that were exported locally are imported into the site and are ready to use.

There are certain situations where using update hooks to update the configuration is necessary. This means that you would change the configuration in your system directly using code in update hooks, rather than following the export and import process. These situations are rare, but necessary from time to time in order to maintain a consistent configuration on your site.

I recently acquired a Vissles V84 mechanical keyboard and I have spent some time giving it a go. Vissles was founded in 2018 and have a selection of decent looking accessories and devices including wireless chargers, headphones and monitors. The V84 is the second of keyboard that Vissles have created, iterating on the previous design.

The keyboard itself has 84 keys and is a 75% ANSI layout, this is also called tenkeyless as it is a normal keyboard without the keypad. This keyboard moves a few of the keys around in order to fill the entire surface of the board with keys, rather than separate out the arrow and home/end keys. The compact design gives the keyboard a slim look, but it doesn't feel cramped or small to use.

When copying a database from your production environment to your dev or local setup you should probably be sanitising it. This means to remove all user identifiable information from the database. You would assume that this means removing passwords and email addresses, but it also includes any fields you might have added to the user that might contain information. Things like name, address, company or even gender should all be sanitised.

Sanitisation is important from a data security point of view as you do not want any user data leaking out from your development (or testing) platforms. You want your users to have confidence in your abilities to protect their data and sanitisation allows you to keep their user data only on your production environment (and any production backups).

If you are using Drupal 9 and Drush then you can sanitise your data easily using the sql:sanitize command. This comes with Drush and should be available out of the box.

Picture the scene, it's 2010, you're a young web developer working in a satellite office of a fast paced digital agency. The work is interesting, but normally quite stressful as there are tight deadlines and high expectations on delivering good work. There is a lot going on so you tend to finish one website and jump onto the next. The company you work for has a history of firing people and making people redundant, especially in the satellite office you work at. Low morale, a culture of blame, and absolutely zero investment in people means that there is very little enthusiasm for the work from anyone. The economy is still recovering from the collapse of the banking system from a couple of years before. You have a young family at home and so you'll put up with a lot of poor working conditions to ensure a pay cheque every month.

I have been using Git for a number of years and I can remember feeling quite daunted at the complexity of some of the commands I saw on the internet. When I started using Git on a daily basis I soon realised that the basics were quite simple and the complexity only lay further down the road with commands like cherry-pick or rebase.

Whilst Git does sometimes make me scratch my head, it is never as bad as the days of SVN where I would have a notepad of 'fix' commands that I would copy and paste into my terminal to solve random problems. I usually didn't even know what the problems were, just that this command fixed things so I could continue on and not lose work.

Drupal Views is a powerful module. The ability to generate lists of things in Drupal means that it is used everywhere. It even has a powerful plugin system that allows other modules to interface with it and create more functionality.

With multilingual sites there is a common issue I come across quite a lot that is quite easy to fix. A View will be created (usually via the Views wizard) that is intended to list a type of content. When an item of content is translated the content is duplicated in the View and you end up with a single list containing both translations of a single content item.

The Luhn algorithm was created by Hans Peter Luhn and is a way of creating a simple checksum for a number. This algorithm, also known as the mod 10 algorithm, is used in a wide variety of applications but is commonly associated with credit card numbers.

If you look at the numbers on the front of your credit card the last digit on the right is the checksum. An algorithm is done on the other numbers and if the checksum is the same then the number is considered valid.

Outside of credit card numbers, the Luhn algorithm can be used to create a checksum on any number that you want to store. It is especially handy when you want to give users a number that they will be hand typing into a computer. The checksum helps spot any errors in typing in the number before that number is processed. The good thing about the Luhn algorithm is that it doesn't matter how long the number is so it will work with any kind of digit sequence.

Getting a list of content types out of a Drupal 9 site is useful in a few situations. Mostly, I find that when creating a service of some kind that I will also create an administration form for that service to allow it to be restricted to certain content types. This list can be saved to configuration so that when the service is run it only effects certain content types, based on the saved configuration.

To get a an array containing a list of the content types on a Drupal site you can use the following code.