Note: The code in this reply is no longer relevant
True that. I was thinking more about providing for theme developers/ webmasters than plugin devs. I did hint to this in the better components thread, and I will try to add this in one of the next releases. Basically, there's not much else to do than add a function similar to this:
I am still torn on one issue though; for which I'd love to have some feedback. Currently the setting lookups are PHP-ified from the setting's label, while in i18n custom fields for example, the user has to write his own lookup ('name'). I did this to eliminate an extra step of 'thinking', but I understand some lookups could get ridiculously long if the label is too descriptive. On the other hand, there's a per-setting description to explain the label... And as a second point, given that the strings are saved in JSON, they could actually contain almost any character without errors... Should I allow such things as?
(2015-02-19, 04:43:21)shawn_a Wrote: Looks promising.
It would be nice to be able to interface with this programmatically via a plugin, it would be very easy to write a bridge function to check for and use this instead of writing your own settings manager in my plugin, or using globals etc like, newsmamager does. I could even use this to make a plugin that shims gsconfig with a ui.
We could also add per component extra hooks, to add these to individual components, in 3.4
True that. I was thinking more about providing for theme developers/ webmasters than plugin devs. I did hint to this in the better components thread, and I will try to add this in one of the next releases. Basically, there's not much else to do than add a function similar to this:
PHP Code:
function add_setting($setting) {
$path = 'path/to/file';
$file = json_decode($path, TRUE);
$properties = array('label','lookup','access','type','options','value','descr');
$final = $setting;
for ($x = 0; $i < count($properties); $i++) {
if (!array_key_exists($properties[$i])) {// OR if value is not correct
// set defaults & validation here
$final[$properties[$i]] = $someDefault;
}
}
array_push($file['data'], $final);
$file = json_encode($file);
file_put_contents($path);
}
I am still torn on one issue though; for which I'd love to have some feedback. Currently the setting lookups are PHP-ified from the setting's label, while in i18n custom fields for example, the user has to write his own lookup ('name'). I did this to eliminate an extra step of 'thinking', but I understand some lookups could get ridiculously long if the label is too descriptive. On the other hand, there's a per-setting description to explain the label... And as a second point, given that the strings are saved in JSON, they could actually contain almost any character without errors... Should I allow such things as
Code:
get_setting('social/I am a really long label?!')
(2015-02-19, 05:18:15)Oleg06 Wrote: does not workWhat does not work? I tested and it works all fine now.