Settings Factory

[dragan]

@Macrura First of all: Thanks for this great module. I noticed it already when you first released it, but because there was no real for it in my own projects, I never installed it till now.

I found a confusing behavior (bug?) when I use the kitchen sink example.

No matter what email address I try, PW always shows me an error: "InputfieldEmail: Please enter a valid e-mail address - Email Test"

It doesn't matter if I use a real, existing email, or just a semantically correct one.

What's even more strange is that this red error shows up on every page in the PW admin - literally everywhere.

Am I missing something obvious? PW throwing an error if a required field is empty or doesn't match some regex rules is one thing, but that should only be visible in the respective page-edit screen, not globally? The only thing I noticed: There is no "autoload disabled" checkbox in module/edit?name=ProcessSettingsFactory

I'm using SF 1.0.3 and
ProcessWire: 3.0.149
PHP: 7.3.13
Webserver: Apache/2.4.35 (Win64) OpenSSL/1.1.1d
MySQL: 5.7.24

Edited January 22, 2020 by dragan
added screenshot

[Macrura]

strange that you'd be running SF 1.0.3 as the 1.0.4 version has been out for over a year- can you double check it is version 1.0.4?

This is the 2nd report of this issue, and i have not been able to reproduce it – are you using the kitchen sink JSON or PHP version (shouldn't matter though).

If I can reproduce this, i think it can be fixed - but i'm not clear where to look;

I guess once you confirm it is 1.0.4, or upgrade to that, if the problem persists, i will keep trying;

I'm running tests on PHP 7.3.1, PW 3.0.148, MySQL 5.7.25

 

[dragan]

@Macrura I'll try and give some more information.

Version: it seems SF installs actually two modules. One is v. 1.0.4, the other 1.0.3. Since I just installed it 1-2 days ago, it's unlikely I accidentally picked an old version.

I'm using the JSON kitchen sink version.

I de-installed SF y'day and installed again today. The same issues persist.

I attached a few screenshots.

before installing:

after installation:

after installation, under modules (notice versions 1.0.3 + 1.0.4)

Trying to update process SF:

editing the page under /admin: the page I entered for the JSON is 100% correct:

Thanks a lot for looking into it.

 

[Macrura]

So the issue is simply that in multilanguage environments, it seems to behave differently; all you need to do is change the value from "0" to an empty string and it should solve this. I will update the kitchen sink example to fix this in multilang environs.

it should be pointed out that what this module really does is to basically use all core functions for rendering the fields; So in this case the issue was really stemming from how the field was being defined, and we didn't catch it because we didn't test the kitchen sink file in multilang.

[Macrura]

this also does bring up whether the settings should be always processed on every admin page load, or if the settings loading should be skipped in admin;

[Frank Vèssia]

Hello @Macrura, great module.
Can you please tell me a way to store a setting value using API instead of writing it in the setting page manually? thanks

[Macrura]

@Sevarf2 - I was able to successfully do that by adding a custom setConfigDataCustom method to the module, but this would be a beta feature until it is tested further. I'm not totally sure if i'm doing it the best/right way, so this was just a quick test, but it did work.

However the api is not so intuitive for this currently as you first need to get the settings array for the key, then alter the value of one of the items, or add a new item (not tested) and then write the whole array back to the module

$factory = $modules->get("SettingsFactory");
$mySettings = $factory->getSettings('wiretabs-testing1',false); // return array not wiredata
$mySettings['settings_client'] = 'Jimmy James 4th';
$factory->setConfigDataCustom('wiretabs-testing1',$mySettings);

I think it might also be possible to write settings to the module that don't have process pages, using this, but not sure how useful that is, i assume that it will be possible since the settings are just module config, so you'd be able to store anything you'd want in those arrays...

If you can elaborate on the use case for this that might help to determine the best way to implement it.

[Frank Vèssia]

thanks for the quick reply.
I have 2 parameters , api Client ID and api Client Secret of a rest api i'm accessing to retrieve some data. I insert those values manually one time. Now, when I use the API I'm getting in return another value, a PolicyKey (for another request) that I need to store for 6 days until it changes again, so I would like to store this value with the other two in the settings panel and I cannot insert it manually

[Macrura]

ok thanks - i think it can be done no problem, but i think the api should be cleaner where you don't need to deal with setting array values; i'll have to post back once i have a working prototype.

 

[Macrura]

@Sevarf2 If you want to test this, you can add the following code to the module at the end of "SettingsFactory.module".

	/**
	 * @var $key - the settings key
	 * @var $_key - the setting within the key
	 * @var $value - the new value
	 */
	public function changeSetting($key,$_key,$value) {
		$modData = $this->modules->getConfig('SettingsFactory');
		if(!array_key_exists($key, $modData)) return;
		if(!array_key_exists($_key, $modData[$key])) return;
		$modData[$key][$_key] = $value;
		$this->modules->saveModuleConfigData('SettingsFactory', $modData);
	}

and then this would be the way to change the setting from api:

$factory->changeSetting('wiretabs-testing1','settings_client','new value');

in limited testing this has worked fine, but i'd recommend a few more tests before using on production. I haven't commited this to the master yet - it probably needs to include a check to ensure the target key exists in this case.

This also illustrates that it would be possible to add settings (addSetting), but since the fieldset is defined in a hard file, any settings added in the api would not be editable in the admin, so not sure if that would be useful.

[Frank Vèssia]

thanks, that's great, I will add the code and test it

[Macrura]

@Sevarf2 - just updated the code to ensure that both the settings array and the key within the array exist. (This would prevent inadvertently adding a settings array or setting if the key is typed incorrectly), if they don't it will ignore the changeSetting() call.

[Martijn Geerts]

@Macrura First of all I love SettingsFactory!

I've seen notices before in SettingsFactory when I add new fields but not yet saved the value.
In this complicated setup I have here this notice prevents the PageList from being loaded.

SettingFactory->getSettings() triggers the notice on line 152.

// Locally i have changed the if statemaent on line 151:
} else {
	$newDataArray[$key] = $dataArray[$key];
}

// To this:
} else if (isset($dataArray[$key])) {
	$newDataArray[$key] = $dataArray[$key];
}

Without looking much in to this, this fixes it for me.

 

[Macrura]

@Martijn Geerts - many thanks for taking the time to make the fix here!

I will implement is and do some tests and update the module soon.

 

[Frank Vèssia]

On 6/5/2020 at 10:43 PM, Macrura said:

@Martijn Geerts - many thanks for taking the time to make the fix here!

I will implement is and do some tests and update the module soon.

 

Any update? I can't download the module, even from github, it's no longer available?

[teppo]

13 minutes ago, Sevarf2 said:

Any update? I can't download the module, even from github, it's no longer available?

Looks like GitHub itself is down right now, so this probably has nothing to do with SettingsFactory ?

[Frank Vèssia]

Just now, teppo said:

Looks like GitHub itself is down right now, so this probably has nothing to do with SettingsFactory ?

Ops, didn't check github itself...thanks ?

[Macrura]

13 hours ago, Sevarf2 said:

Any update? I can't download the module, even from github, it's no longer available?

Hi @Sevarf2 - i haven't tested the mod, so was hesitant to commit the change, but i should be able to do it this week. Are you having the same issue as Martijn?

[Frank Vèssia]

Hi, it's ok, it was just the fact that github was down and I didn't notice it, so I thought you kind removed the module for some reason / imminent update, sorry ?

[gornycreative]

I ran into an unusual situation, I've tried a number of things to remedy it but have had no luck.

When using an InputfieldPageAutocomplete, I have the following setup:

    {
      "name":"header_font",
      "label":"Header Font",
      "type":"InputfieldPageAutocomplete",
      "width":"100",
      "parent_id":1305,
      "maxSelectedItem":1,
      "description":"Page List Select Test Description",
      "collapsed":0,
      "value":"0",
       "columnWidth":20
     },

I am able to type fields, get results and all is good. For some reason that I cannot explain, the single page item that gets saved there started out as being stored in the index [0] for the output array, but after saving the control value with a blank entry and then selecting an entry, now for some reason the index is shifted to [1]. There are things I can do to check for this and use the value, but I am really trying to understand the shift. If I do a tracy dump, it shows the index in the array should be 0, there is only one item in the PageArray. But when I try to extract the settings and call the header_font[0] item, I get an undefined index: 0 error and if I change it to header_font[1] item, the only selected item works as usual.

The weird thing is that it was working fine when I first added the field and saved a value - did a bunch of testing with it, no problem. After I cleared the value, saved, and then inserted a new value I started running into the weird index reset.

I'm not really sure where to go next, when the tracy d() output suggests there is only one item in the PageArray and it somehow is not at the 0 index marker.

[Macrura]

@gornycreative - thanks for the report, i will test this and post back asap.

[Macrura]

@gornycreative -

you can try changing this line (221)

$valuesArray[$key] = $f->attr('value');

to this:

$valuesArray[$key] = is_array($f->attr('value')) ? array_values($f->attr('value')) : $f->attr('value');

which should always force any value that is an array to reindex to 0 based.

Let me know if that solves it.

[gornycreative]

22 hours ago, Macrura said:

@gornycreative -

you can try changing this line (221)

$valuesArray[$key] = $f->attr('value');

to this:

$valuesArray[$key] = is_array($f->attr('value')) ? array_values($f->attr('value')) : $f->attr('value');

which should always force any value that is an array to reindex to 0 based.

Let me know if that solves it.

I will give it a try.

I don't know (again) what happened, but after a few hours trying it again resolved the issue. I'm not entirely sure what caused the original issue or why it was resolved. Perhaps cloudflare said I was logged in and had toggles activated on their UI even though I wasn't logged in? I am not entirely sure. Not great for debugging when the problem solves itself ?

The inconsistency with how Tracy dumps said one thing but some other calls provdided errors - not a lot made sense (which seems much of the time to be caching somewhere).

It doesn't look like the host made any significant config changes anyplace I have access to.

UPDATE: Regardless, the fix provided consistent results.

[Macrura]

@gornycreative 

Currently the fix for the issue you reported is the one i provided. I don't know the internal specifics, but the arrays are not reset when saving the value/processing the form the first time, which is why I had to force any array value to a new array.

So you will end up with no [0] index item under some circumstances unless you apply the fix.

You can test it by dumping the value and then adding items to any multi page reference field, and then removing them one by one and hit save and look at the arrays.

Also note that any 2nd save of the settings page does reset the arrays fully. It must be something to do with where/which hook we are processing the form input; For now this is a safe fix, and i'll cary on researching any further optimizations, but this may be the resolution.

[gmclelland]

@gornycreative - If you are using Cloudflare - you may want to set some rules as seen here: