Contrib.social

Explicitly register template_preprocess callbacks in hook_theme()

Open on Drupal.org →
Created on 21 January 2025, about 15 hours ago

Problem/Motivation

template_preprocess... functions are very unusual. They are the only thing in modules that's not prefixed by the module.

📌 Handle module preprocess functions Active is struggling a bit with that and need to introduce the ability for modules to register them as hooks but not for themself but a "template" pseudo-module.

The reason they are important is order of preprocess callbacks. Currently, first is template_preprocess(), followed by the template_preprocess function for the specific theme definition/hook if it exists, then global regular preprocess functions such as contextual_preprocess() and finally regular specific module and then theme preprocess functions.

Steps to reproduce

Proposed resolution

I'm proposing a different approach, that instead of magically named callbacks with a special prefix, or OOP hooks registered for template, we put them explicitly into hook_theme as a callback. Similar to #pre_render, #process and the other callbacks you can register in an Element plugin.

A cleaner option would to make a theme definition/hook an actual class like a plugin an then it could have a preprocess() method. There are old issues for introducing that, but it's a far more complex step that requires bigger changes and performance testing.

This requires template_preprocess() to be removed first: 📌 Move template_preprocess, _template_preprocess_default_variables into services Needs work

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

📌 Task
Status

Postponed

Version

11.1 🔥

Component

theme system

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 !10970Resolve #3501136 "Explicitly register templatepreprocess" → (Open) created by berdir
  • Pipeline finished with Success
    about 7 hours ago
    Total: 382s
    #402071
  • Comment about 7 hours ago →
    🇨🇭Switzerland berdir Switzerland

    Created a merge request with a proof of concept, basic right now, but already covers BC by only looking for and registering template_ prefixed functions if initial preprocess is not defined.

    MR is based on the referenced issue, only relevant changes is the currently last commit: https://git.drupalcode.org/project/drupal/-/commit/a955017c8e669d28297af....

    Array key "initial preprocess" obviously up for discussion, I picked this to explain the difference to regular preprocess functions.

    I copy pasted the invocation, we can for example use\Drupal\Core\Utility\CallableResolver to also support services.

  • Comment about 6 hours ago →
    🇳🇿New Zealand quietone
  • Comment about 1 hour ago →
    🇺🇸United States nicxvan

    We discussed this briefly on slack, so I'd like to move some thoughts here.

    #3495943: Handle module preprocess functions as OOP hooks is struggling a bit with that and need to introduce the ability for modules to register them as hooks but not for themself but a "template" pseudo-module.

    I'd disagree with the characterization that it is struggling, it is solved. I'm not sure I'd call it a pseudo module either, it's a prefix, it's basically the same thing Registry does for it.

    As for this issue:
    I think it's an interesting approach

    use\Drupal\Core\Utility\CallableResolver to also support services.

    I think we'd definitely want to do this, it would be a shame to have DI for other preprocess hooks but not these ones.

    This does make theme_registry_alter harder to maintain BC for contrib which is not a problem for the original issue, but I'm not sure how many people are moving template preprocess around, and I'm not sure this should be a blocker for this approach, just an observation.

    Another thing I see is this relies on call_user_func_array for calling the initial preprocess, I am not a fan of that call, the original approach only uses it for fallback for custom callbacks added in theme registry alter.

    If it's decided that this is the direction to go, I really think this should be done together with the other issue, this isn't too much more and if we pull out the template work in the other issue the changes are likely a wash complexity-wise.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024