Osticket: Warnungen zu Deklarationsformularen und TransferFormularen in PHP 7

Erstellt am 13. Apr. 2016  ·  30Kommentare  ·  Quelle: osTicket/osTicket

Die Verwendung der neuesten Entwicklungsversion unter PHP 7 führt zu folgenden Warnungen:
Warnung: Die ZuweisungsdeklarationForm::render($options) sollte mit Form::render($staff = true, $title = false, $options = Array) in /opt/osticket/osTicket-develop/include/class kompatibel sein. form.php auf Zeile 4144

Warnung: Die Deklaration von TransferForm::render($options) sollte mit Form::render($staff = true, $title = false, $options = Array) in /opt/osticket/osTicket-develop/include/class kompatibel sein. form.php auf Zeile 4264

Diese Warnungen beeinträchtigen die Popup-Dialogfelder und verwerfen den Abstand auf den Vorlagen

Der beigefügte Patch-Diff behebt diese Warnungen

class.forms.php.zip

bug php

Hilfreichster Kommentar

Ich habe dieses Problem auch bei der aktuellen stabilen Version von osTicket 1.10. Es verhindert, dass die Dialogfelder Übertragen und Zuweisen etwas anderes als ein weißes Quadrat darstellen, und verhindert auch, dass api/cron.php E-Mails überprüft. Wenn ich cron.php ausführe, gibt es diese Fehlermeldungen:

PHP Warning:  Declaration of AssignmentForm::render($options) should be compatible with Form::render($staff = true, $title = false, $options = Array) in /var/www/helpdesk/include/class.forms.php on line 4150
PHP Warning:  Declaration of TransferForm::render($options) should be compatible with Form::render($staff = true, $title = false, $options = Array) in /var/www/helpdesk/include/class.forms.php on line 4270

Hier sind die Serverinformationen aus dem Admin-Panel:

osTicket Version     v1.10 (901e5ea) —  Up to date
Web Server Software  Apache/2.4.18 (Ubuntu)
MySQL Version        5.7.17
PHP Version          7.0.15-0ubuntu0.16.04.4

Der Server läuft mit Ubuntu 16.04.2 LTS und ist vollständig aktualisiert.

Die im Pull-Request #3349 vorgestellten Modifikationen haben das Problem für mich gelöst.

Alle 30 Kommentare

Gibt es einen Grund, warum Sie die Änderungen nicht in einen Pull-Request aufnehmen würden?

Entschuldigung, ich habe kein Git-Repo, ich habe die Datei gerade auf meinem Linux-System mit vi bearbeitet.


Von: ntozier [email protected]
Gesendet: Mittwoch, 13. April 2016 10:52
An: osTicket/osTicket
Cc: Bill Ritchie
Betreff: Betreff: [osTicket/osTicket] Warnungen zu Abtretungserklärung und TransferForm in PHP 7 (#3033)

Gibt es einen Grund, warum Sie die Änderungen nicht in einen Pull-Request aufnehmen würden?

Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/osTicket/osTicket/issues/3033#issuecomment -209487139

Sie sagen, ein Bild sagt mehr als 1000 Worte.

capture

Bei der Verwendung von osTicket 1.10 RC3 mit PHP7 ist mir das gleiche aufgefallen.
Freue mich auf den Fix in einer neueren Version.

Siehe #3349 für eine andere Lösung

Diese Warnung tritt immer noch in der stabilen Version v1.10 auf: http://osticket.com/forum/discussion/89095/v1-10-php-7-warning

heute erneut bestätigt: auf meiner 1.10-Testseite mit IIS 8.5 und neu aktualisiertem PHP 7.0.14.

Gleiches Problem bei PHP 7.1, daher muss ich auf eine nicht PHP 7-Version downgraden, da OsTicket Probleme hat. Aòso kann sich nicht im Admin-Operator-Bereich einloggen Nachricht: Token CSRF valido richiesto

Dieses Problem besteht weiterhin in der stabilen Version 1.10. Der von @martin-rueegg erwähnte Fix hat geholfen.

Ich habe dieses Problem auch bei der aktuellen stabilen Version von osTicket 1.10. Es verhindert, dass die Dialogfelder Übertragen und Zuweisen etwas anderes als ein weißes Quadrat darstellen, und verhindert auch, dass api/cron.php E-Mails überprüft. Wenn ich cron.php ausführe, gibt es diese Fehlermeldungen:

PHP Warning:  Declaration of AssignmentForm::render($options) should be compatible with Form::render($staff = true, $title = false, $options = Array) in /var/www/helpdesk/include/class.forms.php on line 4150
PHP Warning:  Declaration of TransferForm::render($options) should be compatible with Form::render($staff = true, $title = false, $options = Array) in /var/www/helpdesk/include/class.forms.php on line 4270

Hier sind die Serverinformationen aus dem Admin-Panel:

osTicket Version     v1.10 (901e5ea) —  Up to date
Web Server Software  Apache/2.4.18 (Ubuntu)
MySQL Version        5.7.17
PHP Version          7.0.15-0ubuntu0.16.04.4

Der Server läuft mit Ubuntu 16.04.2 LTS und ist vollständig aktualisiert.

Die im Pull-Request #3349 vorgestellten Modifikationen haben das Problem für mich gelöst.

@peterson-dane Können Sie Ihre Lösung teilen?

Ich habe das gleiche Problem mit fast der gleichen Konfiguration wie Sie.

@PrajapatiChirag Ändern Sie in der Datei include/class.forms.php :
function render($options) {
zu
function render($staff = true, $title = false, $options = Array()) {

Es sollte drei Vorkommen geben.

@solsticesurfer , Danke, mein Problem wurde auch unter Debian Stretch (9.2) behoben.

Was passiert hier ? Ich habe diesen Fehler auch, aber die ersten Kommentare dazu sind 1 1/2 Jahre alt?

osTicket-Core, v1.10.1
Neueste stabile Version, veröffentlicht am 14. September 2017

Das habe ich installiert. Wie ist es möglich, dass Fehler nach 1 1/2 Jahr nicht behoben werden? Vor allem, weil die Lösung einfach ist und jemand anders den Fix hier schon geschrieben hat...

Wie Sie sagten: "Neueste stabile Version, veröffentlicht am 14. September 2017"

"Fix" gepostet auf:
2017oct03

Danke, dass du es so gemacht hast, dass ich diesen Thread nicht verlassen musste, um die Frage zu beantworten.

@ntozier

Dieser Fix wurde bereits 2016 gepostet. Erste Kommentare von vor 1 1/2 Jahren zu diesem Fehler. Ich habe einen Fix gefunden, der im September 2016 auf https://github.com/osTicket/osTicket/pull/3349/commits/bde15e2acec29a26c73918ae17aa0774fb5048c4 geschrieben wurde

"Neueste stabile Version, veröffentlicht am 14. September 2017"

1 1/2 Jahr nachdem der Fehler gefunden wurde und 1 Jahr nachdem eine Lösung gepostet wurde, enthält das "Stable Release" den Fehler immer noch.

Und es ist kein Fehler, der schwer zu finden ist. osTicket auf PHP 7 (der heutige Standard) funktioniert ohne diesen Fix einfach nicht.

Vielleicht wäre es besser gewesen, den Thread zu verlassen, um die Frage zu beantworten.

Einfach gesagt, es gab keine neue Version. 1.10 damals, 1.10.1 (Sicherheitsupdate) jetzt. 1.11 wurde noch nicht veröffentlicht.

Es gibt keine Garantie, dass der Fix in diesem Thread verwendet wird, wenn 1.11 herauskommt, und es ist unwahrscheinlich, dass dies der Fall ist, da es allein in diesem Thread mehrere Fixes gibt und er noch nicht zusammengeführt wurde.

@ntozier

Mit jeder Antwort von dir mache ich mir mehr Sorgen. Und hier geht es auch um Haltung.

PHP 7 ist mittlerweile der Standard.

Es gibt einen Bug, der vor 1 1/2 Jahren zum ersten Mal gesehen wurde. Es verhindert, dass os Ticket mit PHP 7 funktioniert.

Und nach 1 1/2 Jahren ist es immer noch nicht behoben ???

Deshalb habe ich in meinem ersten Post gefragt "Was passiert hier?"

Ist es in Ordnung, jetzt Zeit zu investieren, um dieses Programm zu installieren, es in Betrieb zu nehmen usw.? Ist es in Ordnung, Kunden zu beraten, dies zu verwenden?

PHP 7 ist mittlerweile der Standard.

Diese Aussage ist völlig subjektiv. Leute, die ich kenne, bevorzugen immer noch PHP 5.6 gegenüber PHP 7...

Es gibt einen Bug, der vor 1 1/2 Jahren zum ersten Mal gesehen wurde. Es verhindert, dass os Ticket mit PHP 7 funktioniert.

Es hindert osTicket nicht daran, für _jeder_ zu funktionieren, da ich Leute kenne, die es mit PHP 7 in ihrer Produktionsumgebung gut laufen lassen.

Und nach 1 1/2 Jahren ist es immer noch nicht behoben ???

Wie @ntozier sagte, gibt es in diesem Thread mehrere Fixes für dieses Problem und es braucht Zeit, sie durchzusehen und die beste zu finden, die nichts anderes kaputt macht und sicherzustellen, dass sie zu unserem Codierungsstil passt. Außerdem ist dies nicht das einzige Problem hier auf unserer Github-Seite ... es gibt 1.177. Muss sie alle durchsehen.

Ist es in Ordnung, jetzt Zeit zu investieren, um dieses Programm zu installieren, es in Betrieb zu nehmen usw.? Ist es in Ordnung, Kunden zu beraten, dies zu verwenden?

Natürlich ist es in Ordnung! Wenn Sie sich solche Sorgen machen oder Ihr kompiliertes PHP 7 nicht mit v1.10.1 umgehen kann, dann stufen Sie einfach auf PHP 5.6 herunter, bis es vollständig kompatibel ist. 👍

@JediKev

Leute, die ich kenne, bevorzugen immer noch PHP 5.6 gegenüber PHP 7...

Ich kenne auch Leute, die reiten. Der Support für PHP 5.6 wurde im Januar beendet, Sicherheitsupdates werden nächstes Jahr eingestellt.

Ich habe die Patches angewendet, jetzt scheint alles zu funktionieren. Aber es macht mir Sorgen :)

Sie sollten sich keine Sorgen machen. Die Dinge werden wirklich besser. Die letzten zwei Jahre waren für osticket-Benutzer (und ich denke besonders für die osticket-Leute) nicht einfach. Einer der Hauptentwickler (greezybacon, ein sehr freundlicher, immer hilfsbereiter und geschickter Programmierer!) hatte das Projekt verlassen und es dauerte einige Zeit, neue Entwickler zu finden, die das Projekt gut unterstützen und die große Lücke füllen konnten, die er hinterlassen hatte. Dies hatte die Entwicklung für einige Zeit gebremst. Aber man sieht auf github, wenn man das große Ganze betrachtet, dass die Entwicklungsgeschwindigkeit wächst. Und es kommen große Änderungen (zB komplette Überarbeitung der API, benutzerdefinierte Warteschlangen->als Alpha verfügbar).

Auch neue geschickte Community-Mitglieder wie clonemeagain https://github.com/clonemeagain oder Micke1101 https://github.com/Micke1101 haben mit ihren Plugins viele coole Sachen für die Community beigetragen. Sie helfen auch vielen Usern im Forum mit ihrem guten Wissen. ntozier, der Moderator des Forums, hat in all den Jahren so vielen Menschen geholfen (und hilft). Aber die Menschen machen es sich nicht leicht, ihnen zu helfen. Sie lesen die Richtlinien nicht, vergessen wichtige Informationen, sind manchmal nicht in der Lage, sich gut zu verständigen oder sind ziemlich unhöflich.

Dies ist nicht leicht zu erkennen, wenn Sie sich nur auf kleine Details wie einen einzelnen Problembericht konzentrieren. Es gibt so viele Problemberichte. Viele von ihnen sind alt, schlecht geschrieben, dupliziert und so weiter. Es ist schwer, in diesem Dschungel den Überblick zu behalten.

Viele Menschen haben viele Wünsche und nicht so viele Menschen helfen dem Projekt. Die meisten von ihnen sehen nur ihren Standpunkt und sind nicht daran interessiert, anderen zu helfen. Aber das macht es für ein so kleines Team schwierig, alle Wünsche in einem Zeitplan zu erfüllen, die sie erwarten. Ich kenne kein Open-Source-Helpdesk-Projekt, das ähnlich leistungsfähig ist und in dem so viele gute Leute zusammenarbeiten!

Nur meine zwei Cent ;-)

Wenn etwas komisch klingt, ist das meine Ausrede:
Ich bin kein englischer Muttersprachler und verwende hauptsächlich Deep-Learning-Übersetzungstools wie dieses https://www.deepl.com/translator . Grüße aus Köln (Ja, das ist die große Stadt in Deutschland mit all den Flüchtlingen. Die meisten sind nett, glauben Sie Ihrem Präsidenten nicht. Er ist ein Splitter).

Wenn ich die von solsticesurfer am 3. Oktober notierten Änderungen vornehme, wird das Assign-Popup zu einem weißen leeren Balken/Fenster. Siehe Anhang.

Debian-Buster x64
4.13.13-1

2017-12-05 12_48_01-osticket __ staff control panel

@jonshado Haben sie vorher funktioniert? Wenn ja, dann würde ich sagen, dass du es nicht richtig gemacht hast. Ich führe diesen Patch auf meinem Produktionssystem aus und habe Ihr Ergebnis nicht. Wenn nein, haben Sie ein AJAX-Problem, das nichts mit diesem Patch zu tun hat.

@ntozier
Interessant. Ich habe für jetzt zurückgekehrt, da ich es doppelt überprüft und die Zeilen gemäß dem vorherigen Beitrag, der das Diff zeigt, ordnungsgemäß ersetzt habe. Ich habe die Dateien hier eingefügt.

Wir sind am Freitag live gegangen, daher kommen viele dieser Elemente erst jetzt, während mein Team das System durchforstet.

Ich habe keine anderen Probleme mit dem System, die mir funktional bekannt sind. Wenn ich mir jedoch meine Systeminformationen ansehe, glaube ich nicht, dass ich cgi.fix_pathinfo auf 1 gesetzt habe, obwohl ich dies in der php.ini getan habe.

Ich habe die Systeminformationen, die php.ini und die forms.php, die ich zu bearbeiten versucht habe, eingefügt. Ich suche immer noch nach dem Grund, warum ost die php.ini-Änderungen nicht erkennt.

Serverinformation

osTicket-Version | v1.10.1 (9ae093d) — Aktuell
Webserver-Software | Apache/2.4.29 (Debian)
MySQL-Version | 10.1.29
PHP-Version | 7.0.25-1

gdlib | Wird für Bildbearbeitung und PDF-Druck verwendet
imap | Wird zum Abrufen von E-Mails verwendet
xml | XML-API
xml-dom | Wird für die HTML-E-Mail-Verarbeitung verwendet
json | Verbessert die Leistung beim Erstellen und Verarbeiten von JSON
mbstring | Sehr empfehlenswert für nicht-westeuropäische Sprachinhalte
phar | Sehr empfehlenswert für Plugins und Sprachpakete
intl | Sehr empfehlenswert für nicht-westeuropäische Sprachinhalte
Dateiinfo | Wird verwendet, um Dateitypen für Uploads zu erkennen
APCu | Verbessert die Gesamtleistung
Zend-Opcache | Verbessert die Gesamtleistung

cgi.fix_pathinfo |
Datum.Zeitzone | Amerika/New_York

Schema | osticket_db (localhost)
Verwendeter Speicherplatz | 5,14 MiB
Platz für Anhänge | 0,00 MiB
Zeitzone | EST (Interpretiert als Amerika/New_York)

shared.zip

Nachdem Sie Änderungen an der php.ini vorgenommen haben, müssen Sie Apache neu starten. Hast du das gemacht?

@ntozier Ja, das habe ich. Ich habe das System auch komplett neu gestartet. Es scheint, basierend auf anderen Community-Beiträgen, dass die Warnung im Info-Bereich nicht verschwindet, da die PHP-Installation als Apache-Modul ausgeführt wird, daher glaube ich nicht, dass dies einen Einfluss hat.

Der Rest der Installation scheint funktionsfähig zu sein. Meine Sorge ist, dass diese Fehler verhindern, dass der Cron-Job ordnungsgemäß ausgeführt wird. In meinem Cron-Log steht nichts. Ich werde das Abrufen über das Admin-Panel deaktivieren (also sollte es nur cron sein, um nach E-Mails zu suchen) und hoffentlich werde ich sehen, dass E-Mails aufgenommen werden.

Selbes Problem hier. Konnte nicht herausfinden, was es ist. Aber so kann man wieder mit dem System arbeiten.

/var/www/html/include/class.forms. php: 4339

 function render($staff=true, $title=false, $options=array()) {

//        switch(strtolower($options['template'])) {
//        case 'simple':
            $inc = STAFFINC_DIR . 'templates/dynamic-form-simple.tmpl.php';
//            break;
//        default:
//            throw new Exception(sprintf(__('%s: Unknown template style %s'),
//                        'FormUtils', $options['template']));
//        }

        $form = $this;
        include $inc;
    }

@ossd für mich hatte die Abteilungsübertragung auch das gleiche Problem wie das leere Agentenfenster. Es sieht so aus, als ob derselbe Code wie im Agentenfenster verwendet wurde, also habe ich Ihren Fix auf den Übertragungsabschnitt angewendet und es hat funktioniert.

Ich hoffe nur, dass das sonst nichts kaputt macht!

include/class.forms. php: 4462

function render($staff = true, $title = false, $options = Array()) {

//        switch(strtolower($options['template'])) {
//        case 'simple':
            $inc = STAFFINC_DIR . 'templates/dynamic-form-simple.tmpl.php';
//            break;
//        default:
//            throw new Exception(sprintf(__('%s: Unknown template style %s'),
//                        'FormUtils', $options['template']));
//        }

        $form = $this;
        include $inc;

}

Irgendeine endgültige Lösung für diese Warnungen? Oder kann jemand funktionierenden Patch teilen?

@iprok

Das Problem sollte mit dieser Pull-Anfrage behoben werden, jedoch nur für die 1.11.x Serie. Sie können es gerne auf 1.10.x ausprobieren, aber es _könnte_ etwas kaputt machen (weiß nicht; habe es nicht getestet).

Prost.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen