Proposal: child themes

[Timbalu]

...extremely sticky as I said (can't figure out how to change) - tried with submit template config, but still $serendipity['template_engine'] == new_default,default

the problem is, whatever I do with the "engine: setting" there is no effect! Tried different possibilities with/without all with submit.

.... after a while ...

ok, I figured out - you definitely have to change templates first and back to get this working, which is ok for production systems.

Now to make this clear:
I turned engine to new_default, blue for example - with none of them having a admin folder.
The "myTemplate" has a very minor one, so the fallback of {TEMPLATE_PATH} at least is "myTemplate".
If it hasn't, the fallback of {TEMPLATE_PATH} is "bulletproof" and last in the row "default". So this is different the way falling back missing classes in CSS. And Yes, it is very logical, that URL path differ to CSS class settings in the way they fall back.

Now what can we do with that!?

[Timbalu]

Just a little addition

engine: new_default, default
does not inherit missing classes. It just means - if file new_default/style.css use it else use default/style.css.

[Timbalu]

I am nearly done with my theme (not really a child...) and quite happy with the new engine option, but discovered something like a bug or at least very unexpected behaviour.

If you have defined these sidebars like left,right,middle,top,footer,hide in your themes config.inc, it will work as expected as long as you dont change your theme options or themes in general.
As far as I can see, the theme data is stored to the serendipity_options table if you submit your theme options. In this case the sidebars value is not stored and set to empty. This follows to have no sidebars in the plugin admin panel, having all your plugins in 'none' without showing the other default and/or extra columns.
The only way to set this back is to truncate the serendipity_options table.

I assume there must be some storage function thing not knowing about the themes sidebars array value.
Now we can fix it to be set with its value or do not store the sidebars option at all, which is ok too!

Can you confirm this behaviour, Garvin?

EDIT:
Finally found the reason, its just because I used type => hidden, then you definitely have to add a value => 'your content' into the $template_config array, as already blogged by Don.

[garvinhicking]

Hi!

I'm quite tired, so only browsed thorugh this and maybe only comment on a single issue that might have surfaced:

"engine" only applies to the getTemplate code calls. it does not affect template_path and link hrefs that are written INSIDE the .tpl files. Those always need to be patched up locally, because template-path will always be the current template path and NEVER fallback to another directory.

[Timbalu]

engine: new_default, default
does not inherit missing classes. It just means - if file new_default/style.css use it else use default/style.css.

Well this behaviour may be as well, but I discovered its quite more tricky.

Remember I wanted to get rid of defaults #content width: auto, without overwriting its value, so I added #content { padding: 10px; margin: 10px; } in new_default to set back width auto (I developed a whole new template starting on this).
In serendipity.css you will not find the old default width:auto setting any more and only one #content {...} from new_default, which is good. Other classes which have the absolute same content as in default get doubled (first default, second new_default).

This looks to me like it does inherits classes and ids with same values, but only uses the new_default ones, if they have changed in any values. I tried this with some of these classes.

Garvin, is this the default behaviour? Or am I barking up the wrong tree?

Wuff!:
Please forgive me thinking to loud on my way to progress...
The doubled styles I found, came from default/style_fallback.css.
I now threw an empty style_fallback.css into new_default, which avoids the use of the original.