Kontaktformular - Eigene Felder hinzufügen und senden

Grausliche Core-Hacks machen das Internet unsicher, wenn einem Joomla-Formular wie dem Kontaktformular (Email senden) ein zusätzliches Feld hinzugefügt werden soll. Der richtige Weg ist einzig ein System-Plugin. Huch, kann ich nicht! Wer in "verbotenen" Joomla-Dateien rumpfuschen kann, kriegt auch ein eigenes Plugin hin. Und, wenn Probleme auftauchen, gibt es dolle Foren, wo man Hilfe bekommt.

Was will ich?

Ich möchte keine Änderungen machen, die Joomla-Updates nicht überleben, sondern updatesicher arbeiten. Deshalb erstelle ich ein eigenes Plugin und einen Template-Override.
Das joomlaeigene Kontaktformular soll ein weiteres Eingabefeld für eine Telefonnummer erhalten, das der Besucher ausfüllen kann.
Die Telefonnummer soll an den Nachrichtentext angehängt werden und mit der Email an mich gesendet werden.
Im Backend soll im zu erstellenden Plugin ausgewählt werden können, ob das Telefonfeld ein Pflichtfeld ist, ob der Benutzer des Formulars es ausfüllen muss oder leer lassen kann.

Dateien des System-Plugins contactformaddfields

Erst erstellen wir eine Rohfassung mit den notwendigen Verzeichnissen und Dateien. Der Hauptordner heißt wie das Plugin /contactformaddfields/.

Auf dem Bild sieht man die Struktur im /plugins/-Verzeichnis nach Installation in Joomla, unten die des Ordners /contactformaddfields/, den es erst mal anzulegen gilt auf dem eigenen Rechner (lokal), damit wir später daraus eine ZIP-Installationsdatei erstellen können.

Ordner und Dateistruktur des Systemplugins Add fields to contact form

Hauptordner /contactformaddfields

Zwei Dateien

contactformaddfields.php. Hier kommt später die Programmlogik rein, der PHP-Code also. Erkennen, dass gerade ein Kontaktformular angezeigt werden soll, das Telefonfeld den anderen Formularfeldern hinzufügen. Sowie beim Senden einer Email die eingegebene Telefonnummer an den Email-Text anhängen.
contactformaddfields.xml. Die so genannte Manifest-Datei der Erweiterung. Hier werden Daten / Informationen zum Plugin selbst hinterlegt, damit Joomla es korrekt installieren kann. Weiters die Konfigurationsoption für Einstellung Pflichfeld Ja / Nein des eigenen Formularfeldes.

Sprachdateien in Unterordner /contactformaddfields/language

Zwei Dateien im Unterordner /en-GB/.

en-GB.plg_system_contactformaddfields.ini
en-GB.plg_system_contactformaddfields.sys.ini

Auch, wenn wir deutsch sind, sollte in jeder Erweiterung ein Satz englischer Sprachdateien angelegt werden, da dies die von Joomla angenommene Default-Sprache ist. Bei Erweiterungen, die nicht öffentlich werden, schreibe ich hier einfach meine deutschen Texte rein.

Fleißige legen für weitere Sprachen Dateien analog an. Zusätzlichen Unterordner /de-DE/, darin zwei Sprachdateien, die mit de-DE anfangen statt en-GB. (Auch) die weitere Bezeichnung der Dateien ist exakt einzuhalten. Getrennt durch Unterstriche plg für Plugin, system für den Ordner der Plugingruppe (s.u.), gefolgt vom Namen des Plugins: contactformaddfields. Danach ein mal die Dateiendung sys.ini sowie ein mal nur ini. Erstere wird im Backend verwendet, v.a. bei der Installation, zweitere auch im Frontend.

Eigene Formular-XML-Datei in /contactformaddfields/myforms

Eine Datei.

contactcustom.xml

In dieser Datei tragen wir unten unser zusätzliches Telefon-Feld ein, das dem Besucher im Frontend angezeigt wird. Oder weitere, wenn gewünscht. Ordner- und Dateiname sind frei, sollten aber am besten immer Kleinschrift sein, ohne Sonderzeichen, ohne Umlaute, Leerzeichen und so weiter und müssen bei Änderung in der Plugin-PHP-Datei entsprechend angepasst werden.

Manifest-Datei contactformaddfields.xml - Inhalt

Ohne saubere Manifest-Datei keine saubere Erweiterungs-Installation! Bis hin zu fehlenden Dateien.

Ein paar Angaben in der XML-Datei werden bei Installation oder Update in die Datenbank geschrieben. Macht man Änderungen, muss man neu installieren (drüberbügeln). Konfigurationseinstellungen, die man im Plugin schon gemacht hat, werden dabei nicht überschrieben. Weitere Konfigurations-Felder kann man in der Spielphase ohne Neuinstallation einfügen und sie werden im Plugin sofort sichtbar nach Neuladen der Plugin-Konfiguration.

<?xml version="1.0" encoding="utf-8"?>
<extension version="3.7" type="plugin" group="system" method="upgrade">

	<name>PLG_SYSTEM_CONTACTFORMADDFIELDS</name>

	<author>Hier den Autor der Erweiterung eintragen</author>
	<creationDate>2015-11-03</creationDate>
	<copyright>Copyright-Hinweise zum Plugin</copyright>
	<license>Verweis auf Lizenztext</license>
	<authorUrl>Webadresse des Autors</authorUrl>
	<version>2020.10.04</version>

	<description>PLG_SYSTEM_CONTACTFORMADDFIELDS_DESCRIPTION</description>

	<minimumJoomla>3.7.0</minimumJoomla>

	<files>
		<filename plugin="contactformaddfields">contactformaddfields.php</filename>
		<folder>language</folder>
		<folder>myforms</folder>
	</files>

	<config>
		<fields name="params">
			<fieldset name="basic">

				<field name="phone_required" type="list" default="0"
					label="PLG_CONTACTFORMADDFIELDS_PHONE_REQUIRED_LBL"
					description="PLG_CONTACTFORMADDFIELDS_PHONE_REQUIRED_DESC">
					<option value="0">JNO</option>
					<option value="1">JYES</option>
				</field>

			</fieldset>
		</fields>
	</config>

</extension>

Zeile 1 ist immer Pflicht und darf nichts davor haben, keine Leerzeile, kein Leerzeichen. Man kann sie blind in allen Manifestdateien verwenden wie zu sehen. Die Datei gibt sich damit dem so genannten Parser als XML-Datei zu erkennen. Muss uns aber nicht weiter interessieren.

Zeile 2 eröffnet den Bereich <EXTENSION> (= Erweiterung), der in Zeile 38 geschlossen wird. Dazwischen die Informationen zum Plugin. Aufpassen, dass man in Zeile 2 die richtige Plugingruppe (group) einträgt! Plugingruppe ist gleich dem Unterordner im Joomla-Verzeichnis /plugins/, wo die Plugindateien bei Installation reinkopiert werden. Im falschen Ordner, in der falschen Gruppe könnte es sein, dass das Plugin nichts tut oder nur einen Teil seiner Aufgaben erledigt.

version in Zeile 2 ist eine Angabe, die man auch weglassen kann. In Joomla 4 wurde diese Angabe in allen Core-Erweiterungen entfernt.

method="upgrade" macht ein erneutes Drüberinstallieren möglich. Sonst müsste man das Plugin immer erst deinstallieren, damit man seine Spielereien am Code neu installieren kann.

Zeile 4, ein Muss, der klarer formulierte Name des Plugins, hier hinter einem Sprachplatzhalter PLG_SYSTEM_CONTACTFORMADDFIELDS versteckt, den wir gleich in der Sprachdatei en-GB.plg_system_contactformaddfields.sys.ini entschlüsseln.

Zeilen 6-10: Für unser Plugin, das ja privat bleibt, nicht so wichtig. Teils werden die Einträge aber im Backend als Info angezeigt. Den gelegentlich zu findenden Tag <autorEmail> verwende ich nicht mehr oder lasse ihn leer, da die eingetragenen Email-Adressen zu oft für nervigen Spam verwendet wurden.

Will man's hübsch, macht man halt richtig. Was wo reingehört, habe ich reingeschrieben.

Zeile 11: Die Pluginversion, nicht zu verwechseln mit der obsoleten Joomla-Version in Zeile 2. Ich nehme plump das umgedrehte Datum (Jahr.Monat.Tag, 2015.11.03), auch wenn das nicht der Norm entspricht. Wichtig ist, dass die Version in irgendeinerweise aufsteigend ist, wenn man nach Überarbeitung der Erweiterung eine neue Version zuordnen will. 0.0.1, 0.0.2, 0.0.3 usw. Kann man sich im Netz schlau machen wie das mit der 3-blockigen, punktgetrennten Versionsangabe exakt funktioniert und was man damit aussagt. Ich mache es nicht akademisch richtig, aber für Joomla-Update-Eventualitäten funktionierend mit dem Datum.

Zeile 13: Ein mehr oder weniger ausführliche Beschreibung des Plugins, wieder hinter einem Sprachplatzhalter versteckt..

In Zeile 14 mache ich mit <minimumJoomla>3.7.0</minimumJoomla> der Joomla-Installations-Routine bekannt, dass ... ? ... mindestens Joomla in der Version 3.7.0 verwendet werden muss, damit die Installation nicht mit einer entsprechenden Meldung abbricht.

Zeilen 17-21: Wichtig! Der <FILES>-Block. Dateien und Ordner, die bei der Installation kopiert werden sollen. Was hier nicht drin steht, wird auch nicht kopiert und fehlt dann eventuell. Besonderes Augenmerk auf Zeile 18 bzgl. besonderer Formulierung mit Zusatzangabe plugin!

Hat man im Hauptordner z.B. eine weitere Datei helper.php oder LICENSE.txt trägt man im <FILES>-Block zusätzlich ein: <filename>helper.php</filename> bzw. <filename>LICENSE.txt</filename>.

Zeilen 23-36: Der <CONFIG>-Block. Hier kommen die Konfigurations-Optionen für das Backend hinein. Die Konfigurations-Felder werden bei Plugins immer von einem <FIELDS>-Block namens params umschlossen (Zeilen 24-35), damit sie korrekt in der Datenbank gespeichert werden. Der folgende <FIELDSET>-Block (Zeilen 25-34) könnte auch anders benannt sein als basic. Gebe ich z.B. stattdessen "blah" ein, generiert Joomla automatisch einen weiteren Reiter in den Plugineinstellungen.

Konfigurationsoptionen im FiELDSET namens blah

Mit mehreren FIELDSET-Blöcken (alle innerhalb FIELDS) könnte man die Pluginparameter also logisch gruppieren. Die automatisch generierten Sprachplatzhalter der Tabulatoren-Beschriftung, hier COM_PLUGINS_BLAH_FIELDSET_LABEL muss man in der Sprachdatei des Plugins in Klartext übersetzen.

Und in Zeilen 26-31 schließlich ein Konfigurations-Parameter, mit dem wir im Backend einstellen können, ob das Telefonfeld im Frontend als Pflichtfeld behandelt werden soll oder nicht. Die Voreinstellung ist nein (default="0"). Als Art habe ich mir aus der Übersicht der Standard-Formularfelder eine Dropdown-Box ausgesucht (type="list").. Auswahlmöglichkeiten JA (Zeile 30) und NEIN (Zeile 29). Die hier verwendeten Sprachplatzhalter (JYES / JNO) müssen wir nicht extra anlegen. Joomla hält diese überall verwendbar bereit. label (Zeile 27) und description (Zeile 28) wie gehabt mit eigenen Sprachplatzhaltern ausgestattet.

Sprachdatei en-GB.plg_system_contactformaddfields.sys.ini - Inhalt

sys in der Dateiendung steht vermutlich für System, nicht zu verwechseln mit der Plugingruppe system (s.o.). Die Übersetzungen dieser Datei werden bei Installation gezogen und angezeigt und im Backend für grundlegende Informationen zum Plugin verwendet. Hier kommen die Sprachplatzhalter der Tags NAME und DESCRIPTION unseres Manifest-Files (Zeile 4 und 14 oben) hinein. Wie man sieht, kann man in Sprachdateien auch HTML verwenden, muss aber aufpassen, dass man Gänsefüßchen innerhalb des Beschreibungstextes jeweils durch "_QQ_" ersetzt. Tipp: Einfach Apostrophe verwenden. Ein style='color:red;' ist ja auch erlaubt.

Da in der Darstellung folgenden Codes ein Fehler drin ist, der wohl vom Code-Plugin kommt hier die Originaldatei plugins/system/contactformaddfields/language/en-GB/en-GB.plg_system_contactformaddfields.sys.ini (von falsch dargestellten Umlauten nicht beunruhigen lassen)

PLG_SYSTEM_CONTACTFORMADDFIELDS="System - Contact form add fields. Demo by Re:Later"

PLG_SYSTEM_CONTACTFORMADDFIELDS_DESCRIPTION="<p>Demoplugin von Re:Later, um ein Feld Telefon zu einem Kontaktformular hinzuzufügen, das in einem Override des Kontaktformulars angezeigt werden kann. Desweiteren fügt es das Telefonfeld an den Emailtext an. <em>Aktivieren des Plugins nicht vergessen!</em></p><p><a href="/_QQ_"http://ghsvs.de/programmierer-schnipsel/joomla/140-kontaktformular-eigene-felder-hinzufuegen"_QQ_" style='color:red;'>Tutorial</a></p>"

Pluginbeschreibung im Menue Erweiterungen Verwalten

Sprachdatei en-GB.plg_system_contactformaddfields.ini - Inhalt

Weitere Übersetzungen, bspw. für die Beschriftung unseres Konfigurationsfeldes im Backend, aber auch die Beschriftung (= Label) des Telefonnummern-Eingabefeldes im Frontend.

;; FRONTEND
PLG_CONTACTFORMADDFIELDS_PHONE_LBL="Telefon"
PLG_CONTACTFORMADDFIELDS_PHONE_DESC="Hier Ihre Telefonnummer eingeben"

;; BACKEND
PLG_CONTACTFORMADDFIELDS_PHONE_REQUIRED_LBL="Telefon Pflicht"
PLG_CONTACTFORMADDFIELDS_PHONE_REQUIRED_DESC="Soll das Telefonfeld ein Pflichtfeld sein?"

Wenn Sie wollen, können Sie in diese ini-Datei auch die beiden Sprachplatzhalter der obigen sys.ini-Datei mit abweichendem Text eintragen. Beim Öffnen des Plugins im Backend werden dann diese abweichenden Texte angezeigt. Nachtrag 2015-12-28: Ich empfehle es sogar mittlerweile in beide Dateien von Erweiterungen diese beiden Basis-Sprachplatzhalter einzufügen, um blöde Überraschungen, z.B. bei eigenen Modulen zu vermeiden.

Zeilen, die in Sprachdateien mit Semikolon (;) eingeleitet werden, dienen privaten Kommentaren, müssen nicht sein wie im Code zu sehen.

Müssen Sprachplatzhalter eigentlich immer so lange Würmer sein? Müssen Sie nicht. Sie müssen eindeutig sein, damit eine Datei einer anderen Erweiterung sie uns nicht überschreibt. Sie könnten statt PLG_CONTACTFORMADDFIELDS_PHONE_LBL auch TELEFON verwenden oder SONSTWAS oder CONTACT_FORM_PHONE. Manchmal siegt auch bei mir die Faulheit... Gelegentlich bereue ich es...

contactcustom.xml mit dem eigenen Formularfeld - Inhalt

Diese Datei wird dem Formular(-Objekt) zugeladen, das zuvor mit der Datei /components/com_contact/models/forms/contact.xml generiert wurde (keine Gewähr, dass der Link auf contact.xml ewig funktioniert bzw. ewig zum Tutorial passt).

<?xml version="1.0" encoding="utf-8"?>
<form>

 <field name="contact_phone" type="text" filter="tel"
  description="PLG_CONTACTFORMADDFIELDS_PHONE_DESC"
  label="PLG_CONTACTFORMADDFIELDS_PHONE_LBL" />

</form>

Ich will Ihnen nichts vormachen. Das Kontaktformular ist besonders einfach zu erweitern. Wir benötigen keine umschließenden FiELDS-Blöcke und / oder FIElDSET-Blöcke. Bei Joomla-Formularen, die zusätliche Felder auch noch speichern sollen, aber nicht nur dann, kann das trickiger werden.

Zeile 1, wie schon bei der Manifest-Datei oben gesehen. "ich bin eine XML-Datei."

Zeilen 2-8, der FORM-Block. Erzählt Joomla, dass Dazwischenliegendes ergänzende (oder sogar überschreibende) Teile des Formulars sein sollen. Ein Muss.

Die Zeilen 4-6 definieren ein einfaches Textfeld (type="text"), das wie das oben beschriebende list-Feld zu den Standard-Formularfeldern Joomlas gehört. Der Name des Feldes (name="contact_phone"), selbst von mir erdacht in Anlehnung an die Formularfeld-Bezeichner des Original-Kontaktformulars, muss unverwechselbar sein. Mit dieser einzigartigen Kennung wird es erst möglich, dass wir in den unten beschriebenen PHP-Codes auf das Tel.Feld zugreifen können, einerseits bei der Anzeige des Email-Formulars, andererseits, um die eingegebene Nummer nach Absenden auslesen zu können.

Die Hauptdatei contactformaddfields.php - Inhalt

<?php
defined('_JEXEC') or die;

class PlgSystemContactformaddfields extends JPlugin
{
 
 protected $app;
 protected $autoloadLanguage = true;
 
 public function onContentPrepareForm($form, $data)
 {
  
  if ($this->app->isAdmin())
  {
   return true;
  }
  
  $view = $this->app->input->getCmd('view', '');
  $option = $this->app->input->getCmd('option', '');
  $allowedContext = 'com_contact.contact';

  if (
   $view != 'contact'
   || $option != 'com_contact'
   || $form->getName() != $allowedContext
  ){
   return true;
  }
 
  JForm::addFormPath(__DIR__ . '/myforms');

  $form->loadFile('contactcustom', $reset = false, $path = false);
  
  if ($this->params->get('phone_required', 0))
  {
   $form->setFieldAttribute('contact_phone', 'required', 'true');
  }

  return true;
 }

 public function onSubmitContact(&$contact, &$data)
 {
  if (isset($data['contact_phone']))
  {
   $data['contact_message'] .= "\n\n";
   $data['contact_message'] .= JText::_('PLG_CONTACTFORMADDFIELDS_PHONE_LBL');
   $data['contact_message'] .= ': ' . $data['contact_phone'];
  }
  return true;
 }

}

Zeile 2: Ein Muss. Keine ausführbare Joomla-PHP-Datei ohne eine solche Zeile (Es gibt Variationen. Diese ist aber immer richtig.)! Sie verhindert, dass die Datei direkt aus der Browser-Adresszeile aufgerufen werden kann. Die obige Plugindatei ist zwar harmlos. Trotzdem!

Zeilen 4, 5: (Für unser Anliegen) ein Muss. Eine PHP-Klasse wird definiert, durch geschweifte Klammer geöffnet und in Zeile 53 durch geschweifte Klammer abgeschlossen. Der Name der Klasse besteht aus Plg für Plugin, System für die Plugingruppe, die oben bei der Diskussion des Manifests erwähnt wurde, gefolgt vom Pluginordner, besser: dem im Manifest Zeile 17 bekanntgemachten Pluginnamen.

Der so zusammengesetzte Klassenname unterliegt bzgl. Groß- Kleinschrift keinen Regeln. Ich befolge aber immer mindestens die im Code zu sehende, so genannte UpperCamelCase-Schreibweise (Auch Kamele haben hochragende Höcker. Zwar nur 2...). Es spricht aber nichts dagegen, da noch mehr Transparenz in den Klassenbezeichner rein zu bringen PlgSystemContactFormAddFields.

Zeilen 7-8: Es werden zwei praktische Variablen bei Joomla angefordert, was uns v.a. bei komplexeren Plugins etwas Tipparbeit ersparen kann. Lassen wir mal außen vor, verwenden die $app einfach, im Code etwas abgewandelt als $this->app formuliert.

Zeile 10-40 und Zeilen 42-51: Zwei so genannte Methoden der PHP-Klasse, onContentPrepareForm und onSubmitContact. Diese auch Plugin-Events (Vorsicht! Doku-Link teils irreführend sortiert und unvollständig) genannten functions sind die Joomla-Zauberei, die wir ausnutzen.

Es kann mehrere verschiedene Plugins neben unserem geben, die ebenfalls diese Methoden enthalten. An ganz bestimmten Stellen innerhalb sonstigen Joomla-Codes werden die diversen Plugins aufgefordert, die jeweilige Methode auszuführen, um z.B. weitere Daten hinzuzufügen, zu entfernen, zu überschreiben, zu prüfen usw. usf..

Die Plugin-Methode onContentPrepareForm im Einzelnen

Bevor ein Joomla-Formular angezeigt wird, bekommen Plugins, die die Methode enthalten, die Chance, das Formular zu manipulieren. Das Formular wird der Methode als PHP-Objekt $form überreicht /Zeile 1).

 public function onContentPrepareForm($form, $data)
 {
  
  if ($this->app->isAdmin())
  {
   return true;
  }
  
  $view = $this->app->input->getCmd('view', '');
  $option = $this->app->input->getCmd('option', '');
  $allowedContext = 'com_contact.contact';

  if (
   $view != 'contact'
   || $option != 'com_contact'
   || $form->getName() != $allowedContext)
  ){
   return true;
  }
 
  JForm::addFormPath(__DIR__ . '/myforms');

  $form->loadFile('contactcustom', $reset = false, $path = false);
  
  if ($this->params->get('phone_required', 0))
  {
   $form->setFieldAttribute('contact_phone', 'required', 'true');
  }

  return true;
 }

Mit dem Wissen, dass diese Methode in allen Plugins, also auch unserem, sowohl im Backend als auch im Frontend aufgerufen wird, wannimmer Joomla von einer Erweiterung gebeten wird, ein Formular mit Hilfe von XML zusammenzubasteln, müssen wir andere Formulare vor unserem Plugin beschützen und die Ausführung der Methode frühzeitig beenden, wenn es nicht das Email-senden-Formular ist. Der Abbruch passiert durch die Zeile(n) return true; (Zeilen 15 und 27)

Dafür fragen wir via Joomla ab, ob wir uns "in der richtigen Umgebung befinden".

Zeilen 13-16: Bin ich im Backend? Ja? Dann abbrechen! Formulare im Administrationsbereich gehen uns nichts an. Sagt uns aber auch, dass wir mit einem Plugin ebenfalls Backend-Formulare erweitern können (bisschen trickiger, allerdings).

Zeilen 18-19: Für weitere Prüfungen sammeln wir noch mehr Umgebungsvariablen zusammen. Schaltet man in Joomla mal die Suchmaschinenfreundlichen URLs und URL-Rewrite nutzen in der Konfiguration aus und ruft das Kontaktformular im Fronend auf, nachdem man zuvor die Startseite aufgerufen hat, zeigt die Adresszeile Ihres Browsers einen Wurm

/index.php?option=com_contact&view=contact&id=9&Itemid=483

option=com_contact zeigt an, dass wir uns in einer Ansicht der Komponente com_contact befinden.
view=contact zeigt an, dass wir uns in der Ansicht eines einzelnen Kontakts befinden
id=9 zeigt an, dass wir den Kontakt mit ID 9 sehen (Vergleiche mit ID-Spalte der Kontakte-Übersicht im Backend)
Itemid ist die ID des aktiven Menüeintrags

Klicken / Tippen Sie sich durch Ihre Seitenmenüs und vergleichen option und view in der Browseradresszeile.

Zwei dieser so genannten URL-Parameter, nämlich option und view, lesen wir aus und legen sie erst mal je in einer PHP-Variablen ab, nämlich $option sowie $view. Die Dinger links vom Gleichheitszeichen mit dem Dollar ($) vorne dran. Man könnte sie auch $quakie und $pupie nennen, die beiden gewählten Bezeichner finden sich aber seit jeher in Joomla, sind ein bisschen was wie Standard...

Zeile 20: Das Formular(-Objekt) $form enthält eine Info welches Formular es ist. Diese Kennung, auch Kontext genannt, weiß ich auswendig, com_contact.contact und hinterlege sie ebenfalls in einer PHP-Variablen. Wenn man sie für ein anderes Formular nicht weiß, mal in einem Forum oder via Kontaktformular hier auf der Seite nachfragen, wie man sie in der Methode onContentPrepareForm für andere Formulare ermitteln könnte. Leider weiß ich nicht sicher, ob man sie immer verlässlich aus den URL-Parametern zusammendichten kann.

Zeilen 22-28: Die Prüfung auf korrekte Umgebungsvariablen

Wenn (Zeile 22)
der ausgelesene URL-Parameter view nicht gleich contact ist (Zeile 23)
ODER der ausgelesene URL-Parameter option nicht gleich com_contact ist (Zeile 24)
ODER die Kennung im Formular(-Objekt) nicht gleich com_contact.contact ist (Zeile 25)

... dann beende die Ausführung der Plugin-Methode mit einem return (Zeile 27), da wir uns im falschen Formular befinden.

Zugegeben ist diese Mehrfachprüfung etwas "sehr sorgfältig" und man käme vermutlich mit der Formularkennung alleine klar...

Nachtrag: Für Interessierte. Eine weitere Prüfung, ob das Formular überhaupt eines ist

if (!($form instanceof JForm))
{
 $this->_subject->setError('JERROR_NOT_A_FORM');
 return false;
}

Zeile 30: Wir machen dem Formular bekannt, in welchem Verzeichnis es nach eigenen XML-Dateien suchen soll, wo die formularergänzende Datei contactcustom.xml liegt. Die verwendete, magische PHP-Konstante __DIR__ ist gleich dem Pfad bis zur gerade ausgeführten Datei, also der Ordner unseres Plugin-Files contactformaddfields.php. Müssen wir nur noch den Unterordner /myforms dranhängen.

In Joomla könnte man die Zeile auch so formulieren (als Hinweis wie man eine Pfadangabe baut, wenn die XML-Datei woanders im Joomla-Verzeichnis liegen sollte):

JForm::addFormPath(JPATH_SITE . '/plugins/system/contactformaddfields/myforms');

oder, wenn der Ordner irgendwo im /plugins/-Verzeichnis ist, noch kürzer

JForm::addFormPath(JPATH_PLUGINS . '/system/contactformaddfields/myforms');

Zeile 32: Die eigene XML-Datei wird hinzugeladen. Beachten Sie, dass die Angabe ohne Endung .xml erfolgt.

Zeilen 34-37: Wir hatten in der Manifestdatei eine Konfigurationsoption namens phone_required angelegt, um im Backend einstellen zu können, ob das Telefonfeld im Frontend ein Pflichtfeld sein soll, also dem Benutzer angemahnt wird, wenn er es nicht füllt. Diese Einstellungen liegen in einem joomlatypischen, so genannten Registry-Objekt $this->params. Mit get(...) holen wir die gemachte Einstellung ab und wenn sie 1 (= JA) ist, dann wird unserem Feld contact_phone noch ein Attribut required hinzugefügt und das Attribut erhält den Wert 'true', gleichbedeutend mit JA (Zeile 36) .

Auf gleiche Art und Weise könnte man auch andere Attribute des Feldes ändern (natürlich auch Attribute der anderen Formularfelder), ein anderes label, eine andere description etc. pp.

Die Plugin-Methode onSubmitContact im Einzelnen

Nachdem der Benutzer im Frontend den Absenden-Button betätigt hat und die eingegebenen Dinge geprüft wurden, z.B., ob die eingegebene Emailadresse wirklich eine ist, haben Plugins mit dieser Methode die Möglichkeit die Formulardaten im PHP-Array $data zu ändern, bevor die E-Mail zusammengesetzt und anschließend gesendet wird..

 public function onSubmitContact(&$contact, &$data)
 {
  if (isset($data['contact_phone']))
  {
   $data['contact_message'] .= "\n\n";
   $data['contact_message'] .= JText::_('PLG_CONTACTFORMADDFIELDS_PHONE_LBL');
   $data['contact_message'] .= ': ' . $data['contact_phone'];
  }
  return true;
 }

Beim Zusammensetzen der E-Mail, was in einer Joomla-Core-Datei stattfindet, die man nicht ändern darf, wird von den Feldern ausgegangen, die das Standard-Formular bereit stellt. Unser eigenes Telefonfeld contact_phone landet dort zwar auch, aber wird ignoriert.

Wir müssen es also selbst an den Emailtext dranbasteln. Das ist das Feld contact_message.

Zeile 44: Es wird zur Sicherheit geprüft, ob das Feld contact_phone im Formular überhaupt angezeigt wurde, "anwesend war", mitgesendet wurde, egal, ob leer oder nicht.

Zeilen 46-48: Wir hängen schrittweise durch .= weitere Textbauteile an den Emailtext an.

Zeile 46: zwei Zeilenumbrüche
Zeile 47: auf joomlatypische Art die Übersetzung des Sprachplatzhalters aus unserer Sprachdatei als Label (Telefon)
Zeile 48: ein Doppelpunkt (hinter dem Label) und endlich die Telefonummer wie vom Benutzer eingegeben.

Puuh!

Installationsdatei erstellen (ZIP)

Um das Plugin in Joomla installieren zu können, erstellen wir eine ZIP-Datei. Ich mache das mit dem Tool 7-zip so. Den Hauptordner öffnen. Alle Ordner und Dateien markieren. Rechtsklick auf markierten Bereich. Im Submenü 7-Zip die Option Hinzufügen zu "contactformaddfields.zip".

Nach der Installation

Angemerkt. Nach der Installation können Sie an den Dateien Änderungen vornehmen und on-the-fly testen. Weitere Felder hinzufügen usw.

Das Plugin öffnen, mal anschauen, ausprobieren, ob Speichern klappt und es aktivieren.

Im Frontend das Email-senden-Formular öffnen... Nix zu sehen.

Es fehlen noch die Anzeigezeilen für das Telefonfeld in der PHP-Datei des Formulars. Wir müssen noch einen Joomla-Template-Override dafür erstellen.

Override der Datei /components/com_contact/views/contact/tmpl/default_form.php

Achtung: Seit Joomla 3.5 hat sich die Datei default_form.php erheblich geändert! Man muss also entweder aus eine Joomla-3.4.8-Paket die Datei als Basis nehmen oder kennt sich so weit aus, dass man mit der neuen Art zurechtkommt. Ich habe es noch nicht geprüft, aber vermutlich wird mit Joomla ab 3.5 das Telefonfeld auch ohne Override angezeigt ???? Aber man hat dann keinen Einfluss auf die Position ohne Override.

Die Datei in der Überschrift ist eine Joomla-Core-Datei, die nicht verändert werden darf. Also kopieren Sie sie in das /html/-Verzeichnis Ihres Templates.

/templates/IHRTEMPLATENAME/html/com_contact/contact/default_form.php

IHRTEMPLATENAME müssen Sie dabei durch den Ordnernamen Ihres Templates ersetzen. Bei mir im Moment durch protostar.

Overrides können Sie übrigens auch recht bequem mit Joomlas Template-Editor im Backend erstellen und dort die Datei auch gleich bearbeiten.

   <div class="control-group">
    <div class="control-label"><?php echo $this->form->getLabel('contact_email'); ?></div>
    <div class="controls"><?php echo $this->form->getInput('contact_email'); ?></div>
   </div>
   <div class="control-group">
    <div class="control-label"><?php echo $this->form->getLabel('contact_phone'); ?></div>
    <div class="controls"><?php echo $this->form->getInput('contact_phone'); ?></div>
   </div>
   <div class="control-group">
    <div class="control-label"><?php echo $this->form->getLabel('contact_subject'); ?></div>
    <div class="controls"><?php echo $this->form->getInput('contact_subject'); ?></div>
   </div>

Ich habe das Telefonfeld zwischen Email und Betreff geschoben.

Eigeness Telefonfeld im Emailformular im Frontend

Empfangene Email inklusive Telefon im Emailtext

Funktioniert alles nicht??? Fragen (Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.)!

Autor / Programmierung: Re:Later. Freigabe 2015-11-06

Erweiterungs-Infos

Name

PLG_SYSTEM_CONTACTFORMADDFIELDS

Beschreibung

Plugin zu Tutorial. Ein Telefonfeld im Kontaktformular anzeigen und senden. Benötigt Override.

Download

Direkter Download oder zur Download-Seite

Kommentare und Hinweise

Das angehängte Plugin benötigt mindestens Joomla 3.7.0.

Allgemeiner Hinweis zu Erweiterungen und Code-Schnipseln

Verbesserungsvorschläge, Fragen und Feature-Wünsche sind willkommen.

Alle nicht explizit als fertige Erweiterung markierten Skripte und Codes von www.ghsvs.de dienen als Ansätze / Ideen für eigene Ausarbeitung. GHSVS bzw. die jeweiligen Autoren übernehmen keinerlei Garantien beim Einsatz Ihrer kostenlosen Erweiterungen, Programme, Codes und Skripte, helfen aber gerne bei Rückfragen, soweit zeitlich möglich.

Beitrags-Schlagworte

PHP Formular Kontakt Joomla Override Plugin Download Tutorial

Kategorien: Hauptkategorie: Schnipsel; Kategorie: Joomla-Kram
Datum-Infos: Erstellt: 03.11.2015; Aktualisiert: 20.07.2021

Joomla: Codes. Erweiterungen, Wissenswertes (Schnipsel)