Serendipity Forums

Backwards compatibility has always been a strong suit of s9y, and on some level, I think that's a good thing. But there are some areas in which backwards compatibility will be (or already is) an issue. Since we always cared about not breaking the whole thing for some small feature, we should probably look for workarounds.

"My" area of contribution is frontend templates, which is an area in which s9y is already way behind in my humble opinion:

* We have a default template which is ridiculously outdated, but cannot be changed easily because it's the fallback template. There are quite a number of templates which rely on this theme's .tpl files. (It also includes an admin template which is very frustrating to style because large parts of it are hardcoded, but that's a different subject, I guess.)

* We have a standard template (Bulletproof) which is widely appreciated, still more or less up-to-date in terms of markup and very user-friendly. Unfortunately, it's not a good starting point for template development because the code is, well, not exactly manageable if you're not Don or me.

Of course, one can simply change all the files from /templates/default/ to their liking, but that's not very smart since it's a lot of work to do for every single theme.

Possible solution for this: A concept I stumpled across in that other blog engine -- child themes.

Any theme could have a "parent theme" which it would use as its "personal fallback". That way, some themes could keep the current default as their fallback, templates based on BP could be done just the way the mt-* themes work now (some images and a stylesheet, although I haven't really thought that through), others could use a "new default" etc. It should also not be possible to install a child theme if the parent theme isn't present for some reason. And since there are currently no themes which don't use /templates/default/ as a fallback, /templates/default/ could simply be the "fallback fallback", if that makes any sense.

I have more ideas for themes up my sleeve, but this seems to be the most important one because it would give s9y theme development a whole new perspective. Of course, I have no idea whether this would be easy to implement or could implement it myself. Maybe it's even a stupid idea for some weird reason I haven't thought about.

So what do you (coder) guys think? Garvin?

YL

Hi!

We should actually have this since a long time.

In your info.txt you can specify "engine: default" (default *g*) or "engine: new_default". This should specify the fallback directory. Wanna try it out?

(BTW: Great idea. I also completely forgot about this. This could save us some hassle; simply introduce a "serendipity2" template (or whatever) and use that for engine: in all compatible and new templates.)

Regards,
Garvin

garvinhicking wrote:In your info.txt you can specify "engine: default" (default *g*) or "engine: new_default". This should specify the fallback directory. Wanna try it out?

Wait, are you telling me I just typed a proposal for something we already have?!? (I'll give it a try over the weekend and report back.

YL

Interesting...

Don Chambers wrote:Interesting...

I was just thinking: "How much time could Don have saved on Kinetic had he known about this?" ...

YL

I just now created an empty template folder containing only an info.txt with
in the last line. Gives me a blank front page. Hmmm.

YL

yellowled wrote:

Don Chambers wrote:Interesting...

I was just thinking: "How much time could Don have saved on Kinetic had he known about this?" ...

YL

Probably very little.... but I do like the concept. I have never investigated wp's child concept, but I thought it was closer to the bp concept of user.css.... then again, since it is wp, that means you could have entire php file modifications from one child theme to the next... not just style sheets.

yellowled wrote:I just now created an empty template folder containing only an info.txt with

Code: Select all

engine: bulletproof

in the last line. Gives me a blank front page. Hmmm.

Okay, for anyone willing to test this themselves, here's what I just chatted about with Garvin:

* You'll want to test this with a recent svn snapshot (1.6alpha2 or later).
* The new template assigned via engine needs all files default has. That includes the treeview and YahooUI stuff etc.

I can't post any result so far since I have to edit a fresh copy of default at the time of writing this

YL

yellowled wrote:I can't post any result so far since I have to edit a fresh copy of default at the time of writing this

Liftoff, we have a liftoff

Meaning: It's working. I haven't really played with it yet to the full extent, but it is working.

This is so cool.

YL

yellowled wrote:I just now created an empty template folder containing only an info.txt with

Code: Select all

engine: bulletproof

in the last line. Gives me a blank front page. Hmmm.

YL

It works for me. I created an empty template folder. I then copied bp's info.txt file to this folder, modifying it as follows: One thing I noticed immediately was this new child theme wanted to load a non-existent colorset:
This is easy enough to fix (not yet committed):
Another thing it wants to do is load the bulletproof logo, which does not exist in the child theme test folder: So, do we want it looking for this image at the child theme folder, or back to the bp folder?

Don Chambers wrote:

Code: Select all

Name: Child Theme Test 1
Author: Don Chambers
Date: 2010-08-21
engine: bulletproof
Require Serendipity: 1.2

Please note that w/ Garvin's latest patch to svn, you could also state:
Not sure whether it really works with a "triple fallback", but seems to. "bulletproof,default" should definitely work -- and be necessary since BP doesn't have all the files default has.

YL

Hi!

Yes, you can now have multiple (as many as you like) fallbacks quite easily.

Regards,
Garvin

The original default has to be specified? I figured it would fallback to whatever is specified first, and if a file is missing there, would still ultimately fall back to default. No?

Don Chambers wrote:The original default has to be specified? I figured it would fallback to whatever is specified first, and if a file is missing there, would still ultimately fall back to default. No?

Again: No. Also again: Please correct me if I'm wrong.

Also not necessarily a bad idea. The sweet thing behind this is that you can actually write an engine template which can serve as a default to many child themes but doesn't need to be cluttered with feed tpls, the JS stuff for treeview etc.

Edit: Also, I just noticed that Garvin included those fixes in the 1.5.4 release, so we could start using the engine/child concept as of now. If we were that quick, of course.

YL

yellowled wrote:The sweet thing behind this is that you can actually write an engine template which can serve as a default to many child themes but doesn't need to be cluttered with feed tpls, the JS stuff for treeview etc.

That is my whole point - I would not want to provide duplicate smarty templates if they are identical to /default/