This patch will allow PHPTemplate based themes to add their own settings fields to the admin/themes/settings/
configuration form. This will allow these themes to provide a UI for changing things like alternate color schemes or alternate layouts.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

forngren’s picture

I haven't tested it due lack of time, but I was going to spend my summer building something simular. Looks great! But should we perheps add some theme-related forms to the forms-api (eg colorselector, fontselector, etc)?

Cheers Johan F

jfitzell’s picture

This is a slightly modified version that looks the the URL to get the theme being edited instead of using the default theme. A slight hack, perhaps, but I don't see any better way without changing the core to pass the theme that is being looked for through to this function. I'd be happy to hear a better suggestion.

Heine’s picture

I cannot patch right now, but from the code (and http://drupal.org/node/57676) it seems that you can encounter fatal errors when redeclaring functions, for example when template.php of the current theme and template.php of the configured theme both contain function phptemplate_something.

adrian’s picture

Project: PHPTemplate » Drupal core
Version: master » x.y.z
Component: Code » theme system

PHPTemplate is now in drupal core, so this should be a Drupal:Theme System issue.

And i don't support this patch, due to the last problem mentioned. You can not reliably load another theme in the same session, while you are able to configure a theme other than the one you have loaded.

jfitzell’s picture

The code looks for
_settings(), not phptemplate_settings(), so loading multiple templates wouldn't be a problem. It is possible that it might conflict with a module of the same name of course. We could always use phptemplate_
_settings() or something; I don't really care what the naming scheme is but that should be a solveable issue...

jfitzell’s picture

The code looks for
_settings(), not phptemplate_settings(), so loading multiple templates wouldn't be a problem. It is possible that it might conflict with a module of the same name of course. We could always use phptemplate_
_settings() or something; I don't really care what the naming scheme is but that should be a solveable issue...

Heine’s picture

Status: Needs review » Needs work

If theme 1 is active and overrides comment_form (ie, declares phptemplate_comment_form) and you want to set settings of theme 2 then you will get a fatal error if theme 2 also overrides comment_form (phptemplate_comment_form)

It's not the function_exists that's the problem, it's

$file = drupal_get_path('theme', $key) . '/template.php';
.
include_once "$file";
jfitzell’s picture

Ah, good point.

Could we load a different file to get the settings from then, or something?

forngren’s picture

Hm, why not settings.tpl.php?

(I didn't quite understand how themes overwrites each others settings, if someone can explain that further I'll look into it)

KNK’s picture

I have tested this patch (phptemplate_per_theme_settings.patch form jfitzell's comment-118316) and got what I needed, but the call to the 'theme_settings' function should also include the $key as parameter:

- return $function();
+ return $function($key);

this way it is possible to use it's value to return the template specifc settings or system defaults if omited. Well for the last one to work, some changes to system.module are required too.

forngren’s picture

19 days before code freeze... C'mon people, we can do this.

I'll take a look at the code/pathces tomorrow and if everything goes well I might be able to present some code. However, I'm gonna need help with testing it.

KNK: I like your approach, it would be nice if we could discuss it. You can reach me at: http://drupal.org/user/40238/contact or skype/#drupal; forngren

Cheer!

fgm’s picture

I've recently created a more generic solution to the theme settings problem, that works with both PHPtemplate and plain PHP themes.

It essentially introduces an equivalent to the late hook_settings for modules. Maybe deriving something from it would be the best solution ? After all, adding form fields to the already crowded theme configuration form degrades the UI.

fgm’s picture

bradlis7’s picture

Version: x.y.z » 6.x-dev

I think color.module could do this if it was more generic. Right now, I'm pretty displeased with the module, because of it's very Garland oriented approach, which makes it hard for other themes to use. I've submitted an issue on it though, but I have not received a reply.

I'd really like to see the ability for themes to add settings. Maybe there could be some sort of hook, like hook_form_alter, but for themes.

+1 for functionality.

mlncn’s picture

Has this issue been taken up somewhere else, or is it stalled? In general, it seems like a good idea.

~ ben :: http://AgaricDesign.com

forngren’s picture

Status: Needs work » Closed (duplicate)

Marking this as dupe of http://drupal.org/node/57676 since there's actually some code there.