Strings and arrays can be manipulated in a number of ways in python. Splitting a string or an array into sections can be done using the section slicing that is built into the core python syntax and uses the colon (:) symbol.
Generating a simple array in python is straightforward, the following creates an array of 9 elements.
an_array = [1,2,3,4,5,6,7,8,9]
To grab a particular element of the array you can use the simplest section slicing syntax. The number in the square brackets represents the position of the item to be returned. Remember that the counting starts at 0, so using 1 will return the item from the "second" position.
When starting out learning Python you will probably start by looking at the command line a lot. This is understandable as it's important to learn about variables, conditionals and loops and the command line is the best way to start out with the language.
I have always found it useful to quickly introduce graphical user interfaces when learning programming as it allows people learning programming to have something they can engage with. Being able to see the output of their program in real, tangible things that they can interact with.
There are a couple of different libraries in Python that can be used to create user interfaces, and perhaps the first one Python developers tend to learn is Tkinter or the "Tk interface" module. This is a Python binding to the Tcl/Tk toolkit to create graphical user interface.
If you've been building websites sites for a while you will realise that no site lives in isolation. Almost every site you build integrates with some form of API, and this is especially the case for the more enterprise sites where data is often synchronised back to a CRM system or similar. Drupal's hook and service architecture means that you can easily build integration points to that API to pull in data.
Pulling in data from an API into a Drupal site means installing an off the shelf module or creating a custom module to provide the integration. What route you go for depends on the integration, but for enterprise sites the API is quite often very custom to the business. I have even seen APIs being built at the same time as the site that it needs to integrate with, which is especially the case for startups and new businesses.
Drupal 8 and 9 are built upon services, with many parts of the system available through dependency injection, so it's important to understand the concepts. Services are a way to wrap objects and use dependency injection to produce a common interface. They are powerful and are used all over Drupal to do pretty much everything.
They can, however, be a little difficult for newcomers to the system to understand, especially if they are coming from Drupal 7 or other non-object oriented systems. When you look at some Drupal source code you are likely to see objects being created out of apparent thin air. It's a little hard to know where they come from if you aren't used to the how they work.
PHP has a built in debugging and testing tool called assertions, which is essentially the assert() function and a few configuration options.
With this feature you can add additional checks to your application whilst you are developing it so that when you deploy to production you can be sure that things will run correctly. It is simple to run and allows you to embed testing code within your production code without having an adverse effect on performance.
Naming things is hard and there are a lot of things that you can name when configuring a Drupal site. Picking the right machine names for the different parts of Drupal can make your life easy in the long run. Changing labels is simply a case of tweaking the label in the interface, or through configuration updates. The issue is that once you decide on a machine name for something in Drupal it's pretty much set in stone forever.
The machine names you pick are often used in database tables, paths, interface elements and pretty much anywhere it is used. Changing entity or field machine names at a later date is difficult and can mean writing complex code or using migrations to achieve.
I have previously talked about configuring a Drupal site to authenticate against a remote SimpleSAMLphp install, but as Drupal is an excellent user management system I wanted to turn it around and use Drupal as the identity provider. This means that Drupal would allow users to log into other systems using their Drupal username and password by leveraging the power of SimpleSAMLphp.
This can be accomplished by wrapping the Drupal site and SimpleSAMLphp together along with a couple of modules to power the communication between the two systems.
The same terms apply as I described in the previous post, but to reiterate their meaning in this context I will go over them again.
I have previously talked about installing SimpleSAMLphp using composer, so the next step is setting up the system to actually provide authentication against a SimpleSAMLphp system. As I spend a lot of time using Drupal I wanted to set up the authentication with Drupal and SimpleSAMLphp in order to see how things worked.
First, let's define a couple of terms that are important to this setup.
SP - Service Provider - This is the system that users are trying to log into, which in this setup is Drupal. The Drupal site is providing a 'service' and as such users want to authenticate with it. Service providers will generally create a local user to track the user within the site, although that's not always the case.