Robin S Posted August 22, 2016 Share Posted August 22, 2016 I'm using the newer approach to module config that extends the core ModuleConfig class. I want to include a checkbox in my module config, but I want to force it to be unchecked even if the user has checked it. The reason being, the checkbox is not a setting but just an indicator for if some code should be executed. I look for the checkbox in the post data and if it's checked I execute some code, but on each load of the module config page the checkbox should be unchecked again. Any suggestions on how to do this? I had a look at the PageimageRemoveVariations module which does something similar with a checkbox... $field = $modules->get('InputfieldCheckbox'); $field->attr('name', 'remove_all_variations'); $field->label = __('Remove all Imagevariations to clear the images-cache sitewide!'); $field->attr('value', 1); $field->attr('checked', ''); $field->columnWidth = 65; $form->add($field); ...but that module uses the older approach to module config. When extending ModuleConfig it seems that setting the 'checked' attribute does not override the state of the checkbox that is stored in the DB. Link to comment Share on other sites More sharing options...
LostKobrakai Posted August 22, 2016 Share Posted August 22, 2016 You probably want to change the value as well. 1 Link to comment Share on other sites More sharing options...
Robin S Posted August 22, 2016 Author Share Posted August 22, 2016 Thanks, but setting the value does not override a user-saved value either. Easier to see for another fieldtype because a checkbox is unchecked by default. But for a text field, if I set... $f = $modules->get('InputfieldText'); $f->name = 'test'; $f->label = __('Test'); $f->value = 'red'; $inputfields->add($f); ...then 'test' will show 'red' on the first config page load but if the user changes this to 'blue' then this is what sticks. Link to comment Share on other sites More sharing options...
horst Posted August 22, 2016 Share Posted August 22, 2016 I would consider this an issue. If I get you right, it only doesn't work with the new approach? I assume, it has to do with the automaticly parsed / rendered method of PW, that reads your code (as default setting) and then overrides it with the current modules settings. No chance to override a setting for us. Butthis is a valid use case. I think we should make an issue on github and see, if Ryan can add this more fine grained control back for us. 1 Link to comment Share on other sites More sharing options...
Robin S Posted August 22, 2016 Author Share Posted August 22, 2016 59 minutes ago, horst said: I would consider this an issue. If I get you right, it only doesn't work with the new approach? While I don't have much experience with the old approach, I think one of the main differences between the new and the old approach is the way values and defaults are set to the config fields. In the old approach you set defaults in an array and these were merged with user-saved data from the DB into a $data array. And for each inputfield you typically set the value with $data['some_key'] which could be either a default or a user value depending on if that field had a value in the DB . With the new approach the ModuleConfig class takes care of setting the value to the inputfield. It's an added convenience but it also takes it out of your hands if you want do do something out-of-the-ordinary for a particular inputfield. With the new approach, any value you set to the field is only taken as a default that may be overwritten by a user-saved value. In the blog post that introduced the new config class Ryan seems to confirm this: Quote Our default values are defined in this array as well. See the "value" property. So now that I look at the first example again, I don't think it is this line that makes the checkbox unchecked... $field->attr('checked', ''); ...rather it's the fact that the field value is not set from the $data[] array so it never gets any value from the DB and reverts to the default state for a checkbox (unchecked) on each load of the config page. This wouldn't be possible with the new approach because values are set 'behind the scenes'. Not sure if it constitutes an issue though, maybe just requires a different approach. This is how I've solved it for now, which seems okay: public function init() { // Reset checkbox $data = array('my_checkbox' => ''); $this->modules->saveConfig(get_class($this), $data); } Link to comment Share on other sites More sharing options...
LostKobrakai Posted August 22, 2016 Share Posted August 22, 2016 How about not overwriting the value of the inputfield, but actually overwriting the thing you actually want to change: the module config. Link to comment Share on other sites More sharing options...
Robin S Posted August 22, 2016 Author Share Posted August 22, 2016 1 hour ago, LostKobrakai said: How about not overwriting the value of the inputfield, but actually overwriting the thing you actually want to change: the module config. Is there a different/better way to do that besides what I'm doing already? 2 hours ago, Robin S said: public function init() { // Reset checkbox $data = array('my_checkbox' => ''); $this->modules->saveConfig(get_class($this), $data); } Link to comment Share on other sites More sharing options...
LostKobrakai Posted August 22, 2016 Share Posted August 22, 2016 $name = $this->className(); // Namespace aware $config = $this->modules->getModuleConfigData($name); // Before 3.0.16 $config['my_checkbox'] = ''; $config = $this->modules->setModuleConfigData($name, $config); // Before 3.0.16 1 Link to comment Share on other sites More sharing options...
horst Posted August 22, 2016 Share Posted August 22, 2016 @LostKobrakai where must this be called? AFAIK, you define and / or add an array with (default) values and every thing else is done by PW. MyModule.module: Spoiler <?php namespace ProcessWire; class MyModule extends WireData implements Module { public function init() {} public function ready() {} public function doSomething() { if('PRODUCTION_MODE' == $this->site_mode) { var_dump($this->site_mode); } else { var_dump($this->site_mode); } } } MyModuleConfig.php: Spoiler <?php namespace ProcessWire; class MyModuleConfig extends ModuleConfig { public function __construct() { $name = str_replace('Config', '', $this->className()); // Namespace aware $data = $this->modules->getModuleConfigData($name); // Before 3.0.16 $data['site_mode'] = 'DEV_MODE'; $data = $this->modules->setModuleConfigData($name, $data); // Before 3.0.16 $this->add(array( array( 'type' => 'Fieldset', 'name' => '_setup', 'label' => 'setup', 'collapsed' => Inputfield::collapsedNo, 'children' => array( array( 'type' => 'select', 'name' => 'site_mode', 'options' => array( 'PRODUCTION_MODE' => 'PRODUCTION_MODE', 'DEV_MODE' => 'DEV_MODE', ), ) ) ) )); } } Link to comment Share on other sites More sharing options...
LostKobrakai Posted August 22, 2016 Share Posted August 22, 2016 $this->className() in the ModuleConfig will return the name of the config class not the module (as would get_class()). Just remove the …Config suffix. But as soon as you're passing it the correct module name it's going to work wherever you need it. Also I'm not really sure if this kind of functionality actually should be put in the config module in the first place. It's convenient, but a actual function of the module, triggered on init() if a specific config is set, might actually be the better structure. 1 Link to comment Share on other sites More sharing options...
Robin S Posted August 22, 2016 Author Share Posted August 22, 2016 8 hours ago, LostKobrakai said: $name = $this->className(); // Namespace aware $config = $this->modules->getModuleConfigData($name); // Before 3.0.16 $config['my_checkbox'] = ''; $config = $this->modules->setModuleConfigData($name, $config); // Before 3.0.16 This is great, thanks. I see now we need to save complete config data not just one field. $this->modules->setModuleConfigData($name, $config); ^ This didn't work for me, but the following did: $this->modules->saveModuleConfigData($name, $config); 1 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now