DEV Community: oskar calvo

Añadir un capo de tipo hora y minutos en un formulario

oskar calvo — Wed, 01 Apr 2026 11:09:36 +0000

Una de las cosas que más me gusta es el FORM API de Drupal.

Hoy vamos a ver como añadir un campo para recoger únicamente horas y minutos,

La forma de hacerlo es, a partir de la versión 11.30 de Drupal la siguiente.

    $form['datetime_time_only'] = [
      '#type' => 'datetime',
      '#date_date_element' => 'none',
      '#date_time_element' => 'time',
      '#date_time_format' => 'H:i',
    ];

Si estamos trabajando en versiones anteriores a la 11.30 la forma que he encontrado de hacerlo es con el módulo duration_field el cual define un Element para que podamos añadir a nuestros formularios un campo de tipo time

 // Usage example:
 // @code
 $form['duration'] = [
   '#type' => 'duration',
   '#title' => $this->t('Duration),
   // Only 15 minute increments.
   '#date_increment' => 900,
   // Hide seconds.
   '#granularity' => 'y:m:d:h:i',
   // Require hours and minutes.
   '#required_elements' => 'h:i',
 ];

Comento esto porque algunos modelos LLM no saben las diferentes opciones que existen y sugieren paparruchas.

Drupal Canvas, creación de páginas I

oskar calvo — Wed, 24 Dec 2025 13:17:49 +0000

Vamos con la creación de una página, para ello simplemente le damos a crear una página en el botón + Add Page que nos llevará a una página como esta:

Importante, en mi caso he añadido dos idiomas a la web, con la ruta https://drupalcms.ddev.site/en/canvas/editor/canvas_page/12 y https://drupalcms.ddev.site/es/canvas/editor/canvas_page/12 no me funciona Canvas (tengo que investigar esto), pero con la ruta https://drupalcms.ddev.site/canvas/editor/canvas_page/12 vemos la página lista para crear contenido.

Esta página recuerda en su estructura a la de Gutenberg de Wordpress

Lateral izquierdo

En el lateral izquierdo tenemos el menú principal, con los siguientes elementos en orden:

Library
Layers
Code
Pages
Templates

Library

Esta opción del menú nos pinta todos los componentes que tenemos habilitados* en nuestro portal web y también nos permite elegir entre patrones si tenemos creado alguno.

Layers

Esta opción nos permite definir con que capa de la página queremos trabajar, en e caso de Byte existen tres capas, Contenido, cabecera, y pie.

También muestra los diferentes componentes que se están usando en cada capa en una estructura jerárquica, y en permite mover algunos componentes arriba y abajo.

Code

Esta opción nos permite añadir componentes mediante código, a esto e dedicaremos una entrada en exclusiva de esta serie.

Pages

Esta opción nos muestra el listado de todas las páginas que existen, recordemos, páginas de Canvas.

Templates

Esta opción nos permite usar Canvas para personalizar los view mode que tenemos definidos de tipos de nodos.

En caso de que se quiera usar un view mode concreto tenemos que ver si está activado en el nodo para poder usarlo.

NOTA: Lo que he visto por ahora con los nodos es que si añadimos un componente a un tipo de nodo (por ejemplo de blog) en Canvas afecta a todos los nodos, no he visto una forma para que un componente se aplique a un único nodo, estoy preguntando y mirando esto, porque si esto no se puede realizar sería algo a tener en cuenta si queremos elegir entre Layout Builder y Canvas.

Lateral derecho

En el lateral derecho vemos las opciones de configuración del componente que se está trabando. Cuando se entra a la página lo que se muestra son los valores básicos de la página: título, URL, SEO Settings, Media, Page Title (meta-atributos), Meta Description.

Drupal Canvas, Adminstración de contenido

oskar calvo — Wed, 24 Dec 2025 12:08:50 +0000

Este artículo los escribo con una instalación de DrupalCMS beta 2.x y template de instalación "Byte".

Cuando hemos arrancado lo primero que he visto es que las páginas de canvas son independientes de la sección de contenido que solemos ver en Drupal.

Pages nos pinta el listado de "paginas" (no confundir con "basic pages") de Canvas, y el enlace CMS nos pinta la administración clasica de /admin/content de Drupal.

Drupal CMS

Como se puede ver en las imágenes la administración (publicar/despublicar/borrar) para las páginas de Canvas es parecida, las operaciones que podemos hacer son borrar/ver/editar, y crear una página nueva además de buscar por el título de la página y filtrar por publicadas/despublicadas.

Drupal Canvas, introducción

oskar calvo — Wed, 24 Dec 2025 11:57:09 +0000

Canvas es un módulo añadido a Drupal que permite la construcción de páginas webs simplemente agarrando y soltando elementos y luego personalizando dichos elementos.

Uno de los puntos importantes respecto a otros módulos de Drupal que permitían construir páginas es que esta vez Canvas no viene de desarrolladores de backend dando funcionalidades a creadores de contenido/diseñadores, sino que ha sido un trabajo de análisis de que había en el mercado, ver como funcionaba, coger lo mejor de todo aquello que se ha analizado, hablar con diseñadores y creadores de contenido y luego sacar las funcionalidades que se quieren implementar, vamos que se ha pensando más como un producto con los diseñadores y creadores de contenido como público objetivo.

Que nadie me mal interprete, no digo que Layout Builder, Paragraphs, Panels, etc... no fueran buenos productos, pero mi opinión personal es que en la comunidad de Drupal durante muchos años hemos pensado en sacar módulos/productos pensados para desarrolladores backend/hardcoder y no tanto herramientas sencillas de usar para diseñadores o creadores de contenidos, y esto es precisamente lo que hizo que Wordpress triunfase donde no lo hizo Drupal, ellos sacaron un producto pensado para diseñadores o personas sin conocimientos y sin ganas de leerse un libro enorme.

Con Canvas Drupal rompe esa dinámica y tenemos una herramienta pensada para ese tipo de usuarios.

Añadir programáticamente un campo de tipo cshs a un formulario.

oskar calvo — Tue, 11 Nov 2025 11:20:42 +0000

El módulo Client-side Hierarchical Select de Drupal permite elegir un elemento de un select cuando tenemos una jerarquía en árbol con múltiples valores.

(Fuente de la foto: https://www.drupal.org/project/cshs)

Añadir este widget a las entidades de contenido es sencillo, simplemente en la pestaña de "Administrar la visualización del formulario" podemos elegir que widget queremos usar y si tenemos activado el módulo Cshs lo veremos para los campos de taxonomías.

El problema es que los formularios creados a medida para añadir funcionalidades, o los formularios de entidades de configuración no tienen la opción de "Administrar la visualización del formulario".

En este caso muestro como usando el módulo Hux añado un hook_form_alter para añadir un campo adicional a la entidad que trae el módulo simplenews para poder categorizar los tipos de boletines que se crean usando un vocabulario ya definido en el proyecto.


  /**
   * Implement hook_form_alter().
   */
  #[Alter('form')]
  public function addThematicFieldToNewsletters(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) : void {

        if (in_array($form_id, ['simplenews_newsletter_edit_form', 'simplenews_newsletter_add_form'], TRUE)) {
          $form['container_thematics'] = [
            '#type' => 'fieldset',
            '#title' => $this->t('Thematics'),
          ];

          $form['container_thematics']['thematics'] = [
            '#type' => 'cshs',
            '#title' => $this->t('Select the thematic'),
            '#options' => $this->buildCshsOptions('thematics'),
            '#weight' => 100,
                /** @var \Drupal\simplenews\Entity\Newsletter $newsletter */
            '#default_value' => $form_state->getFormObject()->getEntity()->getThirdPartySetting('gobcan_newsletters', 'thematics', NULL),

          ];

            // Añadir entity builder para procesar los third party settings
            $form['#entity_builders'][] = [$this, 'buildThematicsEntity'];
        }

  }

Para definir correctamente el widget de formulario de Cshs tenemos que definir el campo del formulario como ´'#type' => 'cshs',´ , además el array de ´#Options´ no sirve un array de tipo clave valor, sino que tiene que tener una estructura concreta para que Cshs pueda procesarlo, por eso se ha creado el método ´buildCshsOptions()´.


    /**
     * Entity builder para las temáticas.
     */
    public function buildThematicsEntity($entity_type, \Drupal\simplenews\Entity\Newsletter $newsletter, &$form, \Drupal\Core\Form\FormStateInterface $form_state) : void {
      $thematics_value = $form_state->getValue('thematics');
      $newsletter->setThirdPartySetting($module_name, 'thematics', $thematics_value);
    }

Esta funciión es la función necesaria para guardar los valores en la entidad como configuraciones de terceros.

  private function buildCshsOptions(string $vocabulary): array {

    $term_options = [];
    $terms = $this->entityTypeManager
      ->getStorage('taxonomy_term')
      ->loadTree($vocabulary,0,NULL,TRUE);

    foreach ($terms as $term) {
      $termId = $term->id();
      if($term->parent->target_id) {
        $term_options[$termId] = new CshsOption($term->getName(),$term->parent->target_id);
      } else {
        $term_options[$termId] = new CshsOption($term->getName());
      }
    }

        return $term_options;
  }

En este método construimos la estructura del array que necesita Cshs para poder construir el widget correcto, usamos la clase CshsOption que trae el módulo para hacerlo.

El código es de David Mudie (dmudie) lo saqué de esta Issue en Drupal.org

PHP 8.5 nos trae closures en constantes de clases.

oskar calvo — Tue, 23 Sep 2025 21:52:15 +0000

La verdad es que esta nueva funcionalidad me deja frío, y es añadir una constante que puede ejecutar una función anónima no termina de convencerme.

class Example {
    public const VALIDATOR = static function($value) {
        return !empty($value);
    };
}

(fuente del código: https://pixicstudio.medium.com/php-8-5-new-developer-features-f9617311c590)
Para resolver eso mismo podemos crear un functor o podemos usar también un trait, o incluso una clase con un método estático (pero mejor los traits).

Un functor al ser una clase se puede inyectar sin problemas en otras clases y un trait está precisamente pensado para ser usado dentro de otras clases.

interface Functor
{
    public function fmap(callable $fn): Functor
}

class Arr implements Functor
{
    protected $items;

    public function __construct(array $items)
    {
        $this->items = $items;
    }

    public function fmap(callable $fn): Functor
    {
        return new static(array_map($fn, $this->items));
    }
}

(fuente del código: https://www.kai-sassnowski.com/post/php-functors-1/)

Un functor o un servicio normal los plantearía en caso de que sea necesario conectar con la capa de Infraestructura (acceso a bbdd, a servicios externos de terceros, etc.), un trait por otro lado lo implementaría en caso de que correspondiere a la capa de Dominio para manipular datos pero es que no veo en que momento sería buena idea o interesante añadir una función anónima a una constante.

Así que lo dicho, no veo en qué momento sería buena idea añadir una función anónima a una constante.

¿Ha sido una buena DrupalCampSpain 2025?

oskar calvo — Tue, 23 Sep 2025 06:31:26 +0000

Voy a dar mi opinión personal.

Creo que es una pregunta con una respuesta difícil y que depende más de los puntos de vista.

Desde mi punto de vista como persona que ha asistido a varias charlas, la verdad es que la Camp ha sido interesante, quizás para mi gusto demasiada IA, pero no podemos negar que ahora mismo la IA es lo que está tirando de una parte importante del carro de la innovación en el sector de la informática/tecnología tanto a nivel de desarrollo y mejoras como de inversión económica, pero mi sensación es que después del pico del hype que hemos sufrido con la IA estamos en estos momentos en un momento meseta y no tengo claro si de aquí volverá a subir o tendrá una caída.

También he echado en falta charlas más transversales que no sea únicamente Drupal, o en las que Drupal esté presente pero como una tecnología más, charlas del tipo "CSS moderno", "Gestión de proyectos", "SEO en un mundo el que Google está matando la navegación por los resultados de búsqueda", "el futuro de la web abierta", etc...

Desde mi punto de vista como ponente, este año he tenido que dar dos talleres, uno en el Centro de Nuevas Tecnologías de Galicia y otro en la Camp, la verdad es que como siempre ha sido una experiencia enriquecedora ya que el hecho de preparar, revisar, volver a preparar los talleres se aprende mucho y ayuda a asentar conocimientos. El único pero que me pongo a mi mismo es en taller de ECA que a pesar de tener ejemplos muy sencillos del módulo quise enseñar algunas cosas algo más complejas que no terminaron de funcionar bien, ya tengo un posit para ver que ha pasado y poder explicarlo a los asistentes en una futura publicación.

Desde mi punto de vista como parte de la organización, creo que la Camp ha ido rodada, ocurrieron pequeñas cosas pero todo se pudo subsanar sin problemas, si hasta acompañó el tiempo durante todo el evento.

Mención especial se merece Esmeralda, que se ha currado unos textos increíbles para ir publicando en Linkedin, este debería ser el nivel a seguir los próximos años, quizás nos tenemos que plantear que de cara al sprint final de las Camps (cuando más hincapié hacemos en RRSS) la AED debería contratar a una persona que trabaje en comunicación/RRSS para que nos ayude con los textos.

Lo dicho, creo que ha salido una Camp muy redonda y para estar Galicia en "Finis Terrae" la comunidad ha respondido muy bien y hemos tengo una Camp con una gran afluencia de profesionales.

¿Cómo detectar cuando un proyecto se ha construido bien?

oskar calvo — Thu, 07 Aug 2025 18:14:41 +0000

Este artículo es totalmente subjetivo basado en apreciaciones ya que valorar la calidad de un proyecto es una tarea compleja y se tienen que valorar muchos elementos: tests, documentación, arquitectura, etc...

En una conversación de Medium, si a veces salen cosas interesantes en Medium y últimamente salen más cosas interesantes en los comentarios que en los contenidos (que de una temporada a esta parte apestan a IA que echa para atrás), comentamos lo que gustaba más sobre las últimas novedades de PHP y algunas de las novedades que denotaban no solo usar un PHP moderno sino que el equipo de desarrollo se preocupa por hacer buen código eran los siguientes.

`declare(strict_types=1);`

Esta declaración de constructor define que el código que sigue a continuación esté obligada a usar tipado estricto en la definición de métodos y funciones.

Usar esta declaración no es el santo grial pero si ayuda a entender mucho mejor el código, también ayuda a las herramientas de análisis de código estático a encontrar posibles errores, y hace el código más mantenible y organizado.

Se que se puede usar mixed como una forma de "escapar" del tipado estricto pero usando el histórico de git sabríamos que desarrollador lo está usando.

`final class`

final class permite definir que clases pueden ser heredables y cuales no, esta funcionalidad me parece interesante porque de forma explícita indica la relación jerárquica de las clases, y evita que haya una herencia de unas clases a otras de forma infinita.

`readonly class`

Readonly class es otra forma de declarar las clases, en este caso una clase que es instanciada con sus valores no podrá ser modificada, esta forma de declarar una clase ayuda para entender el uso de las mismas y normalmente las suelo usar en las clases de tipo Value Object como los DTO se benefician de readonly.

Add custom twig templates to drupal regions

oskar calvo — Mon, 07 Jul 2025 13:57:54 +0000

page.hmtl.twig

{#
/**
 * @file
 * Tara is theme implementation to display a single page.
 *
 * The doctype, html, head and body tags are not in this template. Instead they
 * can be found in the html.html.twig template.
 *
 * Available variables:
 *
 * General utility variables:
 * - base_path: The base URL path of the Drupal installation. Will usually be
 *   "/" unless you have installed Drupal in a sub-directory.
 * - is_front: A flag indicating if the current page is the front page.
 * - logged_in: A flag indicating if the user is registered and signed in.
 * - is_admin: A flag indicating if the user has permission to access
 *   administration pages.
 *
 * Site identity:
 * - front_page: The URL of the front page. Use this instead of base_path when
 *   linking to the front page. This includes the language domain or prefix.
 *
 * Page content (in order of occurrence in the default page.html.twig):
 * - node: Fully loaded node, if there is an automatically-loaded node
 *   associated with the page and the node ID is the second argument in the
 *   page is path (e.g. node/12345 and node/12345/revisions, but not
 *   comment/reply/12345).
 *
 * Regions:
 * - page.header_top: Items for the header top region.
 * - page.site_branding: Items (logo / site name / site slogan) for the site branding region.
 * - page.primary_menu: Items for the primary menu region.
 * - page.search_box: Items for the full page search region.
 * - page.breadcrumb: Items for the breadcrumb region.
 * - page.highlighted: Items for the highlighted region.
 * - page.content: The main content of the current page.
 * - page.content_top: Items for the content top region.
 * - page.content_bottom: Items for the content bottom region.
 * - page.sidebar_first: Items for the first / left sidebar.
 * - page.sidebar_second: Items for the second / right sidebar.
 * - page.footer_top: Items for the footer top region.
 * - page.footer_first: Items for the first footer column.
 * - page.footer_second: Items for the second footer column.
 * - page.footer_third: Items for the third footer column.
 * - page.footer_fourth: Items for the fourth footer column.
 * - page.footer_bottom: Items for the footer bottom region.
 *
 * @see template_preprocess_page()
 * @see html.html.twig
 */
#}
{% include '@tara/template-parts/header.html.twig' %}
{% include '@tara/template-parts/breadcrumb_region.html.twig' %}
{% include '@tara/template-parts/highlighted.html.twig' %}
<div id="main-wrapper" class="main-wrapper">
  <div class="container">
  <div class="main-container">
    <main id="main" class="page-content">
      <a id="main-content" tabindex="-1"></a>{# link is in html.html.twig #}
      {% include '@tara/template-parts/content_top.html.twig' %}
      {{ page.content }}
      {% include '@tara/template-parts/content_bottom.html.twig' %}
    </main>
    {% include '@tara/template-parts/left_sidebar.html.twig' %}
    {% include '@tara/template-parts/right_sidebar.html.twig' %}
  </div> {# /.main-container #}
  </div> {# /.container #}
</div>{# /main-wrapper #}
{% include '@tara/template-parts/footer.html.twig' %}

header-top-content.html.twig.twig

<div class="header-top">
  <div class="container">
    <div class="header-top-container">
      {% if page.header_top %}
        <div class="header-top-left header-top-block">
          {% include '@tara/partials/header-top-content.html.twig' with { content: page.header_top } %}
        </div> <!--/.header-top-left -->
      {% endif %}
      {% if all_icons_show %}
        <div class="header-top-right header-top-block">
          {% include '@tara/template-parts/social-icons.html.twig' %}
        </div> <!--/.header-top-right -->
      {% endif %}
    </div> <!--/.header-top-container -->
  </div> <!--/.container -->
</div> <!--/.header-top -->

header-top-content.html.twig

{# themes/custom/tara/templates/partials/header-top-content.html.twig #}
<div class="custom-header-top-content">
  {{ content }}
</div>

My two cents about drupal templates marketplaces

oskar calvo — Sat, 14 Jun 2025 17:14:58 +0000

First of all, I want to state that this text represents my fears and my opinion based on my personal experience. It is not intended as an attack on anyone or anything.

Although the idea of a Drupal template marketplace seems like a good idea to me and could be a good boost for Drupal as a product and therefore for the Drupal community, these are my doubts, fears, or a mix of everything.

When we talk about a Drupal template marketplace, the WordPress marketplace comes to mind. It's true that this marketplace works and has possibly been one of WordPress's successes in becoming the product it is today, as it allowed someone without technical knowledge to have a beautiful and operational website.

But we have to take the following into account: a high percentage of sites built with WordPress only use the two content types that come standard in WordPress: page and blog. Having such a basic and simple content architecture makes it easy to create themes that can be sold, since the fields used are known and therefore it doesn't pose any problem.

To be able to do something similar, we either create a marketplace solely for Drupal CMS, or Drupal themes will only use "Article" and "Basic Page," which could be an option, a kind of Minimum Viable Product (MVP). However, my suspicion is that both Drupal CMS projects and Drupal in general will transcend the content architecture that these two products offer.

From my experience, Drupal usually tends towards content architectures that adapt very well to the needs of projects and do not usually remain in the basic proposals.

How can we overcome the particularity of Drupal having content architectures tailored to project needs and at the same time work with a theme marketplace? I believe that a solution would be recipes and the SDC module.

If the community builds a kind of PSR (PHP Standards Recommendations) for content type recipes that can be installed as dependencies in projects, and in turn these recipes include an SDC for each element, it would make things much easier.

On the one hand, these recipes would make it easier for site builders (and also for end users with less technical knowledge) when creating a project, as they could navigate between the different content type recipe options and choose the ones they need for the project. As I mentioned above, these recipes, in addition to a standard content type configuration, should have an associated SDC so that, without needing to buy a theme, they at least have the necessary HTML to be basic but correct.

On the other hand, with this standardization, what will be achieved is that the themes programmed for Drupal will be more consistent with the project's content types. In fact, it would be interesting for themes to indicate the content types they style in their theme definition, so that a buyer can search among those that interest them most.

Another of my fears is that the people who program the themes will move the backend logic to the Twig templates, either through Drupal community modules or through code they have programmed themselves.
I don't have a solution for this. Perhaps a product rating and comment system, but these types of services eventually become very biased. Perhaps an agent of an LLM model that analyzes the code and can publish comments about it, but this would also be complex and costly.

These are my fears and concerns, and what I seek with this exposition is not to scare anyone, but to work with the community to find the best way to build a healthy marketplace that helps the development of Drupal as a community and as a product. (editado)

Drupal Form state with select multiple

oskar calvo — Tue, 03 Jun 2025 16:18:27 +0000

A veces el código habla por si mismo.

    $form['description'] = [
      '#type' => 'item',
      '#markup' => $this->t('This example demonstrates the #states
property. #states makes an element visibility dependent on another.'),
    ];

    $form['needs_accommodation'] = [
      '#type' => 'select',
      '#title' => 'Need Special Accommodations?',
      '#options' => [
        '1' => 'si',
        '2' => 'no',
        '3' => 'vete a saber'
      ],
      '#multiple' => TRUE,
    ];

    // The #states property used here binds the visibility of the
    // container element to the value of the needs_accommodation checkbox above.
    $form['accommodation'] = [
      '#type' => 'container',
      '#attributes' => [
        'class' => 'accommodation',
      ],
      // #states is an associative array. Each key is the name of a state to
      // apply to the element, such as 'visible'. Each value is another array,
      // making a list of conditions that denote when the state should be
      // applied. Every condition is a key/value pair, whose key is a jQuery
      // selector that denotes another element on the page, and whose value is
      // an array of conditions, which must be met on in order for the state to
      // be applied.
      //
      // For additional documentation on the #states property including a list
      // of valid states and conditions see drupal_process_states().
      '#states' => [
        // The state being affected is "invisible".
        'visible' => [
          // Drupal will only apply this state when the element that satisfies
          // the selector input[name="needs_accommodation"] is un-checked.
          'select[name="needs_accommodation[]"]' => ['value' => ['3']],
        ],
      ],
    ];

    $form['accommodation']['diet'] = [
      '#type' => 'textfield',
      '#title' => $this->t('Dietary Restrictions'),
    ];

    // Add a submit button that handles the submission of the form.
    $form['actions']['submit'] = [
      '#type' => 'submit',
      '#value' => $this->t('Submit'),
    ];

    return $form;

Los kudos para Penyaskito

Extender plugins de tipo bloque en Drupal

oskar calvo — Sun, 25 May 2025 15:28:44 +0000

Una de las cosas que más me gustán hacer en Drupal es crear una clase abstracta a modo de "base" cuando estoy definiendo bloques que se van a usar en un Slide.

En este caso como el Slide afectaba a la información de páginas de taxonomías de un vocabulario lo que hice fue crear una clase abstracta para definir todos los elementos comunes de todos los bloques.

<?php

declare(strict_types=1);

namespace Drupal\project_term_area_study\Plugin\Block;

use Drupal\Core\Block\BlockBase;
use Drupal\Core\Entity\EntityTypeManagerInterface;
use Drupal\Core\Plugin\ContainerFactoryPluginInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Drupal\taxonomy\TermInterface;

/**
 * Base class for all blocks used in area of study taxonomy pages.
 */
abstract class AreaOfStudyBaseBlock extends BlockBase implements ContainerFactoryPluginInterface {

  /**
   * The entity type manager.
   *
   * @var \Drupal\Core\Entity\EntityTypeManagerInterface
   */
  protected $entityTypeManager;

  /**
   * Constructs a new MyCustomBlockBase object.
   *
   * @param array $configuration
   *   A configuration array containing information about the plugin instance.
   * @param string $plugin_id
   *   The plugin_id for the plugin instance.
   * @param mixed $plugin_definition
   *   The plugin implementation definition.
   * @param \Drupal\Core\Entity\EntityTypeManagerInterface $entity_type_manager
   *   The entity type manager.
   */
  public function __construct(
    array $configuration,
    $plugin_id,
    $plugin_definition,
    private readonly EntityTypeManagerInterface $entity_type_manager,
  ) {
    parent::__construct($configuration, $plugin_id, $plugin_definition);
    $this->entityTypeManager = $entity_type_manager;
  }

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) {
    return new static(
      $configuration,
      $plugin_id,
      $plugin_definition,
      $container->get('entity_type.manager')
    );
  }

  /**
   */
  protected function getTermContext(): ?TermInterface {
    $term = $this->getContextValue('taxonomy_term');

    if ($term instanceof TermInterface) {
      return $term;
    }
    return NULL;
  }

}

Lo que ambos bloques que voy a usar comparten es que ambos necesitan el servicio entity_type.manager, y usan el contexto de bloques, en este caso para recuperar el término al que corresponde la página.

<?php

declare(strict_types=1);

namespace Drupal\project_term_area_study\Plugin\Block;

use Drupal\Core\Url;

/**
 * Provides an area study degree standard name list block.
 *
 * @Block(
 *   id = "project_term_area_study_degree_standard_name_list",
 *   admin_label = @Translation("Area study degree standard name list"),
 *   category = @Translation("project"),
 *   context_definitions = {
 *     "taxonomy_term" = @ContextDefinition("entity:taxonomy_term")
 *   }
 * )
 */
final class AreaOfStudyDegreeStandardNameListBlock extends AreaOfStudyBaseBlock {

  /**
   * {@inheritdoc}
   */
  public function build(): array {
    $term = $this->getTermContext();
  }

}

En este caso no tenemos que volve a definir ni el constructor ni el método create para cargar los servicios definidos en la clase abstracta ya que son los mismos.

El segundo bloque necesita el servicio rendered, así que si se tiene que instanciar el constructor y el método create; lo importante también es que a parent::constructor además de los métodos por defecto de la base de plugins de Drupal se le tiene que pasar entityTypeManager que es un método que carga la clase abstracta que hemos definido.

<?php

declare(strict_types=1);

namespace Drupal\project_term_area_study\Plugin\Block;

use Drupal\Core\Entity\EntityTypeManagerInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Drupal\taxonomy\TermInterface;
use Drupal\views\Views;
use Drupal\Core\Render\RendererInterface;

/**
 * Provides an area of study - others area of study block.
 *
 * @Block(
 *   id = "project_term_area_study_others_area_of_study",
 *   admin_label = @Translation("Area of study - others area of study"),
 *   category = @Translation("project"),
 *   context_definitions = {
 *     "taxonomy_term" = @ContextDefinition("entity:taxonomy_term")
 *   }
 * )
 */
final class AreaOfStudyOthersAreaOfStudyBlock extends AreaOfStudyBaseBlock {

  /**
   * The current renderer.
   *
   * @var \Drupal\Core\Render\RendererInterface
   */
  protected $renderer;

  /**
   * Constructs the plugin instance.
   */
  public function __construct(
    array $configuration,
    $plugin_id,
    $plugin_definition,
    EntityTypeManagerInterface $entityTypeManager,
    RendererInterface $renderer,
  ) {
    parent::__construct($configuration, $plugin_id, $plugin_definition, $entityTypeManager);
    $this->renderer = $renderer;
  }

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition): self {
    return new self(
      $configuration,
      $plugin_id,
      $plugin_definition,
      $container->get('entity_type.manager'),
      $container->get('renderer'),
    );
  }

  /**
   * {@inheritdoc}
   */
  public function build(): array {
    $term = $this->getTermContext();

  }

  /**
   */
  protected function getListOfTerms(TermInterface $term) :?array {
// Code here.
  }

  /**
   */
  private function renderViewContent(string $view_id, string $display_id, $arguments): mixed {
// Code here.
  }

}

También es importante que aunque el método getTermContext() lo hemos definido en la clase abstracta en ambos bloques se tiene que definir dentro del "@block" para que Drupal pueda cargar el contexto.