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');
}
Comments
Comment #0.0
markhalliwellUpdated issue summary.
Comment #1
couturier CreditAttribution: couturier commentedWe're coming up really tight on code freeze for Drupal 8. Does this need to be reassigned to Drupal 9?
Comment #2
markhalliwellWell 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.
Comment #3
couturier CreditAttribution: couturier commentedYes, 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.
Comment #4
jenlamptonI'm also all for changing this terminology. i think it will help make things make more sense :) +1!
Comment #5
markhalliwellChanging 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.
Comment #6
webchickYes, 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.
Comment #7
jenlamptonI 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.
Comment #7.0
jenlamptonUpdated issue summary.
Comment #8
jenlamptonAfter 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()
Comment #9
jenlamptonmore clearer title
Comment #9.0
jenlamptonexample
Comment #10
joelpittetWe 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
Comment #11
catchYeah 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
Comment #15
markhalliwellObviously, 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.