Using hook_views_post_render() Drupal module developers can change the render array representation of a View before it gets displayed. You can use this to modify the computed HTML of a view just before it gets printed. This hook is similar to using a preprocess function for a template file, but in this case you have access to the whole render tree, not just the specific leaf covered by the template file you're preprocessing.

This hooks gets called after the Views object has been through the render process, and all the different configured displays and formatters have been applied, producing a render array representation of the results of the view. This hook receives an $output parameter which contains the render array, and only changes made directly to the $ouput variable will have any effect. This hook is the last chance to make changes to the render array before it is converted to markup.

You can use hook_views_post_render() to change #cache properties for the View, and to do things like add CSS classes to rows, and change the page title.

In this tutorial we'll:

• Learn how to alter a view's rendered output right after the Views object completes the render phase of the build cycle.
• Use hook_views_post_render() to change the title of the view's display

By the end of this tutorial you should know how to alter the render array generated by a View prior to it being passed to the theme layer and converted to HTML.

As a theme developer you can extend an existing asset library to include custom CSS and/or JavaScript from your theme. This is useful when you want to add styles or behaviors to components provided by Drupal core or another module.

Sometimes there are CSS or JavaScript asset libraries attached to the page by Drupal core, a contributed module, or another theme, that do something you don't like, and you want to change it or even exclude it all together. There are a couple of different ways that themes can override, alter, or extend, an existing asset library in order to modify the CSS and JavaScript that get attached the page by other code belonging to another theme or module.

In this tutorial we'll learn how to:

• Extend an existing asset library using libraries-extend, so that our custom CSS and JavaScript is included whenever that library is used.
• Override an existing asset library using libraries-override, to alter the definition of the library, and replace or exclude individual assets (or the entire library).

By the end of this tutorial you should be able to use your custom theme to override, extend, or alter any of the asset libraries added to the page by another theme or module.

In their simplest form layout plugins in Drupal Layout Builder define the part of the content output that can't be changed. For example a three column layout will consist of three equal columns every time an editor decides to use it as the layout section. The editor can place whatever they want into the three columns. But they can not change the overall layout. This restricts editorial capabilities of using layout plugins since in real life a three column layout may need to consist of a wider middle column and narrower side columns, allow for column headings, or other customizations.

This flexibility is accomplished by creating, and exposing, configuration options for layout plugins in Drupal's Layout Builder. In more advanced cases, we can take this flexibility further by exposing an interface editors to dynamically define layout plugins.

In this tutorial we'll:

• Learn how to use custom PHP classes in the layout plugin annotation
• Learn what annotations properties can be used for custom layout declaration
• Define the concept of derivatives and outline scenarios for using them
• How to declare static single layouts using YAML format

By the end of this tutorial you'll learn advanced ways of declaring configurable custom layout plugins.

The Layout Builder Styles module extends the Drupal core Layout Builder UI to add the ability for editors to apply custom CSS classes to the blocks and sections that make up a layout. This gives layout editors more control over the look and feel of elements within a layout. It's especially useful when using Drupal's Layout Builder in conjunction with a design system like Bootstrap, Material UI, or your own predefined utility classes.

The module allows site builders to define new styles. Then, when placing a block into a layout, if there are any styles available for the block type, the user is presented with a select list where they can choose one or more to apply. When a style is applied, any CSS classes associated with the style are added to the markup. Also, a new style-specific theme hook suggestion is added to the block to allow for further customization.

In this tutorial we'll:

• Install and configure the Drupal Layout Builder Styles module
• Learn how to define new styles
• Learn how anyone editing a layout can apply the styles we defined to a block or section in the layout to change the UX

By the end of this tutorial, you should be able to use the Layout Builder Styles module to allow editors to add predefined styles to existing layouts and blocks without writing any code.

Drupal's Form API is a set of interfaces, utility classes, and conventions that when combined together allow module developers to create forms that collect, validate, and process user-submitted data. The Form API is closely related to the Render API. It uses Render Arrays to define forms, and adds an additional level of workflow and processing to enhance the Render API with some features specific to handling forms.

Given that forms are one of the primary means of interacting with a Drupal site via the UI, understanding how the Form API works is a critical part of learning to develop modules for Drupal. While you may not need to know all the nitty-gritty details, every Drupal module developer is likely to encounter aspects of the Form API at some point. Understanding the basics should be considered required knowledge.

Theme developers are also likely to encounter some aspects of the Form API, as forms are inherently part of the look and feel of a site. Knowing how to make changes to the UX of a form is an important skill.

In this tutorial we'll:

• Describe what forms are and how they are used in Drupal
• Explain the relationship between Form API and the Render API
• List some of the benefits of using the Form API over generic HTML forms

By the end of this tutorial you should have a solid understanding of the role of the Form API in Drupal.

Managing a Drupal application with Composer requires a few modifications to Composer's default behavior. For instance, Drupal expects that specialized packages called "modules" be downloaded to modules/contrib rather than Composer's default vendor directory.

Additionally, it is common practice in the Drupal community to modify contributed projects with patches from Drupal.org. How do we incorporate Drupal-specific practices like these into a Composer workflow?

In this tutorial we will:

• Address all of the Drupal-specific configuration necessary to manage a Drupal application using Composer

By the end of this tutorial you should know how to configure Composer to work with Drupal, and drupal.org.

Administration and maintenance of Drupal websites consists of many tasks that can both be performed via the command line, and automated, with Drush. Using Drush's site and environment administration commands you can run database updates, check an environment's status, clear (rebuild) the cache, perform Cron-related operations, and manage users. These tasks are repetitive, often require many steps in the UI, and may be tedious in the long run. Learning to execute them with Drush can save you time and allows for more automation of common tasks.

In this tutorial we'll:

• Use Drush to check a site's status
• Learn how to perform database updates with Drush
• Clear the Drupal cache with Drush
• Use Drush to execute Cron tasks for a Drupal site
• Learn how to use Drush to login to a site as any user, and manage existing users

By the end of this tutorial you'll be able to perform many common Drupal environment and administration tasks from the command line with Drush. We're not going to cover all of the environment management commands in this tutorial, just some of the more popular ones. We encourage you to explore further on your own.

This tutorial will help you understand the complete life cycle of a Drupal form: receiving the request from a browser, displaying a page with a form, rendering the form as HTML, handling the submitted form, validating input, handling errors, and processing data. We'll point out the common places that module developers might want to inject additional functionality into the process. And we'll link to tutorials with more details about each integration point in a form's life cycle.

In this tutorial, we'll:

• List the steps of the life cycle of a Drupal form.
• Describe how Drupal determines which form to display, and which form handles an HTTP POST request.
• Understand the role of FormStateInterface in the life cycle of a form.

By the end of this tutorial, you should have a solid understanding of the life cycle of a form within Drupal.

The #table render element type is a powerful way to output an array of rows and columns as an HTML table. It supports all the features of a standard HTML <table> element like headers, captions, and column groups. Data to be displayed in the table can be an array of simple string values, or an array of render arrays where each sub element is a row with columns as child elements. In addition, when used in the context of a form, tables can be made into a multiple select widget, or have drag-and-drop reordering of rows enabled. Whether you just want to display a set of tabular data, or you provide your users with a complex form element for reordering and nesting items inside a menu tree, it can all be done with the #table element.

In this tutorial we'll:

• Look at outputting simple strings as a table
• Provide definitions for all the various properties that can be used to define a table element
• Demonstrate how to use the #tableselect and #tabledrag options to create complex form widgets

By the end of this tutorial you should be able to create HTML tables in all their various permutations as part of a render array.

Formatting standards cover things like the use of whitespace, how to format control structures, and other aspects that affect your code's appearance and format.

In this tutorial we’ll talk specifically about standards regarding formatting. This is by no means an exhaustive list of PHP syntax rules, but rather is focused on formatting standards for Drupal.

By the end of this tutorial you'll know about the most common Drupal code formatting standards as well as where to find more information when questions arise.

Translations have their own special functions in both Drupal 7 and 8, and there are some rules for standardizing how they are used that make things clearer for everyone.

In this tutorial we'll look at:

• When to use, and when not to use, translation utilities to output translatable strings
• How placeholders work in translatable strings
• Tips for creating links inside of translatable strings

By the end of this tutorial you should know when, and how, to make strings in your code translatable using Drupal's translation utility functions.

This tutorial teaches you everything you need to know about using the tutorials on Drupalize.Me.

Standardized documentation is crucial to a project, whether it is just you or an entire team working on it. In this tutorial we're going to look at:

• Standards for @docblock comments
• Standards for inline comments
• Why standards for documentation and comments are as important as standards for the rest of your code.

By the end of this tutorial you'll know how to add inline documentation for all the PHP code that you write for Drupal.