Options arrangement

I have been giving a bit of thought to the categorisation of the options. Mainly because Config is getting so long. So was thinking about pulling CSS based options like using a reset for instance out to the CSS category but then I thought perhaps that isn't right since CSS currently has the ability to put CSS in directly.

The option is to have a few different Configs, i.e. Config (for general stuff), Config - CSS, Config - JS etc.

Thoughts? Am I just over thinking this and it doesn't matter?

I have been giving a bit of thought to the categorisation of the options. Mainly because Config is getting so long. So was thinking about pulling CSS based options like using a reset for instance out to the CSS category but then I thought perhaps that isn't right since CSS currently has the ability to put CSS in directly. The option is to have a few different Configs, i.e. Config (for general stuff), Config - CSS, Config - JS etc. Thoughts? Am I just over thinking this and it doesn't matter?

possibly over-thinking :p

Go with your heart. CSS reset under CSS sounds good to me.

On a vaguely related note, Antony and I were discussing removing the options from the admin homepage - partly to clean up but mainly so that 'editor' users don't have access to them.

possibly over-thinking :p Go with your heart. CSS reset under CSS sounds good to me. On a vaguely related note, Antony and I were discussing removing the options from the admin homepage - partly to clean up but mainly so that 'editor' users don't have access to them.

Removing options from admin home page sounds like a great idea.

I'll have play with an options re-categorisation and see how it goes.

Removing options from admin home page sounds like a great idea. I'll have play with an options re-categorisation and see how it goes.

Tom, I think it's important that some options are available to regular admins, and others just for the developer. I frequently add options that are specific to the client's site and put them in their own category for the client to play with. For example I might give them an option for adjusting how many products appear on their product page, or a text field where they can customise a message that appears at a certain point in the shopping cart etc.

Maybe we look at adding a new field to the option entries where one can specify which usergroups the options are visible to?

Tom, I think it's important that some options are available to regular admins, and others just for the developer. I frequently add options that are specific to the client's site and put them in their own category for the client to play with. For example I might give them an option for adjusting how many products appear on their product page, or a text field where they can customise a message that appears at a certain point in the shopping cart etc. Maybe we look at adding a new field to the option entries where one can specify which usergroups the options are visible to?

Harvey makes a good point. I pretty much always hide option from the user because I don't trust them not to break parts of the site but there are things there I would prefer them to be able to change.

I have long wondered about using permissions on options. Using a user group field that can only be edited through api.php could be a good way to filter the list for the content users.

Harvey makes a good point. I pretty much always hide option from the user because I don't trust them not to break parts of the site but there are things there I would prefer them to be able to change. I have long wondered about using permissions on options. Using a user group field that can only be edited through api.php could be a good way to filter the list for the content users.

Totally agree.

I was only talking about the content cache and zip options on the admin home going - I don't see any need for non-admins to have access to them (and the current tag, if you have content cache turned on and change the style sheet, it breaks for the length the minimum cache period, so I don't want people turning it on who don't know what they're doing), and I don't think you can exclude other usergroups from the home page without making it weird.

But, usergroup option access would be good.

I'd prefer to use the existing permission system if possible - presumably easiest way is to limit the results returned to the options page by usergroup, and I'd guess to set the default for each option to admin only.

The existing interface is not built for adding it though, and switching to something like the standard jstree table is maybe going too far the other way.

Although, that said, there are other things that it would be good to do with options that a more comprehensive edit approach might make possible, like being able to to set both global and varying options based on sub-site or language. I know that way one of the remaining bits of interface that Mike felt was missing from his multi-domain version.

Totally agree. I was only talking about the content cache and zip options on the admin home going - I don't see any need for non-admins to have access to them (and the current tag, if you have content cache turned on and change the style sheet, it breaks for the length the minimum cache period, so I don't want people turning it on who don't know what they're doing), and I don't think you can exclude other usergroups from the home page without making it weird. But, usergroup option access would be good. I'd prefer to use the existing permission system if possible - presumably easiest way is to limit the results returned to the options page by usergroup, and I'd guess to set the default for each option to admin only. The existing interface is not built for adding it though, and switching to something like the standard jstree table is maybe going too far the other way. Although, that said, there are other things that it would be good to do with options that a more comprehensive edit approach might make possible, like being able to to set both global and varying options based on sub-site or language. I know that way one of the remaining bits of interface that Mike felt was missing from his multi-domain version.