ProcessWire - Konfigurierbare Module: Unterschied zwischen den Versionen
| Zeile 71: | Zeile 71: | ||
} | } | ||
</syntaxhighlight> | </syntaxhighlight> | ||
| + | |||
| + | |||
| + | == Tipps für das Konfigurieren von Modulen == | ||
| + | Es gibt verschiedene Möglichkeiten Module zu konfigurieren. Außerdem ältere Funktionen die manchmal eingesetzt werden. | ||
| + | |||
| + | === Die Funktion getModuleConfigInputfields() === | ||
| + | https://processwire.com/talk/topic/29098-how-should-getmoduleconfiginputfields-be-declared/ | ||
| + | |||
| + | Should getModuleConfigInputfields() be declared in a module as static or not? Also, I am confused that som modules use an array as the parameter whereas others use an InputfieldWrapper. | ||
| + | |||
| + | For example, WireMailSmtp has | ||
| + | |||
| + | static public function getModuleConfigInputfields(array $data) | ||
| + | |||
| + | whereas WireMailRouter has | ||
| + | |||
| + | public function getModuleConfigInputfields(InputfieldWrapper $inputfields) | ||
| + | |||
| + | I am trying to build a module that allows certain configs to be set outside the modules themselves (to allow non-superuser access), so I need to call the getModuleConfigInputfields() method, but without knowing what parameter to supply. If it is an array, I can use getConfig(), but otherwise what. And why do different modules do it differently anyway? | ||
| + | |||
| + | Ryans Antwort: | ||
| + | |||
| + | The Modules class supports a lot of different options for this, and it figures out which you are using automatically according to how you've defined it. The one that I prefer to use is your second example, that is not static and has the InputfieldWrapper $inputfields as the argument. | ||
| + | |||
| + | The static method is the old/original way from when ProcessWire first was released (13 years ago), and it was used primarily so that one could configure a module without booting up an instance of the module. Later on (like ~8 years ago?), the Modules class was upgraded so that it could instantiate the module without initializing it, which made the static option obsolete. The only reason ProcessWire still recognizes it is for backwards compatibility, or if it happens to be preferred by the module developer for one reason or another. | ||
Version vom 24. Juni 2024, 07:24 Uhr
Ab ProcessWire 2.5.5. kann man Module mit Konfigurationsmöglichkeiten einfacher erstellen. Die Konfigurationsoptionen lagert man in eine extra Datei aus.
https://processwire.com/blog/posts/new-module-configuration-options/ https://processwire.com/api/ref/modules/save-config/
Beispiel Modul "Test" (gibt eine Meldung im Admin bei jeder Seitenladen aus)
- Datei mit dem Namen und Klasse [Modulname]Config erstellen
- Klasse extends ModulConfig
- Default Werte über getDefaults() Funktion definieren
- Inputfelder über getInputfields() Funktion definieren
Test.php
class Test extends WireData implements Module {
public static function getModuleInfo() {
return array(
'title' => 'Module Test',
'version' => 1,
'summary' => 'Module for testing/demo purposes.',
'autoload' => 'template=admin',
);
}
public function ready() {
if($this->fullname && !count($this->input->post)) {
$msg = "Hi $this->fullname! ";
$msg .= "Your age: $this->age. ";
$msg .= "Favorite color: $this->color.";
$this->message($msg);
}
}
}
TestConfig.php
class TestConfig extends ModuleConfig {
public function getDefaults() {
return array(
'fullname' => '',
'color' => 'blue',
'age' => 40,
);
}
public function getInputfields() {
$inputfields = parent::getInputfields();
$f = $this->modules->get('InputfieldText');
$f->attr('name', 'fullname');
$f->label = 'Full Name';
$f->required = true;
$inputfields->add($f);
$f = $this->modules->get('InputfieldSelect');
$f->attr('name', 'color');
$f->label = 'Favorite Color';
$f->options = array(
'red' => 'Red',
'green' => 'Green',
'blue' => 'Blue'
);
$inputfields->add($f);
$f = $this->modules->get('InputfieldInteger');
$f->attr('name', 'age');
$f->label = 'Your Age';
$inputfields->add($f);
return $inputfields;
}
}
Tipps für das Konfigurieren von Modulen
Es gibt verschiedene Möglichkeiten Module zu konfigurieren. Außerdem ältere Funktionen die manchmal eingesetzt werden.
Die Funktion getModuleConfigInputfields()
https://processwire.com/talk/topic/29098-how-should-getmoduleconfiginputfields-be-declared/
Should getModuleConfigInputfields() be declared in a module as static or not? Also, I am confused that som modules use an array as the parameter whereas others use an InputfieldWrapper.
For example, WireMailSmtp has
static public function getModuleConfigInputfields(array $data)
whereas WireMailRouter has
public function getModuleConfigInputfields(InputfieldWrapper $inputfields)
I am trying to build a module that allows certain configs to be set outside the modules themselves (to allow non-superuser access), so I need to call the getModuleConfigInputfields() method, but without knowing what parameter to supply. If it is an array, I can use getConfig(), but otherwise what. And why do different modules do it differently anyway?
Ryans Antwort:
The Modules class supports a lot of different options for this, and it figures out which you are using automatically according to how you've defined it. The one that I prefer to use is your second example, that is not static and has the InputfieldWrapper $inputfields as the argument.
The static method is the old/original way from when ProcessWire first was released (13 years ago), and it was used primarily so that one could configure a module without booting up an instance of the module. Later on (like ~8 years ago?), the Modules class was upgraded so that it could instantiate the module without initializing it, which made the static option obsolete. The only reason ProcessWire still recognizes it is for backwards compatibility, or if it happens to be preferred by the module developer for one reason or another.