Convert template_preprocess in views

Created on 13 July 2025, 1 day ago

Problem/Motivation

Part of 📌 [pp-1] Convert Template Preprocess hooks to OOP equivalent Postponed: needs info

Convert all template_preprocess

Steps to reproduce

Proposed resolution

* Move all template_preprocess functions in update module to ViewsThemeHooks, including hook_theme itself
* Deprecate the old functions and move them to views.module, so that the file definitions can be removed
* Update all references, including direct calls in tests and @see/@covers in tests and templates.
* Figure out how to define initial preprocess callbacks based on the plugin definition and theme name.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

📌 Task
Status

Active

Version

11.0 🔥

Component

views.module

Created by

🇨🇭Switzerland berdir Switzerland

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @berdir
  • Merge request !12709Conversion of template_preprocess in views module → (Open) created by berdir
  • Pipeline finished with Failed
    1 day ago
    Total: 363s
    #546268
  • 🇨🇭Switzerland berdir Switzerland

    This might not be as hard as I feared, but it does depend on this central piece of magic:

           $initial_preprocess_class = 'Drupal\\' . $def['provider'] . '\\Hook\\' . Container::camelize($def['provider']) . 'ThemeHooks';
            $initial_preprocess_method = 'preprocess' . Container::camelize($def['theme']);
    
            if (method_exists($initial_preprocess_class, $initial_preprocess_method)) {
              $hooks[$def['theme']]['initial preprocess'] = $initial_preprocess_class . ':' . $initial_preprocess_method;
            }
    

    I think we generally want less magic like this (service providers), but it's not enforced, just a default, and it feels in line with the kind of magic that this hook does.

    There is also the bit about theme_file that plugins can in theory provide, but the new attribute classes are actually missing that and I want to deprecate the underlying 'file' key as well, so I just went ahead and added that deprecation right now. There are a bunch of them in contrib, but again, they would need to resort to a plugin definition alter hook for this in D12 with attributes anyway. And all they need to do for D12 compatibility is move the functions into their .module file (or convert to initial preprocess, but that would require 11.3 unless we backport this)

  • Pipeline finished with Failed
    1 day ago
    Total: 757s
    #546270
  • Pipeline finished with Failed
    1 day ago
    Total: 601s
    #546420
  • Pipeline finished with Success
    about 7 hours ago
    Total: 678s
    #547073
Production build 0.71.5 2024