Given how #2004872: [meta] Theme system architecture changes is refactoring the theming layer, I am proposing we swap out all references of "hook" when we are actually referring to "Theme IDs". This is exactly how FAPI does things and will help separate the concept of a module/theme "hook" implementation and implemented "Theme IDs". An example of this more simplistic definition is what will be done with #2035055: Introduce hook_theme_prepare[_alter]() and remove hook_preprocess_HOOK().

Here's an example of a code change the patch might contain. Before:

function hook_preprocess_HOOK(&$variables) {
  // This example is from rdf_preprocess_image(). It adds an RDF attribute
  // to the image hook's variables.
  $variables['attributes']['typeof'] = array('foaf:Image');
}

After:

function hook_preprocess_TEMPLATE_SUGGESTION(&$variables) {
  // This example is from rdf_preprocess_image(). It adds an RDF attribute
  // to the image hook's variables.
  $variables['attributes']['typeof'] = array('foaf:Image');
}

Blocked by:
#2052271: Introduce theme_info() call, deprecate theme() and have theme_info() just return render array information (like element_info())

Comments

markhalliwell’s picture

Issue summary: View changes

Updated issue summary.

couturier’s picture

We're coming up really tight on code freeze for Drupal 8. Does this need to be reassigned to Drupal 9?

markhalliwell’s picture

Issue tags: +API change

Well technically yes, general code/API freeze has already happened (July 1st). However, given the nature of the major initiative to refactor the entire theme system (#2004872: [meta] Theme system architecture changes) API changes could still happen (https://drupal.org/node/2045345). The theme system API is still kind of up in the air (especially considering how much the theme system team is committed to finally making a decent theming system and now with Twig in core).

We would all benefit from this mentality shift. This may or may not get in D8. It depends on how much we actually do get committed. Until we (the theme system team) deem it necessary to actually move this to D9 (or told to by core maintainers), let's just leave it for now. This issue is really just a placeholder for now (hence the initial postponed status) and is just a reference for the initial concept.

This issue will probably be bumped to critical once other issues are committed. It would cause this issue to become a priority for making sense of the new theme system.

couturier’s picture

Yes, one of our locals (EclipseGc) has talked about how important it is to still get some changes going into D8 despite the freeze. Hope you can do it. The release schedule for new versions seems to be slowing down, so the more that can be done now, the better.

jenlampton’s picture

I'm also all for changing this terminology. i think it will help make things make more sense :) +1!

markhalliwell’s picture

Title: [META] Rename the concept of theme "HOOKS" to "THEME_ID" » [META] Rename the concept of "THEME HOOKS" to "TEMPLATE_ID" & "BASE_TEMPLATE_ID"

Changing title per suggestion from webchick in irc. "THEME_ID" could also potentially confuse people as they might associate that with the actually theme name (ie: bartik, stark). These are actually template IDs.

webchick’s picture

Yes, though note that my feedback on the issue title doesn't necessarily imply "approved API change." I'd need to understand better what the impact would be on module developers.

jenlampton’s picture

Title: [META] Rename the concept of "THEME HOOKS" to "TEMPLATE_ID" & "BASE_TEMPLATE_ID" » [META] Rename "THEME HOOKS" to "TEMPLATE_ID" & "BASE_TEMPLATE_ID" in theme API Docs

I think the impact on module developers would be that they would finally understand what our API docs are talking about - since this new terminology maps to what they already know and love: Form API.

None of the eval'd code they have to write would change since this issue only affects documentation changes (updated issue title to reflect that), but hopefully they'll finally be able to grok what we are talking about.

jenlampton’s picture

Issue summary: View changes

Updated issue summary.

jenlampton’s picture

Title: [META] Rename "THEME HOOKS" to "TEMPLATE_ID" & "BASE_TEMPLATE_ID" in theme API Docs » [META] Rename "THEME HOOK"s to "TEMPLATE_SUGGESTION"s in theme API Docs

After a good chat with Mark, we decided to simplify this even further. In Drupal 8 people won't really know what theme hooks are (since we don't have any more theme functions) but they will be very familiar with template suggestions. Both the BASE_TEMPLATE_ID and the TEMPLATE_ID are just suggestions, so I think we should update the docs to call these things TEMPLATE_SUGGESTIONs instead.

Since suggestions will *finally* work properly, we don't need to differentiate between the suggestion that maps to the template that is actually being used, and the base template anymore. They are all just template suggestions.

Yay for fixing critical bugs :)

Fore more clarification of the new order of things, see this issue: #2035055: Introduce hook_theme_prepare[_alter]() and remove hook_preprocess_HOOK()

jenlampton’s picture

Title: [META] Rename "THEME HOOK"s to "TEMPLATE_SUGGESTION"s in theme API Docs » [META] Rename "THEME HOOK"s to "TEMPLATE_SUGGESTION"s in theme API Docs and example usage

more clearer title

jenlampton’s picture

Issue summary: View changes

example

joelpittet’s picture

Version: 8.0.x-dev » 9.x-dev
Issue summary: View changes
Status: Postponed » Active

We are at RC and this could make things a bit confusing also with "Template Suggestions". Changing this would be a whole thing... Moving to 9.x

catch’s picture

Title: [META] Rename "THEME HOOK"s to "TEMPLATE_SUGGESTION"s in theme API Docs and example usage » Find a better name for theme hooks and use it in documentation
Version: 9.x-dev » 8.3.x-dev
Priority: Normal » Minor

Yeah I don't think TEMPLATE_SUGGESTION is clearer, looks like you're preprocessing the template suggestion itself. Re-titling and moving down to 8.3.x (and minor), since if we found a better name, we could update the docs and potentially code references too in 8.x

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

markhalliwell’s picture

Title: Find a better name for theme hooks and use it in documentation » Find a better name for "theme hook" and use it in documentation
Issue tags: +Theme System Modernization Initiative
Related issues: +#2869859: [PP-1] Refactor theme hooks/registry into plugin managers

Obviously, for the previous procedural function based APIs, we'd still call them "theme hooks" as we'll need to keep them for BC reasons.

However, considering that #2869859: [PP-1] Refactor theme hooks/registry into plugin managers is proposing to introduce a @Template annotated plugin and the fact that we now use [Twig] templates instead of theme functions... I think the appropriate logical step would be to call them a "template" or a "template ID" moving forward.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.