phpBB • Free and Open Source Forum Software

One of the advantages of a face-to-face meeting is that feature requests and feature discussion can be much more effective; at least if it is about minor window dressing as opposed to huge changes. To curb the wave of requests right here: you should have been there, the opportunity has passed . People watching the SVN repository may know already: there were some major changes in the past two weeks. A lot is moving right now in the active branches, but that’s for future posts.

Today it is a great pleasure for us to unveil a new feature for the 3.0 branch, to be released with 3.0.3: Template Inheritance.

It is a direct result of our meeting with Andy Miller and is intended to give more freedom to style and template authors. To cut to the chase and explain what it actually does: If you base a new template set on an existing one, but if you only want to change a few things, you still needed to copy all template files. Having unaltered copies certainly works fine, but if there is an update for the original, it can be very tedious to merge the changes to all derived templates.

So – the answer to that is adding template inheritance. Now a simple declaration “inherit_from” in the template configuration file will tell the template engine to fall back to files of a different template set, if there is anything missing in the current one. The nice thing about this is that the process is completely transparent after template compilation and comes at practically no extra costs during runtime.

To give you an idea: Let’s say you want a new template set named inherits, which uses prosilver as base (especially note the very last line):

Code: Select all

# General Information about this template

name = inherits
copyright = © phpBB Group, 2007
version = 3.0.2

# Defining a different template bitfield
template_bitfield = lNg=

# Are we inheriting?
inherit_from = prosilver

And let’s just add just one template file to that new set:

Code: Select all

$ ls -l
-rw-r--r-- 1 kell dev 8986 Jul 30 15:22 editor.js
-rwxr-xr-x 1 kell dev 215 Jul 28 16:52 faq_body.html
-rw-r--r-- 1 kell dev 4375 Jul 30 15:22 forum_fn.js
-rw-r--r-- 1 kell dev 2517 Jul 30 15:22 styleswitcher.js
-rwxr-xr-x 1 kell dev 764 Jul 28 16:52 template.cfg

The sole html file is pretty trivial – I’m sure you folks will come up with far cooler applications. It does use includes however:

Code: Select all

<!-- INCLUDE overall_header.html -->
<h2>This is overridden</h2>
<!-- INCLUDE jumpbox.html -->
<!-- INCLUDE overall_footer.html -->

Okay. Let’s see how that works out. We see our new template in the list:

The partial template set appears in the list normally.

… and can install it:

The install shows the dependency.

We can now use it in a style just as any other template:

And – drumroll – we can use it.

And take it for a ride – all the included template files are taken from prosilver:

The page uses all elements from prosilver.

Back in the ACP, we can view the cache details to see where the template engine took the source from:

The ACP gives information about the origin of a given template file.

So far so good, we can’t wait to see what people will do with it. Have fun.

In the implementation for 3.0 there are a few limitations to this, which we won’t keep secret. For starters, there is no stacking of fallbacks. It’s only possible to fallback to a template that does not itself declare to be dependent on another template. The other major limitation is that it only affects the files managed by the template engine (*.html) and not the static javascript files bundled with many templates. Those static files still have to be copied, or manually linked using the new {T_SUPER_TEMPLATE_PATH} template variable.

Note: Although we introduce this new feature in the 3.0.x line the branch is still feature frozen. We will however include very important features if we wish to do so and if they fit nicely into the existing code. New features are discussed by the development team and need to be approved by all members.