Die, themeEngineName_ prefix, die!

I like the idea on paper, but how do you propose getting around the function name collision issue? You can't have to identically named functions.

But, all my blog posts that say use 'phptemplate_something' will be no good!!!

Tagging as needs design review. I'm fine either way but I imagine some others might want to chime in. This is removing a 'feature' after all.

@seanr his proposal removes the possibility of name collisions.

Thanks for raising this issue JohnAlbin! I'm 100% behind it, our use of phptemplate_* in themes has always broken our own rules about namespacing.

Though I wonder, wouldn't it be better to removed "themeEngineName_engine_*" and keep "themeEngineName_*" for the theme engine? Although then we wouldn't be forcing users to stop using phptemplate_ prefixes, for better or worse.

Ah, OK, so he's just saying to always use themename_function instead of the current sometimes enginename_function sometimes themename_function paradigm. I'm down with that. It'll certainly mean more consistency in documentation and suchlike.

The documentation for theme() needs to be tweaked for THEME_preprocess(). It still refers to ENGINE_preprocess() which should shortly not be in the documentation any more. I'm not sure what it should be changed to, especially when most themes will benefit from phptemplate_preprocess() anyway.

Thanks for getting this cleared up in core. I'd been a little confused lately with the different things I had read in documentation and code.

Oh, um. Needs work, I guess. :P

If we really want to remove this, we have to introduce an equivalent for this one phptemplate_* use-case in the same patch:

I have x Drupal sites with y modules. Because y modules implement awkward output, I have y common (default) theme overrides in x sites.

If we remove phptemplate_* without replacement, then I need to maintain x * y theme function overrides.

Meaning: Theme developers currently are able to use the phptemplate*-prefix to build a repository of common/custom theme overrides that can be quickly applied to any Drupal site.

sun, If you're really concerned about building a "library" of overrides, you can still use hook_theme_registry_alter() and point theme functions to those provided by a universal module shared by all sites. Or better yet, you can also create a base theme shared by all sites, which has the added benefit of individual themes being able to override the parent theme functions.

On the other hand, if the sites are all separately maintained, it doesn't seem like renaming the functions would be a terrible burden, since the code in each theme will be maintained separately anyway. We certainly don't want to provide a new equivalent shared prefix, as the common prefix between different themes makes loading of multiple themes at once impossible.

If you want to have a common library of overrides for use in lots of themes, put them into a base theme. They'll still work and you can single-source them, and you can override them again for your site-specific subtheme. Zen D6 did that in early versions to work around bugs in core until they got fixed, and it worked fine.

Subthemes themselves are a replacement for phptemplate_*, if you use them properly. I am +1 on removing phptemplate_*.

Re-roll.

Tagging.

             elseif ($type == 'theme_engine' || $type == 'base_theme_engine') {
               // Theme engines get an extra set that come before the normally named variable processors.
               $prefixes[] = $name . '_engine';
-              // The theme engine also registers on behalf of the theme. The theme or engine name can be used.
-              $prefixes[] = $name;
-              $prefixes[] = $theme;
+              // The theme engine also registers on behalf of the theme. The theme name should be used.
+              $prefixes[] = $theme;

That comment sounds a bit strange to me now. Perhaps simply drop the also as well as the second sentence.

+1

I've read the comments and the patch itself. The patch itself seems benign. It will break a few themes, so "we" need to make sure there is good upgrade documentation for D6 -> D7. The fix is easy though (search and replace from phptemplate to themeName) so I support the patch.

+1
Find/replace is easy enough. My only worry is phptemplate_ functions from past installs silently failing, and curses being shouted around the world as people wonder why drupal isn't noticing phptemplate_foo like they expect. I think a warning message for version 7 would be considerate when drupal detects the prefix, but I don't think its a show stopper. As for the word "also"...

Ok, cool. That's enough +1s from enough themer-types that I'm comfortable committing this once it's RTBC again.

Looks good to me, but I'll have webchick drive this one home!

Committed to HEAD! Yay! :D

Docs please!

Documentation has been added to the D6.x -> D7.x theme upgrade page. Please see: http://drupal.org/node/254940#function-names-phptemplate and add additional information if you feel more is needed.

Updating the tags as well.
Removing: Needs design review, Needs Documentation, needs themer review, Quick fix,

Hm...

Trying to figure out something...

I have a rather uncommon use case for theme patterns (which might be bad, then I'm looking for better suggestions!).

Basically, in Privatemsg, I have a table with dynamic number of columns, and each of these columns can be displayed/themed or not. (We have our own query builder in the D6 version so the whole thing is very dynamic).

In D6, I have used theme patterns to be able to theme every field in a separate theme function and easily allow other modules/themes to override single columns, both the header definition and the actualy fields.

The problem in D6 already was that modules can't provide theme suggestions based on theme patterns. That's why I used phptemplate_ as the prefix. See also http://blog.worldempire.ch/api/group/theming/1 for a description of what I'm doing, and http://blog.worldempire.ch/api/drupal/privatemsg.theme.inc/1/source for the currently defined theme functions.

Now, this patch removed the phptemplate_ prefix which makes it impossible for modules to provide theme suggestions, since it only looks for the theme anymore.

Am I just doing it wrong(tm) (If yes, then please explain me how to do it correctly while having a similiar flexibility) or how am I supposed to adapt that system to D7?

Ok, I was able to "solve" the issue by adding the following code to my hook_theme() implementation:

  // Include the theme file to load the theme suggestions.
  module_load_include('inc', 'privatemsg', 'privatemsg.theme');
  $templates += drupal_find_theme_functions($templates, array('theme'));
  return $templates;

This looks for theme suggestions prefixed with theme_, which is what I wanted in the first place. Please tell me if that's not a good idea :)

phptemplate_ prefix is still suggested in hook_theme (as a default preprocess)? i guess it isn't anymore, so i am removing it.

forgot to add the patch

I think this missed correction to system.api.php should be raised/reopened as an issue against Drupal core, not in the documentation project, so I'm moving it there.