Module Settings Import / Export

[adrian]

Just posting a teaser at the moment because I am not yet sure if this should be a standalone module, or part of the still unreleased Module Toolkit (https://processwire.com/talk/topic/8410-module-toolkit/).

Now available here: https://processwire.com/talk/topic/15702-module-settings-import-export/

It is quite simple in its execution - it adds a Settings Import / Export collapsed fieldset to the top of the module settings page of all modules.

You can copy settings from one install and paste into another and click "Import Settings". It works quite like PW's core template and field import/export functionality.

Simple as that

PM me if anyone is keen to try it before I decide where and how it should be released.

Settings are automatically saved when you uninstall a module, so you have an easy way to restore them when you uninstall.

Anyone have any thoughts on any of this?

 

[tpr]

What I don't know currently that what happens if a module is updated and some of its fields are renamed or removed. Do old fields remain in the module after re-importing old settings, or will they skipped on save?

[BitPoet]

4 hours ago, adrian said:

I am also thinking about automatic storing of module settings during uninstall (like @tpr is now doing with AOS) of all modules. During a re-install, the stored settings would be automatically imported. I think this functionality might also belong in Module Toolkit.

Can I leave a vote to make the restore optional?

@tpr: the topic also came up here. Currently, PW carries over old field settings infinitely, though it might be worth a thought to make PW core (Modules::saveConfig) forget no longer applicable field values.

[horst]

I'm a bit unsure if PW should automatically forget about old settings. I would like to see that the module authors handle this case by case with the upgrade method! This way, nothing will get lost when it shouldn't.

[LostKobrakai]

I think forgetting settings by default is the most clean way (on uninstall), but there should probably be ways to let developers choose different paths if needed. Maybe "deactivate" could be a non destructive way to disable a module, whereas "deinstall" is the clean sweep, where everything is removed.

[tpr]

30 minutes ago, BitPoet said:

Can I leave a vote to make the restore optional?

I've added a checkbox to opt-out from automatic restore in my module.

[adrian]

Just been toying around with this a little more. 

You can now backup the settings for any module anytime you want using the "Backup Current Settings" button. You can also "Restore Settings from Backup" at any time. 

By default it automatically backs up the settings of any module when it is uninstalled, but you can turn this off if you want. Even with it on, restore on reinstall still has to be manually triggered anyway, so probably no real reason to turn off.

And of course you can still manually import settings that you have pasted in from another install.

Anyone have any further thoughts?

In particular I am looking at @tpr (AOS) and @horst (ALIF) because they are the two module authors who I know have built some sort of dedicated settings backup / migration into their modules. Do you think it would be weird having this module installed and adding this functionality on top of what you have already built into your modules? I guess ideally if this functionality was in the core it wouldn't be an issue because you'd know that everyone has access to it, so no need to build it in.

 

[szabesz]

3 hours ago, adrian said:

I guess ideally if this functionality was in the core it wouldn't be an issue because you'd know that everyone has access to it, so no need to build it in.

So true

[szabesz]

@adrian One question: how can this module deal with dissimilar settings? I mean when settings of an older version of a module are different from the newer one? In module development, one usually has to implement an upgrade procedure to account for possible db storage differences, I guess something similar is needed in this case too. Am I missing something?

[adrian]

31 minutes ago, szabesz said:

@adrian One question: how can this module deal with dissimilar settings? I mean when settings of an older version of a module are different from the newer one? In module development, one usually has to implement an upgrade procedure to account for possible db storage differences, I guess something similar is needed in this case too. Am I missing something?

That's a good point - this isn't foolproof for sure. Remember though that it's only config settings that are being exported/imported (which are stored in a json object in the "modules" db table), so nothing should be critical - there are no db schema impacts or anything. New settings should be added in when saving the settings page again.

I guess an option to mitigate any confusion might be to add the version of the module to the json file so that it can be compared on import and if the version is different then warn that there might be new settings might be lost and should be reviewed.

The other issue to consider is when a module's config settings reference a page, template, or field - these won't match on different PW installations because their IDs will be different. Nothing can really be done about this. I guess I am just trying to make configuring of complex and commonly used modules simpler. Maybe there is no complete solution possible?

[szabesz]

Thanks! You are right, and missing page ID references can also be included in a list of detailed warnings. If we have a list with all the details that need attention, we can just review them one by one and that is helpful enough, I think.

[BitPoet]

9 hours ago, adrian said:

I guess an option to mitigate any confusion might be to add the version of the module to the json file

The quote above reminded me of something I tried a while ago:

<?php

/**
 * Keep track of module config versions in ProcessWire.
 * Allows smooth upgrading of module versions when configuration
 * options change.
 */

class ModuleConfigVersion extends WireData implements Module {
	public static function getModuleInfo() {
		return array(
			"title"			=>	_("Module Config Verisons"),
			"summary"		=>	_("Store module version in config to allow smooth upgrading."),
			"version"		=>	"0.0.1",
			"autoload"		=>	true,
		);
	}
	
	public function init() {
		$this->addHookBefore("Modules::saveConfig", $this, "hookSaveConfig_SetVersionProperty");
	}
	
	public function hookSaveConfig_SetVersionProperty(HookEvent $event) {
		$module = $event->arguments(0);
		$data = $event->arguments(1);
		
		$moduleInfo = $this->modules->getModuleInfo($module);
		$version = $moduleInfo["version"];
		
		$data["version"] = $version;
		
		$event->arguments(1, $data);
	}
}

This automatically adds the version each time a module's configuration is saved.

[adrian]

Module has been released and now available over here: