Registry: replace files[] with include[]/exclude[] [#399702]

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.inc

template.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

Comment #1

sun

German

Karlsruhe

commented 21 April 2009 at 17:11

Issue tags:

+tpl-refresh

Comment #2

dvessel commented 21 April 2009 at 19:12

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.

Comment #3

sun

German

Karlsruhe

commented 3 May 2009 at 21:56

Title:	template.php: Allow to split theme override functions into multiple .inc files in theme includes/ directory	» Registry: Allow wildcard in files[] .info file definition
Component:	theme system	» base system
Assigned:	Unassigned	» sun

Yeah, something like

files[] = includes/*.inc

would 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.

Comment #4

sun

German

Karlsruhe

commented 7 May 2009 at 07:15

Title:	Registry: Allow wildcard in files[] .info file definition	» Registry: Allow wildcards in files[] or replace files[] with ignore[]
Category:	feature	» task
Priority:	Normal	» Critical

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.inc
files[] = includes/bar.baz.inc

with

ignore[] = foo.api.php
ignore[] = includes/*.php
ignore[] = external_library/

Comment #5

chx commented 7 May 2009 at 07:20

Title:

Registry: Allow wildcards in files[] or replace files[] with ignore[]

» Registry: replace files[] with include[]/exclude[]

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.

Comment #6

sun

German

Karlsruhe

commented 7 May 2009 at 07:35

Issue tags:

-tpl-refresh

+Registry

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.

Comment #7

Crell commented 20 May 2009 at 07:28

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.

Comment #8

sun

German

Karlsruhe

commented 20 May 2009 at 11:19

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.php
exclude[] = 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.

Comment #9

merlinofchaos commented 7 June 2009 at 21:26

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.

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...

Comment #10

moshe weitzman commented 18 June 2009 at 20:30

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.