GS Custom Settings [v0.6.2]

[Oleg06]

site in Russian language
site in English language

how to make the language has changed?

[Tyblitz]

how to make the language has changed?

Haha, yes. GS Custom Settings uses its own JSON translation files, merged with the available GS XML translation files. And the 'Save updates' button is a default GS string, so it is translated (there is no Russian translation yet) . 

Btw, if you could make a Russian translation, that would be great and would allow me to test this plugin with non-ANSI characters more easily. The latest translation file is this:

  custom_settings_0.4_en_US.zip (Size: 1.41 KB / Downloads: 4)

[Oleg06]

http://get-simple.info/extend/plugin-lan...tings/924/

[Tyblitz]

http://get-simple.info/extend/plugin-lan...tings/924/

Thanks, that was fast! I will include it in next version. Funny Notepad++ can't properly show Russian language chars. But it looks good in GS.. I tested, everything seems fine; As said, I'll try to allow these characters in the next version (will hopefully be better than the quick patch I posted)

[Oleg06]

in my Notepad ++ encoded UTF-8 looks good

http://get-simple.info/extend/plugin-lan...tings/924/

Thanks, that was fast! I will include it in next version. Funny Notepad++ can't properly show Russian language chars. But it looks good in GS.. I tested, everything seems fine; As said, I'll try to allow these characters in the next version (will hopefully be better than the quick patch I posted)

[Tyblitz]

@oleg Ah I discovered, it's because I had set a custom font in Notepad++ style config (Inconsolata). 

I'm not particularly happy with the patch solution, as that would require Russian, eastern European, Arab, Chinese, etc. to have a crappy workaround for renaming tabs.

UPDATE: 
See http://stackoverflow.com/questions/29722...3#29728633. GS Custom Settings 0.4 will include support for non-Latin characters in the following way:

To keep it ASCII-compatible a word will display correctly in the plugin UI/ output, but will be changed to unicode in the JSON data, eg: Экспорт will become:  \u042D\u043A\u0441\u043F\u043E\u0440\u0442. The only downside (if any) is that, eg. Russian users have to pass the raw data file through a unicode converter if they want to be able to read it properly.

[datiswous]

Maybe add a date setting type. When you click you get a calendar where you can set date, or something like that.

[Tyblitz]

Maybe add a date setting type. When you click you get a calendar where you can set date, or something like that.

Thanks for your suggestion, but you can use the regular text setting to output anything you like + in the format you like.
Besides, a datepicker would mean having to provide different settings for different countries to have a convenient date format in the UI. Could you post a use-case for site-wide date settings where the text setting falls short?

(NB: This is also the reason I haven't implemented a URL field, because you can already achieve this with the text setting)

[shawn_a]

Why not use html5
http://www.wufoo.com/html5/types/4-date.html
http://www.wufoo.com/html5/types/3-url.html

at least they will have types..
if not good enough someone can always shim it or replace it with a jqueryui alternative if they chose

[Tyblitz]

Why not use html5
http://www.wufoo.com/html5/types/4-date.html
http://www.wufoo.com/html5/types/3-url.html

at least they will have types..
if not good enough someone can always shim it or replace it with a jqueryui alternative if they chose

I beg to differ: please see quirksmode. Almost all HTML5 inputs or their attributes do not work in at least 1 and often 2 major browsers. GS supports old PHP 5.1 servers, so I think it is in line with the CMS' philosophy to fully support older browsers up to IE8. The only candidates I see for now are the number and range inputs, but as still that could be achieved with the text setting I fail to perceive their added value.

[shawn_a]

Not my point, if you want to shim old shitty browsers then you can still do so since they will have data types, if they are text then you cannot detect which is date etc. also adding support for 80%?of browsers with no code is a pretty good deal, that site also shows the browser support , gs will not support old browsers as of 3.4 any way.

If someone wants to add their own plugin for polyfilling these they can do so on their own.
https://github.com/Modernizr/Modernizr/w...-Polyfills

[Tyblitz]

Not my point, if you want to shim old shitty browsers then you can still do so since they will have data types, if they are text then you cannot detect which is date etc. also adding support for 80%?of browsers with no code is a pretty good deal, that site also shows the browser support , gs will not support old browsers as of 3.4 any way.

If someone wants to add their own plugin for polyfilling these they can do so on their own.
https://github.com/Modernizr/Modernizr/w...-Polyfills

I'll add the suggestion to the Github issue tracker, but can't consider it a priority. I'm working on theme settings documentation now and there are more important updates to be made first, amongst them:

• Support for Cyrillic & other charsets
  
• Support for I18n-enabled fields (with I18n plugin)
  
• An image browser for the image field
  
• Automatic theme settings update (currently manually)
  
• A way to set tab lookups separately from the UI
  

I'd also need some testing with plugins, working on that too (GSconfig shim)

[shawn_a]

What problem are you having with cryllic characters?

[Tyblitz]

What problem are you having with cryllic characters?

See this thread #31. Basically I checked to validate tab lookups with the JS regex operator \w in v0.3, which doesn't recognize cyrillic chars as word characters. And now I am pondering whether I should:

1. only allow ASCII chars for the lookups, not change the UI, and use a solution like the temporary one in this thread #27 for eg Russian users.
   
2. Allow anything & only lowercase it + replace spaces with underscores as it doesn't matter because JSON can contain any chars (but the non-ASCII chars are converted to unicode codes, eg \u043) 
   
3. Solution #1 but with a field to allow setting the tab lookup separately (instead of being based on the tab label)
   

[datiswous]

Feature idea: If you implement settings, you now get one list of settings for every tab. It would be nice to be able to divide these settings into sections. Maybe with fold-in fold-out function.

For example theme settings, where you want a different section for head, header, footer, etc.
Also if you have multiple template files. Some way of organizing would be nice.

[Tyblitz]

Feature idea: If you implement settings, you now get one list of settings for every tab. It would be nice to be able to divide these settings into sections. Maybe with fold-in fold-out function.

For example theme settings, where you want a different section for head, header, footer, etc.
Also if you have multiple template files. Some way of organizing would be nice.

That's a very good suggestion! You can already subdivide tabs with 'Section titles' but not yet making them foldable. I'll like to implement this in v0.5. Added to Github issues, so on my task list

[datiswous]

...You can already subdivide tabs with 'Section titles'

Hah, I missed that. Works really well.

Really nice plugin, great ui also. I like how you can change theme setting by changing classes, for example.

[Tyblitz]

Thanks @datiswous, I put a lot of time and effort in it. 

Just as a spoiler:
v0.4 will include support for multilingual settings, (limited) support for Cyrillic characters, more consistent keyboard shortcuts and PHP functions, as well as an in-app plugin update notification, more extensible JSON data, and a good amount of bugfixes.

Together with v0.4 I will publish a (really) giant tutorial divided in small cases for theming that will demonstrate the full potential of GS Custom Settings, along with a small sample theme to test it. As you mentioned, outputting classes is one option. 

@shawn_a, work on a GSCONFIG UI shim is almost finished, and will also, together with v0.4 release the plugin in the Extend section, all this probably in 2-3 weeks.

[datiswous]

Something I don't like at the moment:

I can't see the full code line in the admin. Have to copy the text to text-editor or something to see fully.
This is the same for the (image/web) urls. A tooltip hover would already be an improvement.

There are some other element in the ui which have also a limited size.




Some idea: Setting an image for a setting state. So if you activate a certain setting (for example background color or css file) you see this change in example image (could be a screenshot of the site, or a screenshot of a font, or something). This way you could make a more visual orientated setting panel.

Another idea: Group settings together. Normally you can set one setting and place it somewhere, but maybe you have a group of settings, which do a certain thing. 
You can also choose to use tags / categories with which you can group settings. Maybe you can add that as an option to the Section Title function.

[Tyblitz]

Something I don't like at the moment:

I can't see the full code line in the admin. Have to copy the text to text-editor or something to see fully.
This is the same for the (mage/web) urls. A tooltip hover would already be an improvement.

There some other element in the ui which have also a limited size.


Some idea: Setting an image for a setting state. So if you activate a certain setting (for example background color or css file) you see this change in example image (could be a screenshot of the site, or a screenshot of a font, or something). This way you could make a more visual oriëntated setting panel.

Thanks for your feedback.
About 1), yes I agree, I might think of stripping out the  PHP / content filter tags so you only see the lookup, and I'll implement your suggestion about the tooltip in the upcoming version already (0.4). A temporary workaround is to set GSSTYLE in gsconfig.php to GSSTYLEWIDE (which will increase the code input's size considerably, as well as the setting fields).

About 2) I think I get what you mean, though I admit this will be hard to implement if it is to be completely automatic, and where would that image be?. In the meantime, in v0.4 the setting descriptions will be allowed to contain HTML, so you could have a workaround by using JS inside an HTML attribute.

For example, if you had a setting for image size, with type text which accepts values like 100x300, you could set the setting's description like below, which will output an image in the setting's description & update the image size with the setting's value everytime it is changed:

Code:

<img src="http://placehold.it/256x256" id="my_setting-img" onload="(function() { $('#my_setting-output').on('change', function() { var src = $('#my_setting-img').attr('src'); $('#my_setting-img').attr('src', src.slice(0, src.lastIndexOf('/')+1) + $('#my_setting-output').val()); }); }())">

As for grouping settings: dear me, you can read my thoughts! In v0.4 you will be able to use return_setting_group($tab, $group, $prop=NULL) where $group = a prefix on multiple settings, separated by an underscore (eg in social_facebook & social_twitter, the 'group' would be 'social') in PHP, but for the plugin UI I'm not sure it would be a benefit + it's already easy to move settings around in the multi-select Edit mode.

[datiswous]

Good to hear about the improvements in v0.4


I have an issue with the export and import function. Can't get it to work at all. It also seams impossible to actually delete a tab. If I do that, it is not removed.
I want to supply the exported tab with a theme I made in the past (I mean converted for GS), included is a big list of css files (called skin.css), so it's easy to change the skin. It's very easy to make this work with GS Custom Settings, but it's a shame I can't include an export in the theme.

[Tyblitz]

Good to hear about the improvements in v0.4

I have an issue with the export and import function. Can't get it to work at all. It also seams impossible to actually delete a tab. If I do that, it is not removed.
I want to supply the exported tab with a theme I made in the past (I mean converted for GS), included is a big list of css files (called skin.css), so it's easy to change the skin. It's very easy to make this work with GS Custom Settings, but it's a shame I can't include an export in the theme.

Those are important issues and I'm kind of surprised, I rigorously tested this.. Can you clarify a bit?
What browser and version are you using? (import requires IE10+ or other browser)
What data did you try to export? (all site settings, theme settings, or one site tab)
Or did you mean 'export' as in 'Export as theme/plugin' ? 
When you try to delete a tab which has at least one setting in it, do you get a confirmation message?

Could you eventually repeat those actions, but open the browser console first and see if there is any JS error?

NB: in the meantime you can do those changes manually by going to /data/other/custom_settings/data.json and deleting the tab there, and copy paste the tab you needed into a new file for your theme.

[datiswous]

Those are important issues and I'm kind of surprised, I rigorously tested this.. Can you clarify a bit?
What browser and version are you using? (import requires IE10+ or other browser)
What data did you try to export? (all site settings, theme settings, or one site tab)
Or did you mean 'export' as in 'Export as theme/plugin' ? 
When you try to delete a tab which has at least one setting in it, do you get a confirmation message?

Could you eventually repeat those actions, but open the browser console first and see if there is any JS error?

I use Chrome 42

When I try to import an export I exported via Export ->tab name  I get the following error:

Error: Import aborted. The plugin for the imported settings is not activated.

This is only with a specific tab I created. This is the tab options of type Radio (icon)

Code:

                               "/css/skin.css",
                "/css/aim/skin.css",
                "/css/bigcoloridea/Blue/skin.css",
                "/css/bigcoloridea/Dark-Blue/skin.css",
                "/css/bigcoloridea/Orange/skin.css",
                "/css/bigcoloridea/Pink/skin.css",
                "/css/bigcoloridea/Purple/skin.css",
                "/css/bigcoloridea/Red/skin.css",
                "/css/blackberry/skin.css",
                "/css/fresh/skin.css",
                "/css/fruitjuice/skin.css",
                "/css/glimpse/skin.css",
                "/css/humble/skin.css",
                "/css/illusion/skin.css",
                "/css/isimple/skin.css",
                "/css/liner/skin.css",
                "/css/maple/skin.css",
                "/css/mentol/skin.css",
                "/css/moderndark/Blue/skin.css",
                "/css/moderndark/Green/skin.css",
                "/css/moderndark/Orange/skin.css",
                "/css/moderndark/Pink/skin.css",
                "/css/moderndark/Purple/skin.css",
                "/css/moderndark/Red/skin.css",
                "/css/moderndark/Yellow/skin.css",
                "/css/nightroad/skin.css",
                "/css/passion/skin.css",
                "/css/simplesoft/skin.css",
                "/css/simpleswiss/skin.css",
                "/css/simploid/skin.css",
                "/css/snobbish/skin.css",
                "/css/solution/skin.css",
                "/css/stylus/skin.css",
                "/css/teawithmilk/skin.css"

I found out that I have te click Save Settings at the bottom after deletion, which isn't entirely logical to me. Sorry if I missed this in your documentation. This is the same with changing tab order, etc.


Edit: I didn't read the info about theme settings file settings.json and that it works differently than the import function.

[Tyblitz]

Yes good point, I should clarify that you have to click Save updates after every change, as a final confirmation. That's because this plugin is heavily front-end based (the JS architecture is more complicated than the PHP).

An explanation of the 2 different exports:

• Export button in the nav at the top: for site managers who wish to backup their settings, or transfer them to another installation.
  
• Export as plugin/ theme: for plugin/ theme devs; prepares a file called settings.json with all the current tab's settings, ready to be placed in the plugin dir.
  

As for the error with import, what is the name of the imported file? This error should only come if (1) the file is named plugin_data_plugin_name.json and (2) you have created a GS Custom Settings plugin which is not activated when you did the import (you should activate before importing).

[Tyblitz]

GS Custom Settings v0.4 released

Awesome new features for theme & plugin devs

• Instant PHP & other changes - v 0.4 adds a custom-settings-save hook, which allows you to act upon settings right after a user clicks the 'Save updates' button, but before they are saved to the files. Why is it awesome? Because it allows a plugin to make immediate changes to files multiple times, without requiring a page reload!
  
• Return a batch of settings at once - v 0.4 adds a return_setting_group($tab, $group, $prop) function, which allows you to retrieve a batch of settings in one function call.  You make a setting group by prefixing settings with a common 'word', eg. to get both settings social_facebook & social_twitter, you would do $social = return_setting_group($tab, 'social') and get an array('facebook'=>'your_fb_link', 'twitter'=>'your_tw_link'). Because the prefix is stripped, you can now get the setting by doing $social['twitter']
  
• Automatic version updates - Worried about complicated update instructions for your custom settings every time you release a new version? No longer: v0.4 compares a plugin's version with the version stored in the data, and updates 'old' settings to the newer version. The only requirement is adding a version property in your plugin's JSON file, in the tab object.
  
• I18n-enabled settings - Yes, you can now even provide I18N-enabled text/ textarea settings with your own theme or plugin (useful for output). If the user doesn't have I18n (with I18n plugin by Martin Mvlcek) enabled, they will show as simple settings, else they will hold a value for each language on the installation. Use the new get_i18n_setting($tab, $setting, $echo=TRUE) function to echo the output, or return it (if $echo === FALSE).
  
• Custom setting properties - Apart from the default setting properties, you can now include your own custom properties on each setting (not through the UI, only by editing the JSON files). This basically means extra storage room to associate keys and values, or other info, with a setting.
  
• Limited support for non-ANSI chars (Cyrillic, Latin Extended; use at own risk for lookup properties)
  
  

UI Enhancements

• Consistent keyboard shortcuts - All previously active keyboard shortcuts are replaced with a combination of Ctrl + Key:
  • Search - Ctrl + F
    
  • Edit mode > Add x settings - Ctrl + Enter (x = amount of selected settings)  
    
  • Edit mode > Delete selected settings - Ctrl + Delete
    
  • Edit mode > Move selected settings up - Ctrl + arrow up
    
  • Edit mode > Move selected settings down - Ctrl + arrow down
    
• Tab lookups to be set manually from the tab toolbar
  An extra 'tag' icon is added to the tab toolbar which toggles the tab's label (default)/ lookup. The lookup is still automatically computed from the label when it is added, until the user manually changes the lookup. 
  Why? - Ease of use as well as flexibility.
  
• Help button '?' with plugin links, new version download, & translator credits
  

Plugin changes

• return_setting($tab, $setting) returns the value instead of full setting
  In < v0.3 return_setting($tab, $setting) returned the full setting, now it is shorthand for return_setting($tab, $setting, 'value'). Instead of omitting the third optional parameter $property, you should now do return_setting($tab, $setting, FALSE) to get the full setting (false => no property selected, so all properties returned).
  Why? - Because the primary use of this plugin atm is for theming and value checking, not full settings (mostly in plugins).  
  

NB: The docs still need to be updated