Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | base system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
| Issue tags: | Registry, template.php, theme, theme layer |
Issue Summary
The new template files we have are great, but when completely customizing a site's output, you still have to override gazillion of theme functions.
Putting all theme override functions into one bloated template.php sucks.
In my custom themes, I started to use a "includes" sub-directory in theme folder, which holds several PHP include files that are named after the module/subsystem they are overriding. The files are named freely and the theme unconditionally loads all *.inc files in that directory, which makes it easy to add new overrides and manage existing.
So I have:
mytheme/template.php
mytheme/includes/form.inc
mytheme/includes/user.inc
mytheme/includes/some_other_module.inc
mytheme/includes/custom.inc
mytheme/includes/all_theme_overrides_for_my_special_topic.inctemplate.php just glob()s the entire "includes" directory and include_once()s each file that was found.
Functionally, there is no difference to how theme() works. It is just a clean and better maintainable way to separate theme override functions by topic.
Additionally, it allows you to easily re-use theme override snippets across multiple Drupal sites by copying and pasting the .inc file into your other Drupal site.
Would that make sense for Drupal core?
Comments
#1
#2
Having a built-in facility to separating the template.php file would be nice but I wouldn't want to go with your approach. Specifically, including all the files unconditionally.
What I'd rather see is the theme registry have the ability to handle multiple files to include. Each hook entry can define a file and this is often done for modules to point at the file with all the required functions such as theme functions and preprocessors but it can only point to one file. It wasn't designed to be used from the theme AFAIK. It *can* be used from the theme even though I don't think it was designed for it. And oddly enough, once a theme overrides the hook, the defined file is lost for the module anyway and I've never experienced an error with this.
I personally don't use the 'file' in the registry because I believe it's a bug. Once I can focus on core again, I'll try fixing it but if the file can be safely defined more than once, It would be the first step in including the file only when it's needed.
Having core populate the file entry for each hook automatically would need to be discussed and I guess this is what you would be more concerned with.
#3
Yeah, something like
files[] = includes/*.incwould be very helpful for .info files.
That would do actually the same like I am doing now, but much more cleanly, and using auto-loading of the registry. :)
Also, it would help all kind of contrib modules that implement Views and/or Panels support, which both encapsulate atomic functionality in separate include files.
#4
In IRC, chx raised the question why we need to specify each and every file for the registry in the first place.
One idea might as well be to completely replace
files[] = foo.bar.incfiles[] = includes/bar.baz.inc
with
ignore[] = foo.api.phpignore[] = includes/*.php
ignore[] = external_library/
#5
Yeah. We already know that in modules/foo/ we want every piece of .inc and .module file so why type it out meticulously? We could use include/exclude pairs on top of including every piece of inc and module for modules. For themes the default will be a bit more tricky. I let others follow up on that.
#6
Note that we are now discussing modules, not themes. Which is a turn that is perfectly fine with me.
If it should happen that we can't apply the very same approach to themes as well (no include[] by default, but themers can add some in the theme's .info file), I'll go and open a separate issue later on.
#7
IMO we do want an opt-in strategy to declaring files; otherwise life can get extremely difficult for bridge modules that integrate to some 3rd party code we don't want Drupal's registry to deal with.
For most modules, there would only be maybe 3-4 files (not counting templates). Modules that have dozens of files like Views or CCK are rare, but I can see the argument to making life easier for them. Glob or regex patterns seem like a good way to handle that.
Pros:
- Easy to declare a whole bunch of files at once.
- Probably easy to implement.
Cons:
- The syntax gets more complicated, so someone looking at someone else's info file could have a WTF if they're not already well-versed in globs.
- Could lead to inadvertently over-aggressive rules.
#8
Note that I'm putting a fair amount of energy into Libraries API currently, which should at least eliminate the need to exclude arbitrary files of externally hosted/distributed libraries that were usually copied into a module's directory before.
If some module comes pre-packaged with some GPL-code that should only be loaded manually (and not by the Registry), then I suppose that you either have a few files only...
exclude[] = foo.phpexclude[] = fParser.inc
...or that those files use a common namespace anyway...
exclude[] = *diff.inc...or that there are so many files that you need/want to put them into a sub-directory anyway...
exclude[] = beerparser/*After all, when talking about this, we are talking about edge cases. The registry should focus on making the life easier for those 4,000 regular contrib modules instead. It makes no sense to add the current
files[]burden to all developers just to prevent < 1% of contrib module developers from not telling the registry to not parse certain files.#9
Who doesn't know globs? It's just * pattern matching. Maybe if you've never touched a command line in your life...but then, why are you looking at .info files then? I reject this con. =)
I would rather deny,allow be the default order, though. I think it's easier to specify what you're including. Having to exclude is just as tedious, as you might have css, js, images directories as well. And any module which has themes might have to exclude their *.tpl.php files...
#10
I am looking to implement studio theme in core and it organizes its preprocess functions into a 'preprocess subdir'. it would be really nice to allow themes to put files i the theme registry. rules for include/exclude are nice but even letting themes be first class citizens for the code registry is a start.
#11
Crell or whoever probably wants to take over.
#12
Slight correction. Since #345118: Performance: Split .module files by moving hooks won't fix, this won't fix, too.
#13
@Sun - please don't hurt the queue when you are having a temper tantrum.
#14
#15
Downgrading all D8 criticals to major per http://drupal.org/node/45111
#16
We no longer have the hook registry.
Latest proposal at #534594: registry_rebuild() and system_rebuild_module_data depend on all modules being loaded would skip having files[] at all for the class registry.
I'm marking this postponed until that critical is resolved. If we deprecate files[] altogether then this'll be won't fix again.
#17
And downgrading to a feature request as well.