Best Practices: Vorhandenes Modul erweitern in Contao 4.x

Guten Tag!

Nach sehr langer Recherche und missglückten Versuchen das Event-Liste-Modul um ein Feld wie "Teilnehmerzahl" zu erweitern, frage ich mal hier. Die meisten Tutorials handeln von der Modulentwicklung, nicht von einer schlichten Ergänzung. Auch fehlen Dateien die oft genannt werden, fangen meistens mit "dca" an, sind 5 Jahre alt oder älter. Wie erstelle ich updatesicher und elegant solche Anpassungen?

Ich habe Erfahrungen mit Custom Elements. Doch wäre es in diesem Fall bequemer schlicht die Event-Liste um diese eine Eintragsmöglichkeit zu erweitern.

HTML-Code:

---

<p class="attendance">Teilnehmerzahl: <?= $this->attendance ?></p>

---

Soweit wäre ich schonmal.

Vielen Dank,

dness

Schau mal hier unter app/Resources/
http://de.contaowiki.org/Ordner_und_Dateien_in_Contao_4

Insgesamt 6 Stunden probiere ich herum ein kleines Textfeld im BE anzulegen, auch mithilfe der Seite http://de.contaowiki.org/Ordner_und_Dateien_in_Contao_4. Das ist eindeutig zu lang. Ich mache Webdesign- und entwicklung schon seit Jahren mit verschiedenen CMS. Wenn ich es mal geschafft habe, werde ich einen kleinen Schritt-für-Schritt Guide schreiben. Damit es anderen erspart bleibt.
Unten stehender Code wurde entnommen und abgewandelt aus https://docs.contao.org/books/manual...nzufuegen.html. Ich verstehe das gerade soweit, dass sich ab Contao 4 eigentlich nur die Pfade geändert haben. Im Netz finde ich nichts weiter mit meinen Suchbegriffen.

Wie ist mein Stand bisher:

- im Verzeichnis /app ein neues Verzeichnis angelegt: /Resources. Dort wiederum /contao. Dieses beinhaltet /dca und /languages ( + /de).

/dca enthält tl_calendar_events.php:

PHP-Code:

---

$GLOBALS['TL_DCA']['tl_calendar_events']['palettes']['default'] = str_replace
(
    'attendance',
    'attendance_number,attendance',
    $GLOBALS['TL_DCA']['tl_calendar_events']['palettes']['default']
);

// Hinzufügen der Feld-Konfiguration
$GLOBALS['TL_DCA']['tl_calendar_events']['fields']['attendance'] = array
(
    'label'     => &$GLOBALS['TL_LANG']['tl_calendar_events']['attendance'],
    'exclude'   => true,
    'inputType' => 'text',
    'eval' => array('maxlength'=>255, 'tl_class'=>'long'),
    'sql'  => "varchar(255) NOT NULL default ''"
); 


---

/languages/de enthält tl_calendar_events.php:

PHP-Code:

---

$GLOBALS['TL_LANG']['tl_calendar_events']['attendance'] = array
(
    'Teilnehmerzahl',
    'Bitte geben Sie die Teilnehmerzahl an'
); 


---

var/cache ist gelöscht, werde trotzdem im Installtool nicht zum aktualisieren der DB aufgefordert.

Viele Grüße,
dness

Es fehlt das

PHP-Code:

---

<?php

// dein code

---

Ah, und ich wundere mich warum das Syntax-Highlighting nicht greifen wollte.

Behebt das Problem aber leider noch nicht. Weder ist das Feld da noch ist nach dem Löschen des Caches die Aufforderung des Installtools bzgl Datenbank da.

Ich habe bei mir das Feld attendance nicht, deswegen habe ich es bei mir mit location probiert. Es funktioniert. Aber du hast auch den Namen des neuen Feldes vergessen einzutragen, da stand bei dir immer noch 'attendance'

PHP-Code:

---

<?php

$GLOBALS['TL_DCA']['tl_calendar_events']['palettes']['default'] = str_replace
(
    'location',
    'attendance_number,location',
    $GLOBALS['TL_DCA']['tl_calendar_events']['palettes']['default']
);

// Hinzufügen der Feld-Konfiguration
$GLOBALS['TL_DCA']['tl_calendar_events']['fields']['attendance_number'] = array
(
    'label'     => &$GLOBALS['TL_LANG']['tl_calendar_events']['attendance_number'],
    'exclude'   => true,
    'inputType' => 'text',
    'eval' => array('maxlength'=>255, 'tl_class'=>'long'),
    'sql'  => "varchar(255) NOT NULL default ''"
);

---

PHP-Code:

---

<?php

$GLOBALS['TL_LANG']['tl_calendar_events']['attendance_number'] = array
(
    'Teilnehmerzahl',
    'Bitte geben Sie die Teilnehmerzahl an'
);

---

Ich gebe dir auch den Tipp die camelCase Schreibweise für Feldnamen zu benutzen, der Core macht dies auch durchweg - attendanceNumber.

Tut mir leid mit den 6 Stunden. Und das man bei jeder kleinen Änderung den Cache leeren muss, dass ist natürlich auch mehr als doof. Da sollten demnächst Alternativen zu auftauchen. Falls man das mit app_dev.php nicht machen muss, das wäre keine Alternative, weil viele diesen Modus beim einfachen Entwickeln nicht benutzen möchten.

Bei dem String, den du für die palettes zum Ersetzen suchst, solltest du dies stärker eingrenzen.

PHP-Code:

---

    'location',
    'attendanceNumber,location', 


---

Sowas würde z.B. fehlschlagen, wenn es da ein Feld 'altlocation' o.ä. geben sollte. Besser wäre.

PHP-Code:

---

    ',location,',
    ',attendanceNumber,location,', 


---

Zitat:

---

Zitat von Andreas

Besser wäre.

PHP-Code:

---

    ',location,',
    ',attendanceNumber,location,', 


---

---

Falls location nicht das letzte Feld ist, in der palette also auch wirklich ein Komma danach kommt!

Code:

---

{details_legend},location,teaser;{image_legend},

---

würde funktionieren

Code:

---

{details_legend};{image_legend},

---

würde nicht funktionieren (location,teaser könnte bereits von einer anderen Extension entfernt oder an eine andere Stelle platziert worden sein). Um richtig sicher zu sein müsstest Du preg_replace() verwenden und nach location gefolgt von Komma, oder Semikolon oder Ende des Strings suchen.

Danke Andreas für die Hilfe und Erklärungen soweit.

Wir sind schonmal soweit, dass die Datenbank aktualisiert werden will. Danach passiert dennoch nichts. Anders gesagt: Es erscheint kein Textfeld im Events-Backend

Code zurzeit:

PHP-Code:

---

<?php

$GLOBALS['TL_DCA']['tl_calendar_events']['palettes']['default'] = str_replace
(
    'attendance',
    'attendanceNumber,attendance',
    $GLOBALS['TL_DCA']['tl_calendar_events']['palettes']['default']
);

// Hinzufügen der Feld-Konfiguration
$GLOBALS['TL_DCA']['tl_calendar_events']['fields']['attendanceNumber'] = array
(
    'label'     => &$GLOBALS['TL_LANG']['tl_calendar_events']['attendanceNumber'],
    'exclude'   => true,
    'inputType' => 'text',
    'eval' => array('maxlength'=>255, 'tl_class'=>'long'),
    'sql'  => "varchar(255) NOT NULL default ''"
);

---

und

PHP-Code:

---

<?php

$GLOBALS['TL_LANG']['tl_calendar_events']['attendanceNumber'] = array
(
    'Teilnehmerzahl',
    'Bitte geben Sie die Teilnehmerzahl an'
);

---

Zitat:

---

Zitat von Andreas

Und das man bei jeder kleinen Änderung den Cache leeren muss, dass ist natürlich auch mehr als doof. Da sollten demnächst Alternativen zu auftauchen. Falls man das mit app_dev.php nicht machen muss, das wäre keine Alternative, weil viele diesen Modus beim einfachen Entwickeln nicht benutzen möchten.

---

Ich habe mir schon überlegt ob ich einen Cronjob am Server anlege, wo mir ein Shellskript den Cacheordner im Minutentakt löscht ...

Zitat:

---

Zitat von dness

Danke Andreas für die Hilfe und Erklärungen soweit.

Es erscheint kein Textfeld im Events-Backend

PHP-Code:

---

<?php

$GLOBALS['TL_DCA']['tl_calendar_events']['palettes']['default'] = str_replace
(
    'attendance',
    'attendanceNumber,attendance',
    $GLOBALS['TL_DCA']['tl_calendar_events']['palettes']['default']
);

---

---

Das verwundert nicht. In $GLOBALS['TL_DCA']['tl_calendar_events']['palettes']['default'] steht das hier

Code:

---

'{title_legend},title,alias,author;{date_legend},addTime,startDate,endDate;{details_legend},location,teaser;{image_legend},addImage;{recurring_legend},recurring;{enclosure_legend:hide},addEnclosure;{source_legend:hide},source;{expert_legend:hide},cssClass,noComments;{publish_legend},published,start,stop'

---

(siehe vendor/contao/calendar-bundle/src/Resources/contao/dca/tl_calendar_events.php)

Du willst jetzt 'attendance' durch 'attendanceNumber,attendance' ersetzen. Da 'attendance' dort aber gar nicht vorkommt wird auch nichts ersetzt. Du musst das schon so machen, wie Andreas in #6 geschrieben hat.

Ah! Danke! Jetzt läuft es.

Mein Problem war, dass ich die Funktion hier missverstanden habe. str_replace kenne ich, ich dachte dieser Block ist dafür verantwortlich $this->attendanceNumber durch den jeweiligen Eintrag aus der Datenbank zu ersetzen. Müsste etwas intuitiver sein, so sieht es etwas wie ein Hack aus.

Danke an alle Helfenden. Trotz meinem Gewusel konnte ich noch einiges lernen wie Contao auf Programmseite funktioniert.

Zitat:

---

Zitat von Samson1964

Ich habe mir schon überlegt ob ich einen Cronjob am Server anlege, wo mir ein Shellskript den Cacheordner im Minutentakt löscht ...

---

Aber bitte nicht bei Webgo, ich bin nämlich auch da ;) und wenn da der Server blockiert, dann weiß ich ja wer's war ;)

Zitat:

---

Zitat von dness

Mein Problem war, dass ich die Funktion hier missverstanden habe. str_replace kenne ich, ...

---

Und ich sach noch .... Ne, da wird einfach nur der String, der für den Aufbau der "palettes" sorgt, um den Feldnamen deines neuen Feldes erweitert. Ich bin davon ausgegangen, dass du dieses Feld "attendence" durch eine Erweiterung bei dir vorliegen hast.

Zitat:

---

Zitat von Andreas

weil viele diesen Modus beim einfachen Entwickeln nicht benutzen möchten.

---

Warum genau?

Zitat:

---

Zitat von fiedsch

location,teaser könnte bereits von einer anderen Extension entfernt oder an eine andere Stelle platziert worden sein. Um richtig sicher zu sein müsstest Du preg_replace() verwenden und nach location gefolgt von Komma, oder Semikolon oder Ende des Strings suchen.

---

Geht das noch eleganter? Wenn ich die Extensions überblicken kann, überschreibe ich auch mal direkt den Wert von

Code:

---

$GLOBALS['TL_DCA']['tl_calendar_events']['palettes']['default']

---

. Aber ihr habt recht.

Ist preg_replace() die ultimative Lösung, um mehrere Extensions garantiert konfliktfrei zu betreiben?

Manche berichten über Performance Einbußen. Dann der zusätzliche Kram im HTML. Die aufwendigere URL zum Eintippen. Das Einzige was wir möchten ist doch, dass Änderungen die wir vornehmen direkte Auswirkungen haben. Schließlich sind wir ja im BE eingeloggt, da ist dann doch davon auszugehen, dass wir Veränderungen vornehmen.

Na gut, ok, vielleicht muss man dies nochmal differenzierter betrachten - einfaches Einpflegen von Inhalten und Änderungen am System, bzw. Erweiterungsentwicklung.

Außerdem ist alles was neu und anders ist erstmal doof ;)

Zitat:

---

Zitat von mpietsch

Ist preg_replace() die ultimative Lösung, um mehrere Extensions garantiert konfliktfrei zu betreiben?

---

Man kann den String auch am Ende mit ner eigenen Palette einfach ergänzen.

PHP-Code:

---

$GLOBALS['TL_DCA']['tl_calendar_events']['palettes']['default'] .= ';{foobar_legend},myFoo,myBar'; 


---

In der Praxis reicht es aber eigentlich immer, wenn man sich an ein Feld anhängt, welches wahrscheinlich nie entfernt wird und dieses so genau wie möglich sucht.

Edit: Zumindesten das führende Komma sollte man bei der Suche mit str_replace() immer mit angeben, weil das jedes Feld besitzt.

Zitat:

---

Zitat von Andreas

Manche berichten über Performance Einbußen.

---

Das ist auch der Fall, denn ohne Cache und noch dazu internen Cache von Contao ist die Seite natürlich langsamer (genau so wie in Contao 3). Du kannst allerdings mit folgender config_dev.yml die Performance verbessern (dafür hast du aber keinen Profiler mehr):

Code:

---

# Den gesamten Profiler deaktivieren, obige Einstellungen sind dann obsolet
framework:
    profiler: false

# Die Ausgabe der Exception vereinfachen   
services:
    twig.exception_listener:
        class: stdObject

---

Zitat:

---

Zitat von Andreas

Die aufwendigere URL zum Eintippen.

---

Naja... app_dev.php einmalig eingeben kann wohl nicht ein Grund sein.

Zitat:

---

Zitat von Andreas

Das Einzige was wir möchten ist doch, dass Änderungen die wir vornehmen direkte Auswirkungen haben.

---

Wenn es dir nur um den internen Cache von Contao geht (also alles unter Resources/contao), dann kannst du auch ein

Code:

---

cache:clear --no-warmup

---

ohne nachfolgendem cache:warmup machen. Oder wenn du breits einen voll aufgebauten Cache hast, könntest du einfach manuell var/cache/prod/contao löschen. Der interne Cache baut sich ja nicht von selbst neu auf.

Zitat:

---

Zitat von Andreas

Schließlich sind wir ja im BE eingeloggt, da ist dann doch davon auszugehen, dass wir Veränderungen vornehmen.

---

Nein, wieso sollte man davon ausgehen? Es gibt in Contao keine Möglichkeit bei einem BackendUser zwischen einem Developer, der Änderungen an den internen Strukturen von Contao durchführt, und einem regulären User zu unterscheiden.

...dafür hast du aber keinen Profiler mehr...

> Was ist das? Ist das diese Leiste, die man da unten sieht?

...obige Einstellungen sind dann obsolet...

> Welche Einstellungen meinst du?

...Die Ausgabe der Exception vereinfachen...

> Was ist das?

...

Code:

---

cache:clear --no-warmup

---

> Ich habe mal versucht mich über eine Suche schlau zu machen, aber ich kann einfach nicht finden, was man mit der Option (oder Funktion?) cache: machen kann und was diese Parameter(?) clear, --no-warmup ... genau bedeuten.

...manuell var/cache/prod/contao löschen. Der interne Cache baut sich ja nicht von selbst neu auf...

> Ich dachte, wenn ich var/cache/prod[/contao] lösche, dann kann ich weiterarbeiten und im Hintergrund wird erkannt, dass es keinen Cache gibt.

Also ich bin einiges durcheinander.

Zitat:

---

Zitat von Andreas

...dafür hast du aber keinen Profiler mehr...

> Was ist das? Ist das diese Leiste, die man da unten sieht?

---

Naja, nicht nur die Leiste, sondern im genauen das, was man in dieser Leiste machen kann ;)

Zitat:

---

Zitat von Andreas

...obige Einstellungen sind dann obsolet...

> Welche Einstellungen meinst du?

---

Das war ein Copy & Paste von hier, jedoch ohne

Code:

---

# Features des Profilers deaktiveren
web_profiler:
    toolbar: false
    intercept_redirects: false

---

Zitat:

---

Zitat von Andreas

...Die Ausgabe der Exception vereinfachen...

> Was ist das?

---

Wenn ein PHP Fehler auftritt, siehst du über app_dev.php ja genauere Informationen über den Fehler. Mit diesen Settings wird diese Ausgabe vereinfacht und verbraucht dadurch weniger Performance. Wobei ich diese Option in den meisten Projekten nicht mehr verwende, da ich die aufwändigere Ausgabe oft doch hilfreicher finde.

Zitat:

---

Zitat von Andreas

...

Code:

---

cache:clear --no-warmup

---

> Ich habe mal versucht mich über eine Suche schlau zu machen, aber ich kann einfach nicht finden, was man mit der Option (oder Funktion?) cache: machen kann und was diese Parameter(?) clear, --no-warmup ... genau bedeuten.

---

cache:clear ist das Symfony Command zum löschen des Caches. Seit Symfony 3.3 (?) ist die Verwendung von cache:clear ohne --no-warmup deprecated. Daher eben cache:clear --no-warmup. Das löscht den Cache ohne in neu aufzuwärmen. Ist also dasselbe wie wenn man manuell var/cache/prod löscht. cache:warmup baut dann denn Cache neu auf (inkl. dem internen Cache von Contao).

Zitat:

---

Zitat von Andreas

...manuell var/cache/prod/contao löschen. Der interne Cache baut sich ja nicht von selbst neu auf...

> Ich dachte, wenn ich var/cache/prod[/contao] lösche, dann kann ich weiterarbeiten und im Hintergrund wird erkannt, dass es keinen Cache gibt.

---

Genau, das meine ich ja damit. Der interne Cache baut sich nur auf, wenn du das Install Tool besuchst oder cache:warmup aufrufst.

Vielen Dank für diese Infos.

Servus,

dank Eurer Anleitung habe ich es geschafft, dem Kommentarmodul, 4 weitere Felder hinzuzufügen. Herzlichen Dank dafür.
Nun scheitere ich aber, die zusätzlichen Felder im Formular einzufügen. Wenn ich mod_comment_form.html5 richtig verstanden habe, sucht es nach den Feldern und gibt diese im Frontend aus.

Wo muss ich hier noch anpassen, damit die neuen Felder auch ausgegeben werden?

Evtl. reicht es, wenn du diese Felder im Template mod_comment_form hinzufügst, so wie die anderen dort auch eingetragen sind.

Das ist ja mein Problem:

hier nur der Formularteil von mod_comment_form.html5

PHP-Code:

---

<form<?php if ($this->action): ?> action="<?= $this->action ?>"<?php endif; ?> id="<?= $this->formId ?>" method="post">
        <div class="formbody">
          <input type="hidden" name="FORM_SUBMIT" value="<?= $this->formId ?>">
          <input type="hidden" name="REQUEST_TOKEN" value="{{request_token}}">       
          <?php foreach ($this->fields as $field): ?>
            <?= $field->parse() ?>
          <?php endforeach; ?>
          <div class="widget widget-submit">
            <button type="submit" class="submit"><?= $this->submit ?></button>
          </div>
        </div>
      </form>

---

Das Template sucht nach den Feldern und erzeugt diese. Die neuen Felder werden nicht vom Modul zur Verfügung gestellt also nicht erzeugt.
Muss man nun 'fields' erweitern, wie das mit 'palettes' gemacht wurde?

Zitat:

---

Zitat von bahnfuehrer

Servus,

dank Eurer Anleitung habe ich es geschafft, dem Kommentarmodul, 4 weitere Felder hinzuzufügen. Herzlichen Dank dafür.
Nun scheitere ich aber, die zusätzlichen Felder im Formular einzufügen. Wenn ich mod_comment_form.html5 richtig verstanden habe, sucht es nach den Feldern und gibt diese im Frontend aus.

Wo muss ich hier noch anpassen, damit die neuen Felder auch ausgegeben werden?

---

Das Kommentar Modul kannst du eigentlich nicht sauber erweitern. Die Felder sind hard gecodet. Siehe https://github.com/contao/comments-b....php#L185-L241

Sorry, sehe gerade, dass ich bei 3.5 geschaut habe, da gab's noch kein foreach().
3.5
https://github.com/contao/core/blob/...ent_form.html5
4
https://github.com/contao/comments-b...ent_form.html5

Und was passiert, wenn du dort die Felder manuell einträgst? Lässt sich dies dann noch absenden und kann man diese manuellen Felder dann mit dem HOOK addComments auffangen?

Das sollte funktionieren. Also manuell die Felder in das Template einfügen und dann per addComment Hook den Datenbankeintrag des Kommentars dementsprechend aktualisieren.

Zitat:

---

Zitat von Spooky

Das Kommentar Modul kannst du eigentlich nicht sauber erweitern. Die Felder sind hard gecodet. Siehe https://github.com/contao/comments-b....php#L185-L241

---

Das habe ich befürchtet.
In einem ersten Versuch habe ich die Bundledateien direkt editiert/erweitert. Backend und Frontend, alles war da. Das Problem hier: ausfüllen und speichern/senden hat nur im Backend funktioniert.

Zitat:

---

Zitat von Andreas

Sorry, sehe gerade, dass ich bei 3.5 geschaut habe, da gab's noch kein foreach().
3.5
https://github.com/contao/core/blob/...ent_form.html5
4
https://github.com/contao/comments-b...ent_form.html5

Und was passiert, wenn du dort die Felder manuell einträgst? Lässt sich dies dann noch absenden und kann man diese manuellen Felder dann mit dem HOOK addComments auffangen?

---

Trage ich die Felder so ein:

PHP-Code:

---

<div class="widget">
            <?= $this->fields['company']->generateLabel() ?>
            <?= $this->fields['company']->generateWithError() ?>
</div>

---

bekomme ich einen Fehler. Ersetze ich hier 'company' (durch mich angelegt) durch ein Feld aus dem Modul (z.B. 'website') erscheint das Feld im Formular.
addComments HOOK / könnt Ihr mir das erklären?

Du musst sie manuell einfügen. Also einfach direkt als HTML Code. Oder du erzeugst die Widgets und deren Ausgabe on-the-fly im Template, damit du nicht selbst das zugehörige HTML copy & pasten musst.

Zitat:

---

Zitat von Spooky

Du musst sie manuell einfügen. Also einfach direkt als HTML Code. Oder du erzeugst die Widgets und deren Ausgabe on-the-fly im Template, damit du nicht selbst das zugehörige HTML copy & pasten musst.

---

also das

HTML-Code:

---

<div class="widget widget-text">
                                <label for="ctrl_company">Firma</label>
                                <input name="company" id="ctrl_company" class="text" value="" maxlength="128" type="text">
                        </div>

---

eingefügt / Fromularfeld erscheint.

Was fehlt noch, damit mir der Inhalt des Feldes in die DB geschrieben wird?

Zitat:

---

Zitat von bahnfuehrer

Was fehlt noch, damit mir der Inhalt des Feldes in die DB geschrieben wird?

---

Der Hook wo du eben genau das machst ;)

In dem Hook https://docs.contao.org/books/api/ex...ddComment.html, kannst du erstmal die Variablen, die da ankommen checken.

Frage an @Spooky, ich glaube das geht nicht mehr mit dump() in Contao 4, oder? Ich habe das in 3.5 meistens so gemacht.

PHP-Code:

---

public function myAddComment($intId, $arrSet, Comments $objComments)
{
  // Do something
  dump($intId);
  dump($arrSet);
  dump($objComments);
} 


---

Und dann irgendwie mit nem Model die zwei Felder zum Datensatz hinzufügen. Evtl. ist das $objComments bereits ein Model, ansonsten in etwa so.

PHP-Code:

---

$myCommentsModel = \CommentsModel::findByPk($intId);

$myCommentsModel->company = 'die Firma';
$myCommentsModel->zweitesFeld = 'Wert von dem zweiten Feld';

$commentsModel->save(); 


---

Mit den Models, das ist sehr praktisch, da braucht man nicht mit den Database-Klassen rumzuhantieren und keinen SQL-Query zu schreiben.