Don't allow theme hook and base template file name to be different

So afaik if you specify 'template' in hook_theme() then it works, except for the bug that the other issue will fix. If we wanted to stop people doing that we could possibly change that key to just specify a directory rather than a file path?

Why remove the ability to define the template filename?

It adds the ability for developers who create modules containing submodules to to place all templates in one directory but still differentiate which template for which submodule. That's just one of the many uses, I'm sure other developers have other justifications.

You can still preprocess/process functions based on the theme hook, that's not changing.

The other issue isn't adding any extra abilities, it's allowing for the existing ability of naming template files different to the hook to be overridden when copied, whereas currently only template files named after the hook are override-able.

I don’t like the idea. Having a singular naming convention is the only thing that ties all the separate parts. If you want to separate the name of the theming hook with the template name, there must be another model that is consistent and very well understood due to it being pervasively implemented. Not what can be argued as edge cases. Inconsistencies just kills me.

This obviously benefits module developers and can confuse theme devs. Individuals writing modules tend to be more experienced programmers so I think this idea is unbalanced.

@dvessel

The point of the other issues patch is to remove the confusion for theme dev, even I was confused that copying a template file didn't instantly override the original. But that is really the only confusion point.

From what I understand, there's two primary levels of theme development, there's those who simply override existing template files in there theme, which the other issues patch will fix, and there's those who use preprocess/process hooks in code, which is not an inexperienced task and those would generally be referring to the hook_theme() declaration or similar, in which case they would be working based on the hook key and this should be a non issue.

I've always stood by the fact that the Drupal way is to provide sane functionality with flexible options for users to use that functionality as they wish, not to restrict functionality so that they can only use it based on a single reasoning. This flexibility already exists, we shouldn't remove it, be should just make it more sane.

But at the very least, if you are to remove it, it can't be removed from D7 as it will break existing modules and sites.

Copied templates not registering is confusing but that is *not* the only confusing point. There is variable process functions that will not obviously be connected. You are arguing for it for organization issues. If all module developers have their own way of organizing and setting their own logic for naming templates then that'll be even more confusing.

I’m not arguing alternate template names should be removed. It’s too late for that but I don’t believe it should continue for D8. If it fixes copying templates without affecting anything else in D7 then great but then it will most likely continue for D8 (not so great). With the number of developers who might have their own idea on how they should be managed, it becomes an unnecessary burden for theme developers.

Having flexibility is great but it can also lead to building mental barriers which can be worse than building hard set ones. The question is, is this flexibility worth it in this case? I don’t think it is.

I believe my problem (http://drupal.org/node/342350#comment-6133956) also lands here.

Use case is modifying the toolbar.tpl.php file by means of hook_theme changes in the template.php theme file.
I had to name my file esp.tpl.php where esp is my theme name. This is a rather frustrating constraint for me as a dev. For life to be easier I should also but in a folder like templates/toolbar/esp.tpl.php but that creates more clutter that I don't need.

Solution anyone? Delete this issue and fix the bug?

I agree with Jacine and dvessel. It's flexibility that causes more harm than good. I support removing the option in D8 core, but maybe in a way that enables a contrib module to add it back (and deal with the implications of that).

Use case is modifying the toolbar.tpl.php file by means of hook_theme changes in the template.php theme file.

Can you clarify what the actual use-case is? What's your end goal? If it's your theme, why not name your toolbar template 'toolbar.tpl.php'? If it's not your theme, then depending on the nature of what you want to override, there's hook_theme_registry_alter(), and the ability for preprocess functions to set $variables['theme_hook_suggestions'].

Goal was to override the existing toolbar.tpl.php in core with a custom theme based tpl.

I was not allowed to name it toolbar.tpl.php. This file was not found or was simply ignored. I had to name it esp.tpl.php for it to work. Or NAME_OF_THEME_USING_HOOK.tpl.php

I also tried using hook_theme_registry_alter() but not altering 'theme_hook_suggestions'. I understood that setting the path should have been enough to make it look for my own toolbar.tpl.php especially considering 'template' = 'toolbar'.

I think the 'template' key should be removed from the hook theme array.

It let you think you have the flexibility to change the template filename, but if you do, you won't be able to override your template file from your module to your theme. The core (theme registry) assume that your templates and your hook theme name are the same.

Go see in core theme.inc, function drupal_find_theme_templates

// Get a listing of all template files in the path to search.
$files = drupal_system_listing($regex, $path, 'name', 0);

// Find templates that implement registered theme hooks and include that in
// what is returned so that the registry knows that the theme has this
// implementation.
foreach ($files as $template => $file) {
  // Ignore sub-theme templates for the current theme.
  if (strpos($file->uri, str_replace($subtheme_paths, '', $file->uri)) !== 0) {
    continue;
  }

// Chop off the remaining extensions if there are any. $template already
// has the rightmost extension removed, but there might still be more,
// such as with .tpl.php, which still has .tpl in $template at this point.
if (($pos = strpos($template, '.')) !== FALSE) {
  $template = substr($template, 0, $pos);
}
// Transform - in filenames to _ to match function naming scheme
// for the purposes of searching.
$hook = strtr($template, '-', '_');
if (isset($cache[$hook])) {
  $implementations[$hook] = array(
    'template' => $template,
    'path' => dirname($file->uri),
  );
}

@fboulais,

If that's the only reason, then refer to the original issue (in summary) where a fix was created for that issue, so if you change the template name you are still able to override it as normal.

Interesting idea, though going to have to push it to D9 as this would be tricky to do now.

We could probably find a way to deprecated this, like deprecation notice in theme registry rebuild, or failing that docs. So moving back to 8.x for that

@catch's idea seems like a good one. Re-activating.