module General site settings module

[szabesz]

On 10/13/2016 at 0:06 PM, titanium said:

Great module, pmarki 

Any chance to provide a file/image field for storing site-wide logos etc.?

Hi @titanium,

You might want to consider doing it in a different way, by creating field+pages for such settings, for example like this:

http://processwire-recipes.com/recipes/create-custom-admin-settings-page-link-in-admin-menu/

Quite a different approach for sure but it might work for you.

[PWaddict]

The checkbox value is broken. Checked or Unchecked it always echo "1". Please fix it. Thanks.

[pmarki]

On 17.12.2016 at 8:38 AM, PWaddict said:

The checkbox value is broken. Checked or Unchecked it always echo "1". Please fix it. Thanks.

Fixed now, Thanks @PWaddict

[PWaddict]

2 hours ago, pmarki said:

Fixed now, Thanks @PWaddict

Thanks for the quick fix. I'm trying to update the module via ProcessWireUpgrade but when I check if there is a new version it still says that the latest is the one I'm currently using the 1.1.2. Any idea why it doesn't show me the 1.1.3 version to update? 

[pmarki]

1 hour ago, PWaddict said:

Thanks for the quick fix. I'm trying to update the module via ProcessWireUpgrade but when I check if there is a new version it still says that the latest is the one I'm currently using the 1.1.2. Any idea why it doesn't show me the 1.1.3 version to update? 

PW refreshes versions once a day, so you have to wait or update manually.

[kongondo]

5 hours ago, pmarki said:

PW refreshes versions once a day, so you have to wait or update manually.

Or you, the module author, can click to edit the module and save (no need to make changes), and PW will fetch the latest version immediately.

Edited December 18, 2016 by kongondo
typos

[Macrura]

Just testing this out now... it's really great! Going to use this on all sites from now on.

One thing i'm testing is that i changed the CSS to show the json for the settings.

Then i added a field called settings_import:

        $field = wire('modules')->get("InputfieldTextarea");
        $field->attr('name', 'settings_import');
        $field->attr('id', 'settings_import');
        $field->label = __("Import Settings Config", __FILE__);
        $field->attr('value', $data['settings_import']); 
        //$field->columnWidth = 34;
        $field->collapsed = Inputfield::collapsedYes;
        $fields->append($field);

then i added this, right after this line
222 $json = (isset( $data['settings'] )) ? json_decode($data['settings'], true) : '';

		if(isset($data['settings_import']) && $data['settings_import'] != '') {
			$json = json_decode($data['settings_import'], true);
			$data['settings'] = $data['settings_import'];
			$data['settings_import'] = '';
		}

now i can import all of the settings from one site to another without having to re-create them...

 

[Macrura]

There is a somewhat major issue with the module that should be changed asap - this module sets a global variable for 'settings' which is also used by ProcessPageListerPro.

Consequently if you have this module installed and you are using PageListerPro, all of your listers will suddenly appear to be broken, until you change the global variable in the settings for this.

However it is probably too risky to leave this module with using that 'settings' variable. i would recommend to make it something more unique and less likely to have collisions - i am using 'site_info' for now since i doubt that would collide with anything, and also since this module deals with settings that will presumably be used on the frontend, it makes sense to use the word 'site' in there somewhere...

[Robin S]

45 minutes ago, Macrura said:

There is a somewhat major issue with the module that should be changed asap - this module sets a global variable for 'settings' which is also used by ProcessPageListerPro.

In the first post:

On 31/08/2016 at 5:23 AM, pmarki said:

You can change global name ($settings) to something else in module configuration.

I take this to mean the onus is on the user to choose some suitable global variable name. Whatever you choose could potentially overwrite another variable, or itself be overwritten in a template if you're not careful. Maybe the module needs its own namespace?

[Macrura]

yes, you can change that but most people probably won't realize why their listers all broke, so the default within the module code should be changed.

not sure if it needs own namespace, because you just want to be able to get and set your global settings in a quick and easy way;

plus i have module that then uses this module's settings basically wraps the settings for things like meta tags.. prior to this i always set my settings as part of $config which may be safer, because then you are 1 down from the top level... so another option would be to have this module use like $config->settings instead of being top level; since i have abstracted my calls to the vars through my intermediary module, the global name can change at any time without affecting my template output b/c my module looks for whatever the global name is and then refers to that in all of the output methods...

[adrian]

I kinda also wonder if that $settings variable should be changed in ListerPro - seems like it should be $listerSettings or something?

[Macrura]

i do agree - i think modules should probably prefix any global variables with something that won't risk being overwritten...

[szabesz]

6 hours ago, Macrura said:

i am using 'site_info' for now

It's "funny" you chose the prefix "site_" because I always use it to prefix my identifiers in my "custom code" to indicate that it is my piece of code and not part of the core nor any other modules. Maybe I should switch to a less used word, such us "plat" or whateverv people would "never" use.

[Macrura]

Here are some preview screenshots from my pimped out version of this module...

1) Added the placeholder and collapsed attributed to the fields editor:

 

2) allow export of the fields setup, as well as restore, so that you can take huge sets of fields and import them into a site.

 

3) ability to export/backup the settings values themselves, as well as restore them from backed up json.

 

still need more testing, but so far these things help make this module more usable; also i changed the default global api variable to g_settings, to avoid the conflict with Lister Pro.

 

[tpr]

I do not use this module but these mods are looking great. How about adding the labels to the left of the fields? that would make the form look less crowded and easier to overview. I'm not sure whether the markup allows easy style update.

[Macrura]

the style would be easy to update; also i'm hoping to be able to enable fieldset close and also fieldset tab open/close so you can make some pretty extensive settings pages with this.

the process page basically renders a standard pw form, using the json data you configure through the module interface; the whole setup is super clever, @pmarki nice job...

also i'm hoping to have some prebuilt sets of fields that can be imported to get started with a lot of standard type settings; possible 'field setting profiles' like home business, corporation, education etc, and then it would populate with a lot of fields needed to configure and edit stuff like Schema..

[szabesz]

It would be cool if the two of you could maintain this module. So far I've been hesitant to use it, but it's nice to see all the effort you are putting into it. Thanks!

[Macrura]

@szabesz i think it is fine to use, i first tested it on localhost, and then i started using it on 3 new sites; i did change the module to not use the 'settings' global variable though before installing it, because as far as i can tell, it somehow actually causes the listers in lister pro to all lose their settings; have not tested extensively yet, so i don't know if it happens only if you load the listers... i will most likely fork the module and then change out my new versions... there are still some things to iron out before it could be considered really stable, with the fields and settings import features..

[szabesz]

Thanks @Macrura for the info. I can live without such a module, but I see that it can be helpful in order to simplify things so I might start using it as it looks useful. I prefer modules being maintained, so I'm a bit cautious in cases like this, and that is why I'm happy to see you improving it

[gmclelland]

 

@Macrura You might not need the json export/import functionality anymore.  See this new module 

 

[Macrura]

@gmclelland, yeah, you are right, i will probably remove that functionality from my version, and defer it to that module

[theoretic]

Hi there! And thanks for Processwire!

Would like to propose an extension of this module. Sometimes it could be very convenient to update settings dynamically and then to save them.

A practical example: currency rates for a multi-currency shop. It's logical to store rates as general settings. But it's also logical to make a script which gets the actual rates from external website and then re-saves them. Some mockup code:

$currencies = ['AUD','GBP'];
$currencyRates = [];

//getting currency rates skipped

foreach( $currencies as $currency )
	$settings->$currency = $currencyRates[$currency];

$settings->save();

Unfortunately there's no save() method in the original ProcessGeneralSettings.module , so i had to write it:

	public function save() {
		$old = $this->data;
		$data = json_decode($old['settings'], true);
		$new = array();
		foreach ($data as $key => $field) {
			$new[$key] = $field;
			$new[$key]['value'] = $old[$field['api']];
			}

	$old['settings'] = json_encode($new);
	wire('modules')->saveModuleConfigData($this, $old); 

	return $this->data;
	}

Have tested it, works like a charm. Would like to merge it into the official module.

[adrian]

@theoretic - have you had a look at @Macrura's new module: https://processwire.com/talk/topic/17458-settings-train-module-preview-all-aboard/?

Maybe this will take care of your needs?

[theoretic]

@adrian, thanks for that! Didn't know about that module. I'm rather impressed by @Macrura 's work, but currently it's a bit overkill for me. The only thing i needed beyond the standard ProcessGeneralSettings functionality was the ability to save the changed settings.

By the way, is there a possibility to access $settings from inside functions, modules etc?

[Macrura]

wire(‘settings’) in func/module