Fehler nach Update auf 1.7

[Timbalu]

^ E_STRICT unterbindet den Fehler bei mir.
Außerdem tritt er wahrscheinlich auch am ehesten auf, wenn man auf event Plugins installieren geht. Vorher werden, jedenfalls auf frischen Installationen, die vorliegenden, aber noch nicht aktivierten Plugins nicht abgefragt.

Edit:
Achtung: Das testen mit +/- von "^ E_STRICT", geht immer nur bei ersten Mal und wird sonst über längere Zeit irgendwo hartnäckig gecached. Um das Verhalten reproduzierbar zu machen, muss man zwischendurch immer mal an anderen Dingen etwas ändern, damit die set_error_handler Direktive in PHP wieder neu greift.

[MarioH]

Vorher werden, jedenfalls auf frischen Installationen, die vorliegenden, aber noch nicht aktivierten Plugins nicht abgefragt.

Ja, war bei meinem lokalen Testblog auch so. In dem Moment, in dem ich das Plugin aktiviert habe, kam sofort die Fehlermeldung.

Gruß
Mario

[garvinhicking]

Hi!

Öh, gecacht werden dürfte da eigentlich nix?!

Ich hab jetzt in MASTER einen fix committed: https://github.com/s9y/Serendipity/comm ... nt-2465634

Würde mich freuen wenn Du, Mario, mal den aktuellen git master ausprobieren kannst, und Ian auch? Aus meiner Sicht könnte man dann diesen rc2 hoffentlich dann auch sinnvoll nutzen, selbst wenn man "böse" Plugins installiert hat.

Grüße,
Garvin

[MarioH]

Hallo.

Die rc2 läuft jetzt mit PHP 5.2 und 5.4 mit dem serendipity_browsercompatibility ohne den Fehler zu produzieren.

Gruß
Mario

[Timbalu]

Garvin, das muss ein PHP interner cache bis zum nächsten change sein... (compile!=laufzeit)

Ok, die pre-RC2 läuft nun ohne diesen exception error aufgrund alter Plugin Inkompatibilitäten wg fehlender Signatures. Mein Test zeigt jetzt aber diesen signature Fehler gar nicht mehr an, auch wenn ich debug manuell setze (siehe commit note). Damit kann ich aber nicht sehen ob jetzt überhaupt noch Fehler gemeldet werden, wie wir es aber doch eigentlich wünschen...

Die andere Sache ist, dass jetzt ein bereits installiertes serendipity_event_browsercompatibility Plugin einfach so weiterläuft. Auch das ist nicht in unserem Sinne. Vielleicht sollten wir mein Vorschlag mit dem $serendipity['deprecated_plugins'] Abgleich doch noch einbauen...!?

[garvinhicking]

Garvin, das muss ein PHP interner cache bis zum nächsten change sein... (compile!=laufzeit)

So etwas gibt es maximal mit externen Tools wie APC o.ä., hast Du das laufen? Natives normales PHP kennt keinen Cache.

Ich habe den Patch gerade für 5.4 nochmal angepasst damit im "debug" mode die Fehler wieder erscheinen, das hattest Du gut entdeckt, danke.

Die andere Sache ist, dass jetzt ein bereits installiertes serendipity_event_browsercompatibility Plugin einfach so weiterläuft. Auch das ist nicht in unserem Sinne. Vielleicht sollten wir mein Vorschlag mit dem $serendipity['deprecated_plugins'] Abgleich doch noch einbauen...!?

Naja, das Plugin macht ja nix total böses. Es kostet ja durchaus performance bei jedem plugin aufruf immer diese deprecated plugins sache durchzugucken. Ich finde wir sind noch nicht so weit dass wir plugins echt "verbieten" müssen; evtl gibts ja leute die halt dieses IE6 PNG Fix noch haben wollen

Wenn das mit dem error reporting klappt müssten wir das irgendwie auch in die 2.0 noch importieren. Ich hoffe ich finde da die Zeit zu und vergess es nicht

Grüße,
Garvin

[Timbalu]

Ich hatte auch gerade eine ähnliche, aber etwas mehr ausführliche Lösung gepostet.

Das mit dem browsercompat plugin sollte man aber mindestens in den NEWS als deinstalliert und wenn möglich auch als zu deinstallieren erwähnen; ebenso im RC Blog post.

Bei der "Cache" Sache habe ich wahrscheinlich folgendes Phänomen wahrgenommen.

Der Großteil der E_STRICT Fehler werden zur Compile-Zeit generiert und werden somit nicht angezeigt, wenn E_STRICT zur Laufzeit zu error_reporting hinzugefügt wird (und auch andersrum).

Edit:
Ich hätte gerne noch vor der offiziellen RC-2 gelöst, dass production = debug nicht auch das smarty debug auslöst. Ich finde das sind zwei verschiedene Stiefel!

Hmmm, nochmal kurz nachgedacht:
Das RC für non-devs würde dann aber doch jetzt bedeuten, dass die Fehler, die wir jetzt eigentlich doch suchen, gar nicht mehr angezeigt werden. Oder??? zb "Only variables should be assigned by reference" oder andere...

[garvinhicking]

Hi!

Ich bin mir nicht sicher ob man das wirklich so explizit eräwhnen muss im Blogpost; finde das bläht sonst zu sehr auf.

Ich hatte auch gerade eine ähnliche, aber etwas mehr ausführliche Lösung gepostet.

Das mit dem browsercompat plugin sollte man aber mindestens in den NEWS als deinstalliert und wenn möglich auch als zu deinstallieren erwähnen; ebenso im RC Blog post.

In docs/NEWS steht die Entfernung davon übrigens schon zu Version 1.6, das ist also gar kein "1.7" feature. Dennoch habe ich in der upgrade-Notice zu rc2 mal den entsprechenden Hinweis aufgenommen, danke.

Das mit dem Debug, das ist ja sowieso nur für devs. Das direkt mit smarty debug zu verbinden finde ich eigentlich gut. Was genau stört? Ich fände es doof noch einen weiteren debug-mode einzufügen, das wird dann alles etwas zu viel des Guten, oder nicht?

Das RC für non-devs würde dann aber doch jetzt bedeuten, dass die Fehler, die wir jetzt eigentlich doch suchen, gar nicht mehr angezeigt werden. Oder??? zb "Only variables should be assigned by reference" oder andere...

Korrekt, das finden wir nur als Devs raus mit debug, oder wenn irgendwo etwas nicht funktioniert und wir die leute dann bitten debug mode zu aktivieren. Es ist normalen Testern von RCs IMO nicht zuzumuten, deren Installationen quasi kaputt zu machen nur weil ein E_STRICT nicht eingehalten wird; das ist IMO nicht Aufgabe von öffentlichen Tests. Dadurch verschreckt man potentielle Tester nur, bzw. frustriert sie, wenn sie die version auf ihrem blog einsetzen und wegen solcher lappalien alles dann vollständig aufhört zu arbeiten.

Grüße,
Garvin

[Timbalu]

Ja, das waren meine Besorgnisse ja auch schon gewesen...
http://board.s9y.org/viewtopic.php?f=15 ... #p10433376

Allerdings wozu benötigen wir dann eine RC? Die offensichtlichen Smarty Konvertierungsfehler sollten nach fast zwei Jahren alle weg sein und nur noch soetwas wie jetzt mit dem entry.author auftreten. Aber das ist schon sehr speziell und ist ja im Eigentlichen auch kein Fehler, sondern nur ein geändertes Verhalten. Smarty3 ist da halt wesentlich genauer! Ich finde das gut, auch wenn es uns zwingt, das eine oder andere anders zu schreiben!
Bei den nun unterdrückten PHP Fehlern, falls nicht im debug Modus, habe ich einfach Sorge, dass wesentliche Dinge nicht mehr funktionieren bzw für immer erhalten bleiben..., oder wären das nur zu vernachlässigende Notes (so wie die "only variables should be assigned by reference"?

Schade, ich hatte schon mit dem Gedanken gespielt einen ~"debug++" mode einzufügen, der dann letztendlich das $this->debugging auf true setzt... Irgendwie stört mich das popup doch sehr wenn ich eigentlich auf PHP error Jagd bin.... Da schaltet man debug doch möglichst gar nicht erst länger ein...