Jump to content

General site settings module


pmarki

Recommended Posts

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.

  • Like 2
Link to comment
Share on other sites

  • 2 months later...
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? 

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

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...

 

  • Like 2
Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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...

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

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

58af326430ada_Modules__ProcessWire__localhost.jpg.18febb957336cac5087845a14dead293.jpg

 

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.

58af325d22742_Modules__ProcessWire__localhost.jpg.5515eb560d85ff3af3cf832c9c50f937.jpg

 

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

58af32541997d_General_settings__ProcessWire__localhost.jpg.b2476470ad45556ceade0e10fdce6be6.jpg

 

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.

 

  • Like 6
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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..

  • Like 3
Link to comment
Share on other sites

@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..

  • Like 2
Link to comment
Share on other sites

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 ;)

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...
  • 7 months later...

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.

Link to comment
Share on other sites

@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?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...