Erweiterungs-Entwicklung: app_dev.php / Cache umgehen / Fehler anzeigen / Autoloader

Ich beschäftige mich zur Zeit mit der Modul Entwicklung in Contao 4 und dabei habe ich ein paar Fragen:

- Die Optionen "Internen Cache umgehen" und "Fehlermeldungen anzeigen" sind in Contao 4 verschwunden. Wie setze ich diese um die Entwicklung zu erleichtern. Ich meine app_dev.php hätte den selben Effekt, bin aber nicht sicher.

- Wenn ich Contao über app_dev.php ansteuere, dann werden die Erweiterungen unter system/modules/ nicht geladen. z.B. das Screencast Module vom YouTube Tutorial). Mache ich hier was falsch?

Anhang 19560

- In der Dokumentation steht vielfach was vom Autoloader in Contao 3, und dass Contao 4 nun einen PSR-0 / PSR-4 konformen autoloader hat. Was heisst das für mich wenn ich ein modul in system/modules/ programmiere? Muss ich mich noch um etwas kümmern oder geht das vollautomatisch?

Welche Version benutzt du? Standard? Managed?
Hätte jetzt die simple Idee, dass in der

Code:

---

app/AppKernel.php

---

eventuell die Erweiterung in der Dev-Umgebung nicht geladen wird.

Unter der Dev-Umgebung sollten alle Caches deaktiviert sein.

Zitat:

---

Zitat von ihkwdiopk

Welche Version benutzt du? Standard? Managed?

---

Managed von dem .zip archiv. AppKernel.php gibt's soviel ich weiss in der Version gar nicht.

Du hast Recht - bei der managed Version gibts das nicht.

Ich würde weiter testen - andere Erweiterung installieren und gucken, ob beide, nur eine oder gar keine geladen werden. Im Zweifel immer mal wieder den Cache via Konsole löschen.

Von der Ferne, ohne jemals den Fehler selber bearbeitet zu haben - ist es immer schwierig - also viel testen und ausprobieren, ob und wie Du den Fehler eingrenzen und finden kannst.

Ok. Ich mach das jetzt halt mal manuell mit dem Cache, was anderes bleibt mir ja nicht übrig.

Weisst du zufällig die Antwort auf meine dritte Frage:

Zitat:

---

Zitat von arechsteiner

- In der Dokumentation steht vielfach was vom Autoloader in Contao 3, und dass Contao 4 nun einen PSR-0 / PSR-4 konformen autoloader hat. Was heisst das für mich wenn ich ein modul in system/modules/ programmiere? Muss ich mich noch um etwas kümmern oder geht das vollautomatisch?

---

Ich experimentiere gerade mit einem Modul das ich in Contao 3 mit dem Extension Creator generiert habe, das hat so eine config/autoload.php Datei wo die Klassen drin stehen. Das deckt sich mit dem YouTube Video Tutorial.

Wie sieht das nun aus mit dem PSR-0/PSR-4 konformen Autoloader in Contao 4? Sollte ich das anders lösen?

Soweit ich das verstehe kümmert sich Composer um den Autoloader wenn man Pakete installiert, aber da ich ja in /system/modules/meinModul operiere geht das wohl anders? Oder überhaupt nicht (also nur über den Contao 3 Weg).

Zitat:

---

Zitat von arechsteiner

Wie sieht das nun aus mit dem PSR-0/PSR-4 konformen Autoloader in Contao 4? Sollte ich das anders lösen?

---

Nach meinem Verständins brauchst Du Dich in soweit noch nicht darum kümmern, da alles aus dem modules-Ordner via Contao integriert wird.

Normalerweise wird über die jeweilige Erweiterungs-composer.json die Konventionen des Namespace geregelt. Falls Du in die Bundle-Richtung gehst, solltest Du definitv PSR-4 konform arbeiten/entwickeln.

Auch wenn es heißt, dass die Dokus auf https://docs.contao.org/ verfügbar sind, finde ich diese nichtmal ausreichend für Personen wie uns, die versuchen auf den 4er-Zug augzuspringen. Leider ist alles auch nocht nicht wirklich nach Symfony-Standards umgesetzt, so dass man sich zwar die Doku aneignen kann - jedoch noch vieles anders ist.

Einfach bei den existierenden Erweiterungen abgucken und das angeeignete Wissen der anderen gebrauchen. Anderfalls try-until-work ;)

Warte mal einige Tage, dann erscheinen Folien von mir aus dem Workshop. Darin zeige ich grob wie man aus eine C3 Erweiterung ein C4 Bundle macht (contao-bundle, kein symfony-bundle)
Das ist gar nicht schwer, wenn man einige Infos hat. Das ganze ist dann auch gleich Managed-Edition kompatibel.

Zitat:

---

Zitat von arechsteiner

Wie sieht das nun aus mit dem PSR-0/PSR-4 konformen Autoloader in Contao 4? Sollte ich das anders lösen?

Soweit ich das verstehe kümmert sich Composer um den Autoloader wenn man Pakete installiert, aber da ich ja in /system/modules/meinModul operiere geht das wohl anders? Oder überhaupt nicht (also nur über den Contao 3 Weg).

---

Egal ob du eine Extension für Contao 3 (über die Paketverwaltung) oder Contao 4 und egal ob du für Contao 4 eine Contao 3 kompatible Extension oder ein Bundle machst oder die Extension über app/Resources oder src/AppBundle umsetzt: in allen Fällen kannst du das Laden deiner Klassen entweder über den alten ClassLoader von Contao machen oder über Composer. Ersteres ist natürlich Deprecated.

Zitat:

---

Zitat von ihkwdiopk

Auch wenn es heißt, dass die Dokus auf https://docs.contao.org/ verfügbar sind, finde ich diese nichtmal ausreichend für Personen wie uns, die versuchen auf den 4er-Zug augzuspringen.

---

Hier kannst du Pull Requests machen: https://github.com/contao/docs

Zitat:

---

Zitat von BugBuster

(contao-bundle, kein symfony-bundle)

---

Ein contao-bundle ist ein symfony-bundle ;)

Zitat:

---

Zitat von Spooky

Egal ob du eine Extension für Contao 3 (über die Paketverwaltung) oder Contao 4 und egal ob du für Contao 4 eine Contao 3 kompatible Extension oder ein Bundle machst oder die Extension über app/Resources oder src/AppBundle umsetzt: in allen Fällen kannst du das Laden deiner Klassen entweder über den alten ClassLoader von Contao machen oder über Composer. Ersteres ist natürlich Deprecated[/url]

---

Wie ginge das denn genau für ein Modul unter /system/modules mit dem Composer? Den Deprecated Weg würde ich natürlich lieber vermeiden. Aber zur Zeit sind halt die meisten Tutorials darauf ausgerichtet.

Ist das eine Extension, die du nur in dieser einen Contao Installation verwendest? Wenn ja, dann einfach die Klassen über die composer.json im Root laden lassen. Dafür kannst du psr-0, psr-4, classmap und files verwenden. Siehe https://getcomposer.org/doc/04-schema.md#autoload

Zitat:

---

Zitat von Spooky

Ist das eine Extension, die du nur in dieser einen Contao Installation verwendest? Wenn ja, dann einfach die Klassen über die composer.json im Root laden lassen. Dafür kannst du psr-0, psr-4, classmap und files verwenden. Siehe https://getcomposer.org/doc/04-schema.md#autoload

---

Ja genau, nur für diese eine Website ist die Extension. Danke ich schau mir das mal an.

Ist das wirklich wahr, dass man keine Möglichkeit hat, sich Fehlermeldungen während der Entwicklung anzeigen zu lassen?
Hab die 4.4.1 Managed Edition

Zitat:

---

Zitat von marebe

Ist das wirklich wahr, dass man keine Möglichkeit hat, sich Fehlermeldungen während der Entwicklung anzeigen zu lassen?
Hab die 4.4.1 Managed Edition

---

Ich suche diese Möglichkeit auch gerade. Das Anpassen des Twig Templates reicht hier nicht. Dort kommt der Server-Log anscheinend nicht als Variable rein.
Ich würde gern sämtliches Twig hier umgehen und direkt den gesamten PHP Fehler bekommen, quasi wie gewohnt. Ist das möglich?

Wie würde man ein Live-System am Kunden debuggen? Angenommen er hat sogar FTP Zugang, dann kann er den log sehen. Dort wird aber nur die erste Zeile Fehler geloggt, nicht der Weg dahin. Wie würde man hier vorgehen?

---
Thema Cache leeren: Mach's auf dem Dampfhammer-Weg

system/config/initconfig.php (ggf. erstellen)

PHP-Code:

---

<?php
// purge contao cache
\Files::getInstance()->rrdir('var/cache/prod', true);

---

Na einfach nur statt domain.de/seite.html aufrufen, domain.de/app_dev.php/seite.html

Damit das auf einen Server geht, also nicht localhost, muss diese app_dev.php angepasst werden, wie genau steht in der selben. (siehe nächsten Beitrag)

Angepasst werden muss die app_dev.php nicht mehr. Du musst einen Benutzer mit

Code:

---

vendor/bin/contao-console contao:install-web-dir --user=USER --password

---

anlegen.

Zitat:

---

Zitat von Spooky

Angepasst werden muss die app_dev.php nicht mehr. Du musst einen Benutzer mit

Code:

---

vendor/bin/contao-console contao:install-web-dir --user=USER --password

---

anlegen.

---

danke, einen neuen Benutzer, oder hier einfach die Daten des Benutzers, der die PHP Skripte ausführt eintragen?

einen neuen Benutzer, den musst du dann angeben um app_dev nutzen zu können.

ok, hat funktioniert, aber ich dachte man sieht dann die Frontendausgabe zusammen mit den Fehlern. Statt dessen bekomme ich einen riesen Flotz mit unübersichtlichem Zeug.
Dann schau ich wohl lieber umständlich in die Log-Dateien, die hoffentlich noch so funktionieren wie früher.
Über Symfony beschwere ich mich ja nur noch privat gegenüber meinen Katzen ;)

Also Fatal Errors und sowas wird gleich direkt angezeigt, zumindest bei mir lokal, aus der Ferne habe ich da noch nicht getestet.

Nachtrag: oder musste man da noch auf Errors klicken... keine Ahnung. Es wird dir aber auch wesendlich mehr geboten als nur Fehlermeldungen.

Zitat:

---

Zitat von marebe

ok, hat funktioniert, aber ich dachte man sieht dann die Frontendausgabe zusammen mit den Fehlern. Statt dessen bekomme ich einen riesen Flotz mit unübersichtlichem Zeug.

---

Verstehe nicht was du meinst, zeige mal einen Screenshot.

Über die app_dev.php (die dev Umgebung) siehst du erst mal einfach das selbe wie über die app.php (die prod Umgebung). Ist ein Fehler aufgetreten, siehst du einen detaillierten Stack Trace zu dem Fehler. Oben gibt es dann 3 Tabs wo du dir auch den einfachen Stack Trace anzeigen lassen kannst.

Zitat:

---

Zitat von marebe

Dann schau ich wohl lieber umständlich in die Log-Dateien, die hoffentlich noch so funktionieren wie früher.

---

Den Stack Trace bekommst du (by default) aber nur über die app_dev.php (die dev Umgebung). Und da siehst du den Stack Trace ja eh schon direkt - wozu also noch in das Log schauen?

Dank dir Spooky über app_dev.php läd der Profiler und auch Fehlermeldungen werden damit ausgegeben. Alles "wunderschön" formatiert :D
Einzig. Das Ding frisst Ressourcen... hui ui ui

Ja, der hohe Ressourcen Verbrauch der Dev Umgebung ist schon öfter mal ein Problem...

Zitat:

---

Zitat von Spooky

Ja, der hohe Ressourcen Verbrauch der Dev Umgebung ist schon öfter mal ein Problem...

---

Ja, verzögert allein das Laden der Seite um mehrere Sekunden und verabschiedet sich lokal schon mit nem eigenen out of memory :D
Naja, für mich eher unbrauchbar. Ich werde mir was anders ausdenken, um wieder gut debuggen zu können.

Danke dir.

Zitat:

---

Zitat von Spooky

Verstehe nicht was du meinst, zeige mal einen Screenshot.

---

da kommt das:
Anhang 19600

werde erstmal die Templates ausputzen - da scheint der Pfad für die colorbox noch nicht zu stimmen. Danach probier ichs dann nochmal, ob es für mich taugt

Zitat:

---

Zitat von marebe

da kommt das:
Anhang 19600

---

Genau. Was genau ist für dich da jetzt ein "riesen Flotz mit unübersichtlichem Zeug"?

Zitat:

---

Zitat von Spooky

Genau. Was genau ist für dich da jetzt ein "riesen Flotz mit unübersichtlichem Zeug"?

---

das ging ja unter dem Screenshot noch ein paar Meter weiter mit der kompletten HTML-Ausgabe der Seite, die als Parameter einfloss. Passt schon - hier werden eben auch die ganzen übergebenen Parameter mit ausgegeben, was ja manchmal durchaus Sinn machen kann. Muss mich halt umgewöhnen und hoffen, dass der Speicher reicht.

Mal ganz nüchtern gefragt. Kann man hier auch einfach wieder eine normale php Exception bzw. Fehlermeldungen direkt "in your face" bekommen? An Symphony vorbei mit seinen Debuggern, einfach als ob man normal eine PHP Datei hat.

Alternative: Bekommt man in das Twig Template den php debug_backtrace. Das wäre auch ok.

Contaos ehemalige Debugger-Leiste war super für die DB-Query-Anzahl und Exe. time, jetzt braucht das alles zu viele Ressourcen.

Zitat:

---

Zitat von Tim G

Mal ganz nüchtern gefragt. Kann man hier auch einfach wieder eine normale php Exception bzw. Fehlermeldungen direkt "in your face" bekommen? An Symphony vorbei mit seinen Debuggern, einfach als ob man normal eine PHP Datei hat.

Alternative: Bekommt man in das Twig Template den php debug_backtrace. Das wäre auch ok.

Contaos ehemalige Debugger-Leiste war super für die DB-Query-Anzahl und Exe. time, jetzt braucht das alles zu viele Ressourcen.

---

Man kann es wie folgt konfigurieren: Man legt eine app/config/config_dev.yml an.

Code:

---

# Features des Profilers deaktiveren
web_profiler:
    toolbar: false
    intercept_redirects: false
   
# Den gesamten Profiler deaktivieren, obige Einstellungen sind dann obsolet
framework:
    profiler: false

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

---

Damit das ganze auch geladen wird, muss man ggf. den Cache leeren:

Code:

---

vendor/bin/contao-console cache:clear --env dev --no-warmup

---

@webstar: Ich danke dir, das hat mir sehr geholfen! VG, Tim

Zitat:

---

Zitat von webstar

Man kann es wie folgt konfigurieren: Man legt eine app/config/config_dev.yml an.

Code:

---

# Features des Profilers deaktiveren
web_profiler:
    toolbar: false
    intercept_redirects: false
   
# Den gesamten Profiler deaktivieren, obige Einstellungen sind dann obsolet
framework:
    profiler: false

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

---

Damit das ganze auch geladen wird, muss man ggf. den Cache leeren:

Code:

---

vendor/bin/contao-console cache:clear --env dev --no-warmup

---

---

Btw. Vorsicht: wenn man neben der config_dev.yml auch noch eine config.yml für allgemeine Konfigurationen benutzt (wie man es von Symfony gewohnt ist), darf man nicht vergessen am Anfang ein

Code:

---

imports:
    - { resource: config.yml }

---

in der config_dev.yml einzufügen, ansonsten sind die Konfigurationen aus der config.yml nicht im Dev Environment vorhanden :). (Bin ich heute darüber gestolpert.)

Guten Tag,

hat sich hier mittlerweile schon etwas getan, damit die Fehlermeldung wie gewohnt (contao <=3, normale php datei) angezeigt werden?

Vielen Dank

Was genau meinst du damit?

Zitat:

---

Zitat von Spooky

Was genau meinst du damit?

---

Hab mich nun etwas damit beschäftigt und ich denke es führt kein Weg daran vorbei mir das ganze mit dem Composer usw beizubringen

Mir sagen leider die ganzen begriffe wie Composer, SSH, Komandozeile nur schleierhaft etwas und ich wüsste jetzt nicht mal wie und wo genau ich den Befehl

hp vendor/bin/contao-console contao:install-web-dir --user=USER --password=PASSWORD

eingeben soll. (Ja Kommandozeile .. aber wie rufe ich die auf? Wäre das zB der Weg mit dem Programm Putty beispielsweise?)

Sry ich verstehe die Zusammenhänge noch nicht.

Ab Contao 4.5 kannst du Benutzername & Passwort für die app_dev.php auch über den Contao Manager setzen.

Zitat:

---

Zitat von Spooky

Ab Contao 4.5 kannst du Benutzername & Passwort für die app_dev.php auch über den Contao Manager setzen.

---

ah cool! Vielen Dank

Genau sowas meinte ich mit meinem ersten Post :D

Und ab Contao 4.8 wird es gar nicht mehr nötig sein ;)