ProcessWire - Konfigurierbare Module - Versionsgeschichte

109.193.152.88: /* Die Funktion getModuleConfigInputfields() */

2024-06-25T05:29:00Z

Die Funktion getModuleConfigInputfields()

109.193.152.88: /* Die Funktion getModuleConfigInputfields() */

2024-06-25T05:27:28Z

Die Funktion getModuleConfigInputfields()

109.193.152.88: /* Old School Storing */

2024-06-24T09:33:15Z

Old School Storing

109.193.152.88: /* Tipps für das Konfigurieren von Modulen */

2024-06-24T09:28:44Z

Tipps für das Konfigurieren von Modulen

109.193.152.88 am 24. Juni 2024 um 06:24 Uhr

2024-06-24T06:24:29Z

84.155.186.35 am 7. November 2020 um 13:25 Uhr

2020-11-07T13:25:08Z

84.155.186.35: Die Seite wurde neu angelegt: „Ab ProcessWire 2.5.5. kann man Module mit Konfigurationsmöglichkeiten einfacher erstellen. Die Konfigurationsoptionen lagert man in eine extra Datei aus. h…“

2020-11-04T19:57:08Z

Die Seite wurde neu angelegt: „Ab ProcessWire 2.5.5. kann man Module mit Konfigurationsmöglichkeiten einfacher erstellen. Die Konfigurationsoptionen lagert man in eine extra Datei aus. h…“

Neue Seite

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/

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
<syntaxhighlight lang="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);
}
}
}
</syntaxhighlight>

TestConfig.php
<syntaxhighlight lang="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;
}
}
</syntaxhighlight>

@@ Zeile 132: / Zeile 132: @@
 '''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.
+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)
+ static public function getModuleConfigInputfields(array $data)
 whereas WireMailRouter has
@@ Zeile 144: / Zeile 144: @@
 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:
+'''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.
@@ Zeile 150: / Zeile 150: @@
 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.
-Value Attribut setzen
+'''Value Attribut setzen'''
-Damit Werte richtig gespeichert werden muss man im Gegensatz zu den moderneren Funktionen das Value Attribut setzen. Ryan setzt i.d.R. im Konstruktor des Moduls die Default Werte.
+Damit Werte richtig gespeichert werden muss man im Gegensatz zu den moderneren Funktionen das '''Value Attribut setzen'''. Ryan setzt i.d.R. im Konstruktor des Moduls die Default Werte.
-Beispiel aus dem alten LoginRegister Modul (plus ein Textfeld)
+'''Beispiel aus dem alten LoginRegister Modul (plus ein Textfeld)'''
 <syntaxhighlight lang="php">

@@ Zeile 128: / Zeile 128: @@
   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.
+Diese Funktion wurde schon bei den ersten Modulen eingesetzt. Sie ist noch aus Gründen der Kompatibilität vorhanden. Wenn man ältere Module anpassen möchte ist es gut etwas über diese Funktion zu wissen.
 For example, WireMailSmtp has
@@ Zeile 145: / Zeile 149: @@
 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.

@@ Zeile 123: / Zeile 123: @@
+   }
+}
-</php>
+</syntaxhighlight>
 === Die Funktion getModuleConfigInputfields() ===

@@ Zeile 75: / Zeile 75: @@
 == 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() ===

← Nächstältere Version		Version vom 24. Juni 2024, 06:24 Uhr
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.

← Nächstältere Version		Version vom 7. November 2020, 13:25 Uhr
Zeile 2:		Zeile 2:

	https://processwire.com/blog/posts/new-module-configuration-options/		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)		Beispiel Modul "Test" (gibt eine Meldung im Admin bei jeder Seitenladen aus)