Contrib.social

Add a "context" array variable to all theme hooks and "#context" array property to all elements to provide optional contextual data

Open on Drupal.org →
Created on 24 June 2015, over 9 years ago
Updated 13 September 2024, 3 months ago

Problem/Motivation

Fairly often there is a need for some sort of contextual data when rendering an element, which parts of, ultimately needs to make its way down the theme system pipeline.

This is especially true when certain render elements or theme hooks, that are not normally aware of the context in which they'll be rendered, needs additional information to provide rendering variations (i.e. per type or identifier).

While it is possible to add any variable you want in preprocess functions, it is often too late in the process and the original data that usually contains the needed information has long since been lost.

This is, in part, due to arbitrary properties (not registered in the theme hook) from being automatically transferred from a renderable element's properties.

Example from the search module in core, where a 'context' variable was manually added to allow for this flexibility ( #2495419: Move the 'search-results' class from the render array and into a Classy template → ):

$build['search_results'] = [
  '#theme' => ['item_list__search_results__' . $plugin->getPluginId(), 'item_list__search_results'],
  //...
  '#context' => ['plugin' => $plugin->getPluginId()],
];

Another example of use is for Views suggestions (which this issue is blocking): 📌 [PP-1] Use hook_theme_suggestions in views Postponed .

Proposed resolution

Add a context variable as an empty array for all theme hooks, if one doesn't already exist.

Add a #context property as an empty array to all elements, if one doesn't already exist.

Remaining tasks

User interface changes

None

API changes

  • The addition of a default #context property added to all elements
  • The addition of a default context property added to all theme hooks (for preprocessing purposes only)
  • The automatic mapping of a renderable element's #context property to the context variable
  • Removal of the context variable immediately prior to rendering (for security concerns).

Data model changes

None

✨ Feature request
Status

Needs work

Version

11.0 🔥

Component
Theme  →

Last updated about 18 hours ago

Created by

🇨🇦Canada star-szr

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

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    🇺🇸United States maskedjellybean Portland, OR

    Thanks for the work on this everybody. This would be super useful. It's one of those things you just assume you can do. Then when you really need to do it and learn you can't, it's quite frustrating.

  • Comment over 1 year ago →
    🇮🇳India manikandank03 Tamil Nadu

    Re-rolled patch #124 to support Drupal 10 latest version(10.1.1) and below themes twig changes removed because those themes not support for Drupal 10,

    bartik, classy, seven, stable.

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.2 & MySQL 8
    last update over 1 year ago
    Patch Failed to Apply
  • Comment over 1 year ago →
    🇩🇪Germany Anybody Porta Westfalica

    Could someone perhaps give an update on the plan here?

    Since @markhalliwell's Bio says:

    I am no longer an active part of this community and not working on any Drupal projects.

    there seems to be not much movement here any more and I think for Drupal 11 it would be worth a review and discussion, if this still makes sense as improvement to Core.
    If yes, we should take it over the finish line. If not, we should point out, why this plan is deprecated.

    Does anyone know?

  • Comment 11 months ago →
    edmoreta

    Patch for 10.2.x based on #129

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.2 & MySQL 8
    last update 11 months ago
    Custom Commands Failed
  • Comment 11 months ago →
    🇮🇳India manikandank03 Tamil Nadu

    Patch #131 works fine in Drupal 10.2.2 with PHP 8.2.

  • Comment 11 months ago →
    🇮🇳India anchal_gupta

    Fixed phpstan
    Please review

  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.2 & MySQL 8
    last update 11 months ago
    Patch Failed to Apply
  • Comment 10 months ago →
    🇫🇷France nicolas-lsn

    Please note that such changes could cause issue with third-party modules, for example ui_patterns.

    This last module define a #context object, which is overridden if we apply the patch. This leads to a fatal error.

    So maybe it could be better to override or extends the #context element if it is empty or array, otherwise the variable should be kept as this.

  • Comment 6 months ago →
    🇺🇸United States les lim

    Les Lim → made their first commit to this issue’s fork.

  • Comment 6 months ago →
    🇺🇸United States les lim

    Les Lim → changed the visibility of the branch 2511548-135 to hidden.

  • Comment 6 months ago →
    🇺🇸United States les lim

    Les Lim → changed the visibility of the branch 11.0.x to hidden.

  • Comment 6 months ago →
    🇺🇸United States les lim

    Les Lim → changed the visibility of the branch 2511548-135 to active.

  • Merge request !8531Reroll #131 for 11.x → (Open) created by les lim
  • Comment 6 months ago →
    🇺🇸United States les lim

    Rerolled #131 against 11.x, but this also applies to 10.3.x right now.

  • Pipeline finished with Failed
    6 months ago
    Total: 202s
    #207326
  • Comment 3 months ago →
    edmoreta

    Posting plain diff for MR 8531

  • Comment about 1 month ago →
    🇩🇪Germany Anybody Porta Westfalica

    @JohnAlbin, @laurii, @larowlan: Now that @markhalliwell has left the Drupal Community, shouldn't we still try to get this fixed finally?

    To say it in the words of @maskedjellybean in #127:

    It's one of those things you just assume you can do. Then when you really need to do it and learn you can't, it's quite frustrating.

    Yes, this is a specific case, but I think many Drupal developers / themers run into this one day, as it's just a natural thing that you sometimes need to know about the context.
    For one year I now didn't run into this, now it's time again: ✨ Pass block context to commerce_cart_block Active 😉

    So I think this is really relevant for DX (Developer Experience) / FX (Front End Experience) and happy Drupal developing.

    My question is: How can we tackle this efficiently? Could someone (powerful 😉) decide, how this should finally be implemented, then we'd be willing to help with the implementation! But coming back and see things stuck again, where lots of work went in already, is frustrating for everyone here.

    Would be great if someone who can decide on this, could decide on this. Even if it means a totally different approach or closing this won't fix, but documenting a best practice for the structure and namings to use in such #context-passing cases, for example in Block Plugins.

    Thank you! 😊

  • Comment about 1 month ago →
    🇳🇱Netherlands Martijn de Wit 🇳🇱 The Netherlands

    maybe via https://www.drupal.org/project/drupal/issues/3482385#comment-15842192 📌 Add a feature flag for the procedural hooks bc layer Active

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024