contao 5

[css-umsetzung]

Habe ich echt das release der stable von Contao 4 verschlafen, ich dachte mit der 3.5.8 bin ich vorerst aktuell?

Deprecated notice: Using Controller::generateFrontendUrl() without $blnFixDomain has been deprecated and will no longer work in Contao 5.0. in system/modules/core/library/Contao/Controller.php on line 1093

[Spooky]

Nein, du hast nichts verschlafen, das ist nur eine Deprecated Notice die dir sagt, dass wenn du (oder eine Extension) die Funktion

\Controller::generateFrontendUrl(…) 

einsetzt und den letzten Parameter nicht auf true setzt, es für Contao 5 nicht mehr kompatibel sein wird, da dort dieser Parameter komplett entfernt wird (in Contao 5 wird diese Funktion nur mehr die ersten zwei Parameter haben).

[Samuell]

3.5.8 ist aktuell.
Das ist eher als Info für die Zukunft zu verstehen, denke ich.
Aktuell laufen noch die Arbeiten an der Version 4.x

[css-umsetzung]

ja das ist mir schon klar aber da jetzt schon so einen Alarm zu schlagen
da mach ich ganz unbedarft ein update und mir fliegt das ganze System um die Ohren.

[Spooky]

Eine Deprecated Notice ist kein Alarm, sondern nur ein Hinweis, wie der Name schon sagt. Die Deprecated Notice siehst du auch normalerweise nicht.

[Samuell]

Unbedarft ein Update = blind = Fahrlässig ;-)

Augen auf beim Autokauf ... und klicke nie einfach mal irgendwas, wenn Du nicht genau weist was Du tust :-P
Mal abgesehen davon dürfte Autoupdate auf 4.3 noch garnicht gehen.
Glaub ich zumindest mal. Getestet hab ich es nicht.

[css-umsetzung]

Ich mache bestimmt keine unbedarften Updates und im Changelog stand nichts von irgendwelchen hinzugefügten Deprecated Meldungen.

Und schon gar keine Autoupdates.

Wenn ich eine Webseite bearbeite, habe ich grundsätzlich alle error Warnungen, außer Notice Meldungen eingeschaltet,
damit ich sehe wo es Probleme geben könnte, insbesondere bei dem aktuellem Projekt da ich die komplette PHP 7 Tauglichkeit teste.

Ein Eintrag im Contao Systemlog hätte ich da sinnvoller gefunden, als direkt eine Seite damit zuzupflastern.

[Spooky]

Ich mache bestimmt keine unbedarften Updates und im Changelog stand nichts von irgendwelchen hinzugefügten Deprecated Meldungen.

Und schon gar keine Autoupdates.

Wenn ich eine Webseite bearbeite, habe ich grundsätzlich alle error Warnungen, außer Notice Meldungen eingeschaltet,
damit ich sehe wo es Probleme geben könnte, insbesondere bei dem aktuellem Projekt da ich die komplette PHP 7 Tauglichkeit teste.

Ein Eintrag im Contao Systemlog hätte ich da sinnvoller gefunden, als direkt eine Seite damit zuzupflastern.

Derartige Depreacted Meldungen sind völlig normal. Du schreibst ja selbst, dass du Fehlermeldungen eingeschalten hast, um solche Problem zu erkennen. Wenn du bspw. den Datenbanktreiber auf 'MySQL' stellst wirst du unter PHP 5.6 auch Deprecated Notices bekommen (diese kommen diesmal aber von PHP selbst, nicht von Contao) und unter PHP 7 einen Fatal Error.

[BugBuster]

Das Deprecated Meldungen in der PHP Error Log erscheinen ist völlig OK, da landen die von PHP selbst ja auch.
Nebenbei sehe ich nun auch wie man sowas generiert, hatte ich auch noch nicht genutzt, obwohl ich auch Deprecated Methoden in meinen Erweiterungen habe. Steht zwar in den PHPDocs, aber wer schaut da schon rein :-)

[css-umsetzung]

Um hier nochmal etwas dazu zu sagen.

wenn ich in meinen PHP Einstellungen sage, das ich deprecated Warnungen nicht sehen möchte, ist es ein bissel doof, wenn der contao eigene Errorhandler, dieses nicht berücksichtigt.

Ich habe jetzt zwei Probleme:

Da ich wegen einigen (aus meiner Sicht vorhandenen) Contao Fehlern in der generateFrontendUrl diesen Wert nicht auf true setzen darf, aber es sehen muss, wann wirkliche Fehler auftreten, bekomme ich mein Projekt zugepflastert mit diesen Deprecated Meldungen.

Ich kann diesen Wert nicht auf true setzen, da ich unter anderem unseren eigenen Newsletter teste, der links zu verschiedenen Domains über das generateFrontendUrl generiert, da der Cron ja über eine .de läuft.
In der de wird dann keine Domain vorne angestellt, in den anderen Domains schon.

Wenn also weitere deprecated Meldungen auftauchen die irgendwann mal im Jahre 2020 zum tragen kommen, bin ich als Entwickler angeschissen.

[Spooky]

Angeschissen bist du nur, wenn du dumm genug bist auf einer Live Seite Fehlermeldungen im Frontend anzeigen zu lassen.

Darüberhinaus kannst du ja trotzdem den letzten Parameter auf true setzen und danach überprüfen ob die generierte URL ein Schema hat - wenn nicht fügst du \Environment::get('base') vorne an.

[css-umsetzung]

Es geht hier nicht um LIVE oder nicht LIVE ich rede von einer Entwicklungsumgebung die jetzt nicht mehr richtig prüfbar ist.
Und ich rede von einem errorhandler, der meine PHP Einstellungen ignoriert.

Und es geht nicht nur um diese eine Funktion, obwohl ich ja eh der Meinung bin das diese Grundlegende Änderung ja auch nichts in einem xx.xx.x Update zu suchen hat.
Ich verwende diese Funktion an vielen Stellen und bin dann in der Pflicht eine extra Prüfung einzubauen nur weil ein Parameter nicht mehr diese Funktionsweise hat die er mal hatte, bzw. er hat diese Funktion ja immer noch, aber MOTZT mich an obwohl ich sagte interessiert mich nicht.

[Spooky]

Deprecated Meldungen können von überall kommen, nicht nur von Contao. Und selbst wenn du den letzten Parameter nicht benutzt musst du ja bis jetzt schon zusätzliche Logik in deinem Code haben, der die richtige Domain voranstellt, also ist auch dein Argument von vermeintlich zusätzlich nötiger Logik hinfällig.

[css-umsetzung]

Ich glaube du verstehst einfach nur das Problem nicht,
daher hat das dann wohl keinen Sinn da weiter drüber zu diskutieren.

Es gibt ja nicht umsonst eine Einstellung ~E_DEPRECATED in PHP

[Spooky]

Du beschwerst dich, dass die Funktion generateFrontendUrl bei falscher Anwendung nun eine Deprecated Notice ausgibt. Daran ist aber nichts falsch oder ungewöhnlich.

Wenn es dir stattdessen darum geht, dass der Error Handler von Contao keine Deprecated Notices ausgeben bzw. loggen soll (warum auch immer du das möchtest), dann kannst du das als Issue auf GitHub vorschlagen.

[css-umsetzung]

Falsch,

es ist ja keine falsche Anwendung, wir reden von contao 3.5.8 falsch wäre es wenn ich in 5.x wäre
in einer 4er oder eventuell auch in einer 3.6er würde ich diese Meldung akzeptieren. aber die 3.5er ist eine LTS?

Das heißt für mich ja eigentlich das dort keine Grundlegenden Änderungen in diesen kleinen mini Updates kommen die mich in der Entwicklung dermaßen behindern, es sei denn es gibt ein Sicherheitsproblem.

[Spooky]

Nein, in der LTS Version, bzw. in Bugfix Versionen gemäß Semantic Versioning werden nicht nur Security Fixes umgesetzt, sondern auch Bugfixes. Die Änderung bzgl. der generateFrontendUrl ist Teil eines wichtigen Bugfixes für einen weitreichenden Fehler, der schon sehr lange existiert. Im Zuge dessen wurde auch die Deprecated Notice eingebaut, damit Entwickler so früh wie möglich davon erfahren, dass die Funktion sich in einer zukünftigen Version grundlegend ändern wird.

Wie schon mehrmals erwähnt ist das alles völlig normal und korrekt. Es kann dir auch bei PHP Bugfix Updates passieren, dass dir plötzlich eine Funktion oder Anwendungsart einer Funktion plötzlich Deprecated gemacht wird. Was ja an sich kein Problem ist, da die Funktion ansonsten wie gehabt weiter funktionieren wird.

[Alphawolf]

Habe über Google hier her gefunden und habe das selbe Problem wie css-umsetzung.

Das Problem ist glaube ich für den Thread-Ersteller nicht, dass die Funktionsweise der Methode generateFrontendUrl gefixt wurde, sondern dass dies a) in einem "point release" passiert ist, und b) das in der Deprecated Notice empfohlene Setzen von $blnFixDomain die Funktionsweise der Funktion grundlegend ändert und damit vorhandene Seiten schrotten kann, ohne dass man dies in einem "point release" erwartet.

Darüber hinaus stehe ich wie gesagt vor dem selben Problem wie css-umsetzung, was den Parameter $blnFixDomain angeht: Soweit ich das überblicke, macht das Setzen von $blnFixDomain ja nichts anderes, als dass er bei Cross-Domain-Links die Domain nun mit voranstellt. Das tut es, indem es die Domain des übergebenen Page Objects mit \Environment::get('base') vergleicht. Das Problem in meinem Fall ist nun folgendes: Für einen Newsletter hole ich für Links, die ich mit generateFrontendUrl generiere, jeweils den Link einer Seite und setzte bisher die Domain manuell davor. Auf diese Weise hatte ich homogenen Code für beide meiner Site Roots, deren Links in einer Email verschickt wurden.

Durch das jetzige Setzen von $blnFixDomain passiert aber folgendes: Für meine .de Domain setzt generateFrontendUrl keine Domain mit voran (da ich den Cron für den Newsletter als wget über die .de Domain aufrufe.) Soweit alles gut und wie bisher. Neu ist nun aber, dass generateFrontendUrl für die .com-Links meiner Seite die Domain automatisch mit hinzufügt (da sie sich von der .de-Domain meines wget-Aufrufs unterscheiden). Das heißt, ich muss nun händisch einen Workaround einbauen, da die Änderung aus einem "Point Release" (!) die Code Logik einer systemimmanenten Funktion ändert, deren Tragweite (siehe Newsletter-Problem oben) mir nicht klar ist, das es sich - ich wiederhole mich - nur um einen "Point Release" handelt.

Ist diese Änderung an der Funktion so final? Ich kann mir irgendwie nicht vorstellen, dass eine derartige Änderung gewollt sein kann, bei der man als Entwickler zusätzlich einen Workaround á la

Darüberhinaus kannst du ja trotzdem den letzten Parameter auf true setzen und danach überprüfen ob die generierte URL ein Schema hat - wenn nicht fügst du \Environment::get('base') vorne an.

drumrumbauen muss, obwohl man ja Contao gerade als Framework nutzt, um so etwas eben nicht machen zu müssen.

[BugBuster]

Was mich grad wundert ist, dass hier:

Using Controller::generateFrontendUrl() with $strForceLang has been deprecated and will no longer work in Contao 5.0
Using Controller::generateFrontendUrl() without $blnFixDomain has been deprecated and will no longer work in Contao 5.0

Der dritte Parameter ist deprecated ist wenn man ihn benutzt, der vierte wenn man ihn nicht benutzt?
Wie soll das später aussehen in 5.0 ? Der dritte kann ja laut Meldung nicht wegfallen da man sonst den vierten nicht setzen könnte, wozu man aber angeblich gezwungen wird.

[Spooky]

Das Problem ist glaube ich für den Thread-Ersteller nicht, dass die Funktionsweise der Methode generateFrontendUrl gefixt wurde, sondern dass dies a) in einem "point release" passiert ist, und b) das in der Deprecated Notice empfohlene Setzen von $blnFixDomain die Funktionsweise der Funktion grundlegend ändert und damit vorhandene Seiten schrotten kann, ohne dass man dies in einem "point release" erwartet.

An der Funktionsweise von

\Controller::generateFrontendUrl 

wurde nichts geändert. In Contao 3.5.8 wurde in den Core Modulen nun der Aufruf korrekt auf …, …, null, true geändert und in der Funktion selbst ansonsten nur die Depreacted Notices hinzugefügt.

Neu ist nun aber, dass generateFrontendUrl für die .com-Links meiner Seite die Domain automatisch mit hinzufügt (da sie sich von der .de-Domain meines wget-Aufrufs unterscheiden).

Nein, automatisch passiert das nur, wenn du den letzten Parameter auf true setzt. Bist du sicher, dass du Contao 3.5.8 im Einsatz hast? In Contao 3.5.7 wurde nämlich tatsächlich die Funktion dahingehend geändert, was aber ein BC Break war und daher mit Contao 3.5.8 ein paar Stunden darauf wieder rückgängig gemacht wurde.

Ist diese Änderung an der Funktion so final? Ich kann mir irgendwie nicht vorstellen, dass eine derartige Änderung gewollt sein kann, bei der man als Entwickler zusätzlich einen Workaround á la

drumrumbauen muss

Wie gesagt, die Funktion hat sich (in Contao 3.5.8) nicht geändert. Außerdem ist das kein Workaround, sondern du musstest, ohne den letzten Parameter auf true zu setzen, oder vor Contao 3.3.0, schon immer zusätzliche Logik anwenden, um die korrekte Domain in der erzeugten URL zu erhalten.

obwohl man ja Contao gerade als Framework nutzt, um so etwas eben nicht machen zu müssen.

Wie gesagt, du musstest es ja sowieso machen. Ohne den letzten Parameter erzeugt dir Contao URLs ohne die richtige Domain (relativ zur aktuellen). Das heißt, ohne den letzten Parameter musst du dich sowieso selbst darum kümmern, dass die richtige Domain in der URL vorhanden ist - ohne Contao Framework. Was du also bräuchtest ist ein zusätzlicher Parameter namens $blnForceAbsolute, damit generateFrontendUrl in jedem Fall eine absolute URL erzeugt. Dafür müsste aber wenn dann eine neue Funktion im Controller eingefügt werden, ansonsten wird es zu messy mit der Backwards Compatibility. Also sowas wie

\Controller::generateAbsoluteUrl(…) 

Was mich grad wundert ist, dass hier:

Der dritte Parameter ist deprecated ist wenn man ihn benutzt, der vierte wenn man ihn nicht benutzt?
Wie soll das später aussehen in 5.0 ? Der dritte kann ja laut Meldung nicht wegfallen da man sonst den vierten nicht setzen könnte, wozu man aber angeblich gezwungen wird.

In Contao 5 fallen beide Parameter einfach weg und die Funktion verhält sich dann fix so, wie wenn man …, …, null, true in Contao >=3.3.0,<5-dev verwenden würde. Wenn du selbst also die Funktion jetzt schon so verwendest, dann musst du auch später für Contao 5 keine Kompatibilitätsanpassung machen.

[Spooky]

Es gibt ja nicht umsonst eine Einstellung ~E_DEPRECATED in PHP

Die Default Einstellung von Contao ist übrigens

$GLOBALS['TL_CONFIG']['errorReporting'] = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED; 

https://github.com/contao/core/blob/...fault.php#L348

Darüberhinaus wird die Error Funktion so aufgerufen:

@trigger_error 

was zumindest in meiner Server Umgebung dazu führt, dass der Error nie irgendwo angezeigt wird, egal ob man ~E_DEPRECATED verwendet oder nicht - was mich allerdings ein wenig irritiert.

[Alphawolf]

Wie gesagt, du musstest es ja sowieso machen. Ohne den letzten Parameter erzeugt dir Contao URLs ohne die richtige Domain (relativ zur aktuellen). Das heißt, ohne den letzten Parameter musst du dich sowieso selbst darum kümmern, dass die richtige Domain in der URL vorhanden ist - ohne Contao Framework.[/php]

Soweit korrekt. Aber die Tatsache, dass ich bisher die Domain durch eigene Logik immer davor setzte, ergab sich ja daraus, dass ich bisher immer davon ausgehen konnte, dass generateFrontendUrl einen Link ohne Domain zurück gibt. D.h. egal welches Page Object ich an generateFrontendUrl übergab, die Methode gab mir eine relative URL und ich setzte die Domain manuell davor. Ohne Abfrage aufgrund des Wissens, dass ich immer eine relative URL zurück bekam.
Das kann ich jetzt nicht mehr, denn jetzt muss ich zusätzlich den zurückgegebenen URL String parsen, ob er bereits ein Scheme beinhaltet. Und das finde ich eine etwas befremdliche Entscheidung.

D.h. ich habe nach diesem Point Release die Wahl, den Parameter weiterhin nicht zu setzen und mit Deprecated Notices im Error Log zu leben, oder ich setze den Parameter und muss nach jedem Aufruf von generateFrontendUrl in meinem Modul einen zusätzlichen Layer an Parsing einbauen, da mir generateFrontendUrl plötzlich nach einem Point Release keinen erwartbaren Rückgabewert mehr zurückgibt (sprich, ob mit oder ohne Domain).

[Spooky]

Soweit korrekt. Aber die Tatsache, dass ich bisher die Domain durch eigene Logik immer davor setzte, ergab sich ja daraus, dass ich bisher immer davon ausgehen konnte, dass generateFrontendUrl einen Link ohne Domain zurück gibt. D.h. egal welches Page Object ich an generateFrontendUrl übergab, die Methode gab mir eine relative URL und ich setzte die Domain manuell davor. Ohne Abfrage aufgrund des Wissens, dass ich immer eine relative URL zurück bekam.
Das kann ich jetzt nicht mehr, denn jetzt muss ich zusätzlich den zurückgegebenen URL String parsen, ob er bereits ein Scheme beinhaltet. Und das finde ich eine etwas befremdliche Entscheidung..

Doch, du kannst das nach wie vor so machen, an der Funktion hat sich ja nichts geändert.

D.h. ich habe nach diesem Point Release die Wahl, den Parameter weiterhin nicht zu setzen und mit Deprecated Notices im Error Log zu leben

Nein, wie gerade erwähnt erscheinen Deprecated Notices by default nicht im Log oder sonst wo.

da mir generateFrontendUrl plötzlich nach einem Point Release keinen erwartbaren Rückgabewert mehr zurückgibt (sprich, ob mit oder ohne Domain).

Doch, die Funktion hat sich ja nicht geändert. Und selbst wenn du den 4. Parameter auf true setzt, hast du immer genau gewusst, was die Funktion zurückgibt.

[Spooky]

Der von \Controller::generateFrontendUrl generierte error ist übrigens E_USER_DEPRECATED, nicht E_DEPRECATED - daher wird der auch von der vorhin erwähnten default Einstellung für das error reporting nicht erfasst. Das spielt allerdings keine Rolle:

Darüberhinaus wird die Error Funktion so aufgerufen:

@trigger_error 

was zumindest in meiner Server Umgebung dazu führt, dass der Error nie irgendwo angezeigt wird, egal ob man ~E_DEPRECATED verwendet oder nicht - was mich allerdings ein wenig irritiert.

Das passiert übrigens, weil der Error Handler von Contao absichtlich errors mit dem @ error control operator ignoriert: https://github.com/contao/core/blob/...ctions.php#L43

Selbst wenn man also nicht ~E_USER_DEPRECATED verwendet, sollte die Deprecated Notice nirgendwo aufscheinen.

[css-umsetzung]

Die Default Einstellung von Contao ist übrigens

$GLOBALS['TL_CONFIG']['errorReporting'] = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED; 

https://github.com/contao/core/blob/...fault.php#L348

Darüberhinaus wird die Error Funktion so aufgerufen:

@trigger_error 

was zumindest in meiner Server Umgebung dazu führt, dass der Error nie irgendwo angezeigt wird, egal ob man ~E_DEPRECATED verwendet oder nicht - was mich allerdings ein wenig irritiert.

Wenn man sich seine triggerfunktion anschaut, sieht man, das ihn keine der Einstellungen interessieren, mein errorlog in system/logs ist nach 2 Stunden locker 20MB gross, vollgeknallt mit diesen deprecated Meldungen.

[Spooky]

Wenn man sich seine triggerfunktion anschaut, sieht man, das ihn keine der Einstellungen interessieren, mein errorlog in system/logs ist nach 2 Stunden locker 20MB gross, vollgeknallt mit diesen deprecated Meldungen.

Ich vermute hier einen Bug bei Contao - es wird nämlich im error handler

if (ini_get('error_reporting') > 0) 

abgefragt (https://github.com/contao/core/blob/...ctions.php#L43), statt

if (error_reporting() > 0) 

wie laut Dokumentation vorgesehen. Evt. wird dadurch nur die ini-Konfiguration zurückgegeben, nicht aber die aktuelle Runtime Konfiguration - und die ist bei dir evt. größer als 0. Zum testen kannst du bei deinem Server mal error_reporting auf 0 setzen (per php_value in der .htaccess oder im vhost, oder über eine PHP .ini bspw.).

[css-umsetzung]

wenn ich das machen würde wäre ruhe, aber das will ich ja nicht, ich bin Entwickler und
darauf angewiesen das ich es sehe wenn etwas nicht wie erwartet läuft.

[Spooky]

wenn ich das machen würde wäre ruhe, aber das will ich ja nicht, ich bin Entwickler und
darauf angewiesen das ich es sehe wenn etwas nicht wie erwartet läuft.

Für Contao ist das egal, das setzt sowieso eigene Werte für error_reporting. Hier geht es ja nur um den Test ob

ini_get('error_reporting') 

die Runtime Configuration zurück gibt, oder die Server Configuration.

[Babelfisch]

In Contao 5 fallen beide Parameter einfach weg und die Funktion verhält sich dann fix so, wie wenn man …, …, null, true in Contao >=3.3.0,<5-dev verwenden würde. Wenn du selbst also die Funktion jetzt schon so verwendest, dann musst du auch später für Contao 5 keine Kompatibilitätsanpassung machen.

Das stimmt aber nicht. Default ist $blnFixDomain=false und lässt man beide Parameter weg, wird die Deprecated notice geworfen, weil $blnFixDomain true sein muss. Wenn also wirklich beide Parameter in Contao 5 wegfallen, kann man gerade wegen der Deprecated notice momentan keinen zukunftsfähigen Code schreiben, weil man gezwungen ist, generateFrontendUrl(…, null, true) anzugeben. Da $blnFixDomain ja momentan von Contao genutzt wird und eine Funktion hat, darf meiner Meinung nach beim regulären Wert false keine Deprecated notice kommen. Außerdem sollte der Vorgabewert dann auch true sein, was aber zu einem anderen Verhalten führt.

Hier kann ich den Unmut von css-umsetzung durchaus verstehen. So eine Änderung mal eben in einem Minor-Update ohne Hinweis im Changelog ist IMHO Käse.

Gruß

[Spooky]

Das stimmt aber nicht.

Der von dir gequotete Post von mir stimmt so wie er ist. In Contao 5 fallen die letzten beidne Parameter weg und die Funktion verhält sich dann so, wie wenn in der Vergangenheit, als die Parameter noch existierten (relativ von Contao 5 in der Zukunft aus gesehen), …, …, null, true verwendet wurde.

Wenn also wirklich beide Parameter in Contao 5 wegfallen, kann man gerade wegen der Deprecated notice momentan keinen zukunftsfähigen Code schreiben, weil man gezwungen ist, generateFrontendUrl(…, null, true) anzugeben.

Du bist nicht dazu gezwungen. Du kannst alles so lassen wie es ist. Spätestens jedoch, wenn du deine Extension für Contao 5 kompatibel machen wilst, musst du darauf Rücksicht nehmen. So wie bei vielen anderen Dinge auch, die deprecated sind oder werden und dann in Contao 5 wegfallen. Hier hast du zB eine Liste an Dingen, die in Contao 4 bspw. deprecated sind und in Contao 5 wegfallen: https://docs.contao.org/books/contao...eprecated.html bzw. https://github.com/contao/core-bundl.../DEPRECATED.md

Da $blnFixDomain ja momentan von Contao genutzt wird und eine Funktion hat, darf meiner Meinung nach beim regulären Wert false keine Deprecated notice kommen.

Doch, die Deprecated Notice wurde eingebaut, weil diese Parameter in Contao 5 wegfallen und sich die Funktion dann so verhält, als hätte man sie mit …, …, null true eingesetzt.

Außerdem sollte der Vorgabewert dann auch true sein, was aber zu einem anderen Verhalten führt.

Nein, das wäre ein Backwards Compatibility break. Hätte man den default Wert auf true gesetzt, würden einige Extensions nicht mehr funktionieren (inkl. der Extensions von css-umsetzung und Alphawolf bspw.). In Contao 3.5.7 war das zB kurzfristig so, daher hat man gleich danach Contao 3.5.8 nachgereicht, wo das wieder rückgängig gemacht wurde. Die Funktion

\Controller::generateFrontendUrl 

funktioniert nach wie vor genau so wie immer (bzw. so, wie sie seit Contao 3.3.0 erweitert wurde).

Hier kann ich den Unmut von css-umsetzung durchaus verstehen. So eine Änderung mal eben in einem Minor-Update ohne Hinweis im Changelog ist IMHO Käse.

Es hat sich an der Funktion nichts geändert. Es wurde nur eine Deprecated Notice hinzugefügt, was völlig normal ist. Der Unmut von css-umsetzung kommt ja nur dadurch zustande, weil sein error.log und/oder Frontend aus irgendeinem Grund mit Deprecated Notices gespammed wird, was aber eigentlich gar nicht sein sollte.

[css-umsetzung]

naja ich hab da von megabyteweise auf meinem Server und finde es wirklich nicht lustig.

[Spooky]

Jo, kann ich mir vorstellen, dass das nicht lustig ist . Temporär kannst du den trigger_error Aufruf ja einstweilen entfernen. Leo Feyer hat das Ticket dazu ja schon als Bug gekennzeichnet. Ich selbst hab' jedoch noch nicht herausfinden können, wie es dazu kommen könnte. Du selbst hast aber auch beim Debugging noch nicht mitgeholfen.

[Babelfisch]

Der von dir gequotete Post von mir stimmt so wie er ist. In Contao 5 fallen die letzten beidne Parameter weg und die Funktion verhält sich dann so, wie wenn in der Vergangenheit, als die Parameter noch existierten (relativ von Contao 5 in der Zukunft aus gesehen), …, …, null, true verwendet wurde.

Nein, eben nicht. Du schreibst:

Wenn du selbst also die Funktion jetzt schon so verwendest, dann musst du auch später für Contao 5 keine Kompatibilitätsanpassung machen.

Man kann die Funktion aber jetzt nocht nicht so wie in Contao 5 – also nur mit zwei Parametern – nutzen, da es dann zu einer Deprecated Notice kommt. Man muss jetzt explizit …, …, null, true angeben.

Nein, das wäre ein Backwards Compatibility break. Hätte man den default Wert auf true gesetzt, würden einige Extensions nicht mehr funktionieren (inkl. der Extensions von css-umsetzung und Alphawolf bspw.). In Contao 3.5.7 war das zB kurzfristig so, daher hat man gleich danach Contao 3.5.8 nachgereicht, wo das wieder rückgängig gemacht wurde. Die Funktion

\Controller::generateFrontendUrl 

funktioniert nach wie vor genau so wie immer (bzw. so, wie sie seit Contao 3.3.0 erweitert wurde).

Ich weiß und deshalb schrieb ich ja auch „…, was aber zu einem anderen Verhalten führt.“.

Es hat sich an der Funktion nichts geändert. Es wurde nur eine Deprecated Notice hinzugefügt, was völlig normal ist. Der Unmut von css-umsetzung kommt ja nur dadurch zustande, weil sein error.log und/oder Frontend aus irgendeinem Grund mit Deprecated Notices gespammed wird, was aber eigentlich gar nicht sein sollte.

Natürlich sollte das nicht sein aber wenn man Erweiterungen nutzt, die kein $blnFixDomain gesetzt haben, dann kommen halt die Warnungen und bei Inhaltselementen kann das dann schon mal eine lange Liste werden.

Als Entwickler bin ich der Meinung, dass solche Änderungen eben nicht in eine Minor-Release gehören. Das sind für mich reine Bugfix-Releases, die für den Entwickler eigentlich keine Änderungen am Code nach sich ziehen sollten. Warum machen wir denn ansonsten überhaupt die Unterscheidungen?

Gruß

[Spooky]

Nein, eben nicht.

Doch:

Man kann die Funktion aber jetzt nocht nicht so wie in Contao 5 – also nur mit zwei Parametern – nutzen, da es dann zu einer Deprecated Notice kommt. Man muss jetzt explizit …, …, null, true angeben.

Sicher kann man das. Du musst nicht explizit …, …, null, true angeben.

Natürlich sollte das nicht sein aber wenn man Erweiterungen nutzt, die kein $blnFixDomain gesetzt haben, dann kommen halt die Warnungen und bei Inhaltselementen kann das dann schon mal eine lange Liste werden.

Nein, es kommen keine Warnungen. Es kommen auch keine Deprecated Notices ins Frontend oder in das error.log. Falls doch, liegt irgendwo ein Fehler vor und dieser Fehler wurde von css-umsetzung auch schon auf GitHub gemeldet. Siehe die vorherigen Posts in diesem Thread. Falls das auch bei dir so ist, kannst du ja mit Helfen die Ursache für diesen Fehler aufzuspüren.

Als Entwickler bin ich der Meinung, dass solche Änderungen eben nicht in eine Minor-Release gehören.

Es wurde nichts geändert. Wie schon mehrmals in diesem Thread erwähnt: die Funktionalität ist noch genau so, wie sie in Contao 3.3.0 schon existiert.

[Babelfisch]

Sicher kann man das. Du musst nicht explizit …, …, null, true angeben.

Ach menno, schau doch mal bitte in den Contao Quellcode:

https://github.com/contao/core/blob/...ller.php#L1082

public static function generateFrontendUrl(array $arrRow, $strParams=null, $strForceLang=null, $blnFixDomain=false)
{
…
if ($blnFixDomain !== true)
{
  @trigger_error('Using Controller::generateFrontendUrl() without $blnFixDomain has been deprecated and will no longer work in Contao 5.0.', E_USER_DEPRECATED);
} 

$blnFixDomain wird standardmäßig auf false gesetzt und später wird die Deprecated Notices geworfen, wenn $blnFixDomain ungleich true ist. Gebe ich die Parameter also nicht an, gibts ’ne Deprecated Notices und das ist murks.

Gruß

[Spooky]

Das ist nicht "murks", Deprecated Notices sind völlig normal. Außerdem scheint diese Deprecated Notice nirgendwo auf. Sieh dir den Code selbst an den du gepostet hast:

@trigger_error 

[Babelfisch]

Das ist nicht "murks", Deprecated Notices sind völlig normal. Außerdem scheint diese Deprecated Notice nirgendwo auf. Sieh dir den Code selbst an den du gepostet hast:

@trigger_error 

Was taucht hier nur bei mir auf? Ich habe den Thread nicht angefangen und schon im ersten Posting von css-umsetzung ging es um diese Deprecated Notice. Und natürlich taucht die im Frontend auf, wenn man in den Contao-Einstellungen Fehlermeldungen anzeigen aktiviert hat. Als Entwickler habe ich das natürlich aktiviert und muss ab Contao 3.5.8 alle generateFrontendUrl-Aufrufe um …, null, true ergänzen, da das »Feature« der Deprecated Notice eben genau in diese Version hinzugefügt wurde. Vorher gab es die Warnung nicht.

Gruß

[Spooky]

Und natürlich taucht die im Frontend auf, wenn man in den Contao-Einstellungen Fehlermeldungen anzeigen aktiviert hat.

Nein, tut sie by default nicht. Und wenn sie das doch tut, liegt, wie schon erwähnt (lies bitte den Thread), ein Fehler vor.

Dafür, dass du dich als Entwickler bezeichnest, musst man dir ziemlich viel vorkauen. Wie bereits erwähnt wird folgender Code benutzt:

@trigger_error 

Das '@' ist ein sogenannter error control operator von PHP:

When prepended to an expression in PHP, any error messages that might be generated by that expression will be ignored.

In diesem Fall wird der error control operator bei einer Funktion benutzt, mit der man selbst eine error message erzeugen kann. Der Code

@trigger_error('…', …); 

dient also einfach nur als interner Hinweis für Entwickler, der nirgends ausgegeben wird. Contao macht das an mehreren Stellen (die GitHub Suche ignoriert leider das @).

Aber, wie du schon selbst bemerkt hast, und wie es schon diesem Thread erwähnt wurde, wird diese Meldung aus irgendeinem Grund dennoch ausgegeben. Vermutlich liegt hier irgendwo ein Fehler im Bezug auf den error handler von Contao vor, denn:

If you have set a custom error handler function with set_error_handler() then it will still get called, but this custom error handler can (and should) call error_reporting() which will return 0 when the call that triggered the error was preceded by an @.

Das heißt, wenn du einen eigenen error handler benutzt, wird der error handler auch bei errors von Funktionen aufgerufen, die eigentlich mit '@' versehen. Der error_reporting level wird dabei von PHP aber zur Laufzeit auf '0' gesetzt - daher muss man, wie beschreiben, im error handler das error_reporting level selbst noch mal überprüfen. Das macht der error handler von Contao auch, allerdings mit

ini_get('error_reporting') 

statt mit

error_reporting() 

Wie bereits auf GitHub und hier im Thread beschrieben war meine ursprüngliche Vermutung, dass dies das Problem ist. Lokal konnte ich den Verdacht bei meinem Webserver aber nicht bestätigen. Beide Funktionen geben bei mir '0' zurück, auch wenn das im Server konfigurierte error_reporting level größer '0' ist.

Wenn du willst, dass dieser Fehler behoben wird, wäre es nicht schlecht, wenn du dich daran beteiligst die Ursache zu finden.

[Babelfisch]

Du kommst mir jetzt ernsthaft mit der Erklärung vom @-Zeichen in PHP? Das ist böse!

Warum wird die Meldung ausgegeben? Weil:

1. in der default.php $GLOBALS['TL_CONFIG']['errorReporting'] = 'E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED' gesetzt wird
2. in der initialize.php display_errors=1 und error_reporting auf obigen Wert gesetzt wird, wenn in den Einstellungen displayErrors aktiviert ist
3. Contao den eigenen Error-Handler __error() aus functions.php anmeldet
4. und dort dann die Deprecated notice von trigger_error landet und mich einem ordinären echo ausgegeben wird, unabhängig davon, ob die Fehlerausgabe mit dem @-Zeichen unterdrückt wurde

Änderungen von Contao an diesen Stellen kann ich keine in letzter Zeit finden, so dass ich davon ausgehe, dass das Verhalten sich schon länger so ist. Ich sehe darin auch keinen Fehler.

Gruß

[Spooky]

Du kommst mir jetzt ernsthaft mit der Erklärung vom @-Zeichen in PHP? Das ist böse!

Warum ist das böse?

Warum wird die Meldung ausgegeben? Weil:

1. in der default.php $GLOBALS['TL_CONFIG']['errorReporting'] = 'E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED' gesetzt wird
2. in der initialize.php display_errors=1 und error_reporting auf obigen Wert gesetzt wird, wenn in den Einstellungen displayErrors aktiviert ist
3. Contao den eigenen Error-Handler __error() aus functions.php anmeldet
4. und dort dann die Deprecated notice von trigger_error landet und mich einem ordinären echo ausgegeben wird, unabhängig davon, ob die Fehlerausgabe mit dem @-Zeichen unterdrückt wurde

Nein, Punkt 1.) und Punkt 2.) spielt für Fehlermeldungen, die mit '@' unterdrückt werden keine Rolle. Egal was du im Server oder in Contao für ein error_reporting Level setzt, '@' unterdrückt diese Meldung.

Punkt 3.) und 4.) hingegen spielt wie bereits im vorigen Post beschrieben eine Rolle. Aber:

und dort dann die Deprecated notice von trigger_error landet und mich einem ordinären echo ausgegeben wird, unabhängig davon, ob die Fehlerausgabe mit dem @-Zeichen unterdrückt wurde

Lies dir dazu einfach den Post von mir durch:

If you have set a custom error handler function with set_error_handler() then it will still get called, but this custom error handler can (and should) call error_reporting() which will return 0 when the call that triggered the error was preceded by an @.

Das heißt, wenn du einen eigenen error handler benutzt, wird der error handler auch bei errors von Funktionen aufgerufen, die eigentlich mit '@' versehen. Der error_reporting level wird dabei von PHP aber zur Laufzeit auf '0' gesetzt - daher muss man, wie beschreiben, im error handler das error_reporting level selbst noch mal überprüfen. Das macht der error handler von Contao auch, allerdings mit

ini_get('error_reporting') 

statt mit

error_reporting() 

Wie bereits auf GitHub und hier im Thread beschrieben war meine ursprüngliche Vermutung, dass dies das Problem ist. Lokal konnte ich den Verdacht bei meinem Webserver aber nicht bestätigen. Beide Funktionen geben bei mir '0' zurück, auch wenn das im Server konfigurierte error_reporting level größer '0' ist.

Wenn du willst, dass dieser Fehler behoben wird, wäre es nicht schlecht, wenn du dich daran beteiligst die Ursache zu finden.

https://community.contao.org/de/show...l=1#post402344