How to extend admin options

Serge D

Joined: 2009-06-11
Posts: 2138

Posted: Tue, 2009-10-20 13:31

When configuring the theme admin/theme_options it would be nice to add/remove options specific to a current theme.

There is modules\gallery\helpers\theme.php which actually contain all the elements for page above.
I would assume we could override such file(s) from helpers folder by simply including theme.php into theme's folder (when inheritance is fixed).

But is it right approach?

Serge D

Joined: 2009-06-11
Posts: 2138

Posted: Tue, 2009-10-20 13:40

In WordPress any module has ability to add its own configuration node/page and populate/save settings
Everything is on the level of "macro commands" to add node, add parameters, construct options page.
It is easy/straightforward and easy to extend.
It would be nice to have similar mechanisms in G3.

bharat

Joined: 2002-05-21
Posts: 7934

Posted: Wed, 2009-10-21 02:20

We haven't yet settled on a strategy for this. Currently, the theme could make its own admin page to expose its own theme options, which would provide maximum flexibility but require the themer to understand how to write Gallery/Kohana code. Or we could try to create our own abstraction in between like we did in Gallery 2. Or we could just expand the default options to add the ones you're thinking about. What options did you have in mind?
---
Problems? Check gallery3/var/logs
bugs/feature req's | upgrade to the latest code | use git

Serge D

Joined: 2009-06-11
Posts: 2138

Posted: Wed, 2009-10-21 02:58

I do not see why would we have anything different from what is already there for modules... With minor additions...

Lets look at theme settings. There is already a theme options page in admin module. I do not see a reason to introduce yet another one. What would be nice is to have something like the following added via helper events file (similar to one for modules) where we could say (just one of possible implementations, I would suggest to look at WP code as a nice example as well):

- theme_install event: a) theme_admin_add_var(themename, var_name, default_value) - this would initialize var in DB
b) theme_admin_add_element(themename, 'html code') - adds provided html code to the page (usualy <input ...>) to the theme admin page
- theme_uninstall event: the theme be able to call theme_remove_admin_var(themename, var_name) if necessary.

First two would prepare DB and provide logic to build necessary elements for the admin page. Since it is admin function, we do not care much about speed/security. Last would give option to remove data from DB if desired.
You already have some of this for modules, we just need similar logic for themes. Assuming helpers/controllers work from the theme level.

talmdal

Joined: 2006-12-06
Posts: 358

Posted: Wed, 2009-10-21 03:22

@Serge D: Maybe create a ticket to capture the thoughts (stick it in release 3.1).
http://www.timalmdal.com

Serge D Joined: 2009-06-11 Posts: 2138	Posted: Tue, 2009-10-20 13:31
	When configuring the theme admin/theme_options it would be nice to add/remove options specific to a current theme. There is modules\gallery\helpers\theme.php which actually contain all the elements for page above. I would assume we could override such file(s) from helpers folder by simply including theme.php into theme's folder (when inheritance is fixed). But is it right approach?
	XUser login Username: * Password: * Create new account Request new password
Serge D Joined: 2009-06-11 Posts: 2138	Posted: Tue, 2009-10-20 13:40
	In WordPress any module has ability to add its own configuration node/page and populate/save settings Everything is on the level of "macro commands" to add node, add parameters, construct options page. It is easy/straightforward and easy to extend. It would be nice to have similar mechanisms in G3.

bharat Joined: 2002-05-21 Posts: 7934	Posted: Wed, 2009-10-21 02:20
	We haven't yet settled on a strategy for this. Currently, the theme could make its own admin page to expose its own theme options, which would provide maximum flexibility but require the themer to understand how to write Gallery/Kohana code. Or we could try to create our own abstraction in between like we did in Gallery 2. Or we could just expand the default options to add the ones you're thinking about. What options did you have in mind? --- Problems? Check gallery3/var/logs bugs/feature req's \| upgrade to the latest code \| use git

Serge D Joined: 2009-06-11 Posts: 2138	Posted: Wed, 2009-10-21 02:58
	I do not see why would we have anything different from what is already there for modules... With minor additions... Lets look at theme settings. There is already a theme options page in admin module. I do not see a reason to introduce yet another one. What would be nice is to have something like the following added via helper events file (similar to one for modules) where we could say (just one of possible implementations, I would suggest to look at WP code as a nice example as well): - theme_install event: a) theme_admin_add_var(themename, var_name, default_value) - this would initialize var in DB b) theme_admin_add_element(themename, 'html code') - adds provided html code to the page (usualy <input ...>) to the theme admin page - theme_uninstall event: the theme be able to call theme_remove_admin_var(themename, var_name) if necessary. First two would prepare DB and provide logic to build necessary elements for the admin page. Since it is admin function, we do not care much about speed/security. Last would give option to remove data from DB if desired. You already have some of this for modules, we just need similar logic for themes. Assuming helpers/controllers work from the theme level.

talmdal Joined: 2006-12-06 Posts: 358	Posted: Wed, 2009-10-21 03:22
	@Serge D: Maybe create a ticket to capture the thoughts (stick it in release 3.1). http://www.timalmdal.com

How to extend admin options

XUser login