Had a random idea about this today. The plugin info file already lists all the $settings variables that a plugin uses (so that it can set defaults and clean up properly later) but I've been thinking about the interface side of things.
Right now, if a plugin wants to add a settings page, even a simple one, it's going to have to create a file, use at least two hooks[1] and create a stub file that is almost entirely identical from plugin to plugin. Heck, when I start a plugin now that uses a simple settings page, I just copy everything from an earlier one.
So, here's what I'm thinking. Everything that you would normally have to set up for a settings page ($config_vars etc.) can be streamlined. Of course, more complex plugins (of the likes of WedgeDesk) would still do their own thing, but the smaller stuff could be simplified.
For example, I have a stub plugin that will grow into a big scary share-topics-with-services monster, dubbed Flitter because it was originally just Facebook + Twitter. Right now, it's very straightforward however, with its settings page being:
Code: [Select]
Then you have a function which binds to the admin menu, and the rest of the boilerplate in this function that's used for saving and calling the relevant templates and stuff. It gets set up as action=admin;area=flitter and uses 'Flitter' as the title (which is the plugin's title anyway)
I'm thinking we could handle this in the plugin-info.xml file directly instead.
Code: [Select]
Assuming the plugin author uses this, it should be able to handle the menu item, the settings themselves, making them searchable and auto-linking it in the plugins area (minimising the need for using the <acp-url> element though not obsoleting it)
The area= part specifies what admin area it should be, the icon is the icon for the dropdown menu, the bigicon is the big icon to use, <load-language> identifies what language file(s) should be loaded when running the page, so that the relevant strings can be loaded. Everything else just correlates to the above.
Personally, I think it's less effort for the plugin developer generally, it's less they have to deal with - you don't expressly have to deal with hooks when doing this and you're still doing less work than you would doing it manually.
Thoughts?
Right now, if a plugin wants to add a settings page, even a simple one, it's going to have to create a file, use at least two hooks[1] and create a stub file that is almost entirely identical from plugin to plugin. Heck, when I start a plugin now that uses a simple settings page, I just copy everything from an earlier one.
So, here's what I'm thinking. Everything that you would normally have to set up for a settings page ($config_vars etc.) can be streamlined. Of course, more complex plugins (of the likes of WedgeDesk) would still do their own thing, but the smaller stuff could be simplified.
For example, I have a stub plugin that will grow into a big scary share-topics-with-services monster, dubbed Flitter because it was originally just Facebook + Twitter. Right now, it's very straightforward however, with its settings page being:
$config_vars = array(
array('desc', 'flitter_desc'),
array('select', 'flitter_position', array('topic' => $txt['flitter_position_topic'], 'sidebar' => $txt['flitter_position_sidebar'])),
array('title', 'flitter_fb'),
array('check', 'flitter_showfb'),
array('title', 'flitter_twitter'),
array('check', 'flitter_showtwitter'),
$txt['flitter_twitter_via_desc'],
array('text', 'flitter_twitter_via'),
array('text', 'flitter_twitter_related'),
array('text', 'flitter_twitter_related_desc'),
array('title', 'flitter_google'),
array('check', 'flitter_showgoogle'),
);Then you have a function which binds to the admin menu, and the rest of the boilerplate in this function that's used for saving and calling the relevant templates and stuff. It gets set up as action=admin;area=flitter and uses 'Flitter' as the title (which is the plugin's title anyway)
I'm thinking we could handle this in the plugin-info.xml file directly instead.
<settings-page area="flitter" icon="mgallery.png" bigicon="$plugindir/flitter.png">
<load-language file="Flitter-Admin" />
<desc name="flitter_desc" />
<select name="flitter_position">
<opt value="topic" name="flitter_position_topic" />
<opt value="sidebar" name="flitter_position_sidebar" />
</select>
<title name="flitter_fb" />
<check name="flitter_showfb" />
<title name="flitter_twitter" />
<check name="flitter_showtwitter" />
<literal name="flitter_twitter_via_desc" />
<text name="flitter_twitter_via" />
<text name="flitter_twitter_related" />
<text name="flitter_twitter_related_desc" />
<title name="flitter_google" />
<check name="flitter_showgoogle" />
</settings-page>Assuming the plugin author uses this, it should be able to handle the menu item, the settings themselves, making them searchable and auto-linking it in the plugins area (minimising the need for using the <acp-url> element though not obsoleting it)
The area= part specifies what admin area it should be, the icon is the icon for the dropdown menu, the bigicon is the big icon to use, <load-language> identifies what language file(s) should be loaded when running the page, so that the relevant strings can be loaded. Everything else just correlates to the above.
Personally, I think it's less effort for the plugin developer generally, it's less they have to deal with - you don't expressly have to deal with hooks when doing this and you're still doing less work than you would doing it manually.
Thoughts?
| 1. | Three if you want to make it searchable as well, yup, even that isn't automated. |
