it-swarm.com.de

So beheben Sie die Warnung "Strenge Standards" für verschiedene Methodensignaturen in allen Joomla-Versionen

Bei der Aktualisierung einer Erweiterung zur Unterstützung von Joomla 3.x sind einige Fälle aufgetreten, in denen sich die Signatur für eine Funktion seit 2.5 geändert hat und eine Strict standards - Warnung ausgegeben wurde.

In der JTable-Klasse hatte sich beispielsweise die _getAssetParentId() geändert

protected function _getAssetParentId($table = null, $id = null)
{
    ...
}

dazu in Joomla 3.x:

protected function _getAssetParentId(JTable $table = null, $id = null)
{
    ...
}

Es ist ein kleiner Unterschied, aber es reicht aus, um die Warnung auszusprechen.

Wenn sie sich andere Erweiterungen ansehen, die Joomla 2.5 und 3.0 mit einer einzelnen Klassendatei unterstützen, scheinen sie das Problem einfach zu ignorieren.

Wenn wir die Warnung für 3.x korrigieren, wird 2.5 natürlich mit throw the warning installiert.

"Lösungen", die für uns keine Option sind, umfassen:

  • verwenden von zwei separaten versionsspezifischen Klassendateien
  • warnungen ausschalten

Wie lösen Sie diesen Konflikt?

7
Craig

Bei der Arbeit versuchen wir, alle PHP Warnungen, Fehler und Verstöße gegen strenge Standards zu beheben. In Situationen wie diesen, in denen die Signaturen unterschiedlich sind, gibt es keine Möglichkeit, sie mit zwei separaten, versionsspezifischen Klassen aufzulösen Ich bin allerdings neugierig, warum das für Sie keine Option ist.

Versionsspezifische Klassendateien sind eigentlich einfach zu implementieren, aber etwas schwieriger zu warten, da Sie Code an mehreren Stellen aktualisieren. Das Beste, was Sie in dieser Situation tun können, ist ein root src/ Ordner, der alle Ihre Komponentenklassen für das automatische Laden enthält, und anschließend alle versionsspezifischen 2.5- oder 3.x-Klassen in einem overrides/$VERSION Mappe. Anschließend können Sie den Autoloader so einrichten, dass er an den entsprechenden Stellen in der entsprechenden Reihenfolge sucht, basierend auf der aktuellen Version.

Ich wünschte wirklich, es gäbe einen einfacheren Weg, aber PHP erlaubt keine dynamische Methodenüberladung, bei der die Signaturen übereinstimmen können.

9
Don Gilbert

Meines Wissens können Sie diese strenge Warnung nicht lösen. Weil die Signaturen in 2.5 oder 3.x immer unterschiedlich sind.

Korrigieren Sie es entweder für 3.x und ignorieren Sie es in 2.5 oder umgekehrt.

In einer produktiven Umgebung sollten Sie diese Warnung sowieso nie sehen, da Sie nur strenge Warnungen in den Entwicklungseinstellungen anzeigen sollten.

4
Bakual

Es gibt ein großes Problem mit dem Status von PHP, einige Server verwenden noch 5.2, während andere bei 5.3 oder 5.4 sicher bleiben. Es gibt auch einige, die bei 5.5 aktuell bleiben.

Dies führt zu einem großen Problem bei der "Unterstützung". Wenn Sie sich für die verschiedenen Versionen entscheiden, würde ich sagen, dass 5.2 die am häufigsten verwendete, aber unsichere Version ist. 5.3 und 5.4 sind das, wonach Joomla in 3 sucht. Wenn ein Benutzer jedoch in 5.5 ist, können die strengen Standardwarnungen von den anderen Versionen abweichen.

Obwohl PHP geht bei den Fehlern nicht über den Tellerrand, da es immer noch "funktioniert" seine Warnung, dass es nicht so ist, wie die aktuelle Version damit umgehen soll, sondern immer noch Bei den meisten Entwicklern können die Warnungen von Notice und Strict Standards daher weitgehend ignoriert werden, da Sie, wenn Sie eine Fehlerbehebung vornehmen, eine andere in einer anderen PHP Version auslösen können.

Für einen OCD-Entwickler ist es am besten, alle zu entfernen. Offensichtliche Fehler sollten behoben werden, aber solche, wie Sie sie beschreiben, würden dazu führen, dass Joomla auf eine PHP Version zu viel fokussiert wird, was zu viel mehr Arbeit für ein Upgrade seiner PHP führt Version auch.

Das einzig wahre Problem ist, in Joomlas "Bootstrap" auf die PHP) - Version zu testen und darauf basierende Dateien zu laden. Dies könnte dazu führen, dass sich die Größe der Joomla-Basisinstallation verdoppelt und es auch noch so ist Dann sollte mehr Arbeit für Fehler geleistet werden, die eigentlich keine Site beschädigen. Don Gilberts Antwort geht darauf noch genauer ein.

Meine Antwort ist seltsam, aber ich denke, sie kann anderen helfen, das Chaos zu verstehen, das PHP ist.

1
Jordan Ramstad