Fehler nach Upgrade auf php7

  • Hallo Support,

    nach der Umstellung auf php7 lässt sich unser Burning Board nicht mehr aufrufen.

    Beim Debuggen habe ich zumindest die Stelle gefunden, an der er rausfliegt.
    \wcf\lib\system\database\statement\PreparedStatement.class.php
    Zeile 121: return $this->fetch($type);

    Wenn ich die Zeile in der debug Konsole ausführe, bekomme ich jedoch Werte.
    Leider hab ich noch keine Fehlermeldung gefunden, die darauf hindeuten würde, weder im Apache / php noch im wcf Log.

    Wenn ich zurück auf php5.6 stelle, funktioniert es wie erwartet.

    Habt ihr eine Idee, woran es liegen könnte? Fehlen noch php Module?

    "php -m" liefert die folgenden Werte
    -------------------------------------------
    [PHP Modules]
    calendar
    Core
    ctype
    curl
    date
    dom
    exif
    fileinfo
    filter
    ftp
    gd
    gettext
    hash
    iconv
    json
    libxml
    mbstring
    mcrypt
    mysqli
    mysqlnd
    openssl
    pcntl
    pcre
    PDO
    pdo_mysql
    Phar
    posix
    readline
    Reflection
    session
    shmop
    SimpleXML
    soap
    sockets
    SPL
    standard
    sysvmsg
    sysvsem
    sysvshm
    tokenizer
    wddx
    xdebug
    xml
    xmlreader
    xmlwriter
    xsl
    Zend OPcache
    zip
    zlib


    [Zend Modules]
    Xdebug
    Zend OPcache
    -------------------------------------------

    Beste Grüße
    Michael

  • Ich bin ein Stück weiter aber nur weil ich den Code im WCF ein wenig modifiziert habe. Vielleicht könnt ihr mir ja das Verhalten erklären.

    Es ist immer noch die \wcf\lib\system\database\statement\PreparedStatement.class.php

    Statt der Zeile 121:

    Code
    return $this->fetch($type);

    Habe ich den Code so modifiziert:

    Code
    $x = $this->fetch($type);
    return $x;

    Damit bekomme ich jetzt wenigstens eine Fehlermeldung im wcf log.


    Da habe ich aber noch nichts weiter verändert.


    Dann habe ich die wcf\options.inc.php gelöscht und vom System neu generieren lassen. Leider noch der selbe Fehler.


    Ich habe auch in der Datenbank geschaut aber das ist ein default style gesetzt.


    Inhaltlich habe ich auch keine Veränderung in der Datenbank vorgenommen. Habe mir auch gestern erst den letzten Datenbank dump von unserem Produktivsystem gezogen. Das Produktivsystem läuft in php 5.5


    Wenn ich auf unserem Testserver wieder auf die alte php Version wechsel,

    Code
    sudo a2dismod php7.0; 
    sudo a2enmod php5.6; 
    sudo service apache2 restart

    habe ich diese Probleme nicht.


    Irgendwelche Ideen? Wäre auch schön, wenn es auch ohne Manipulation des Frameworks ginge.

    Beste Grüße
    Michael

  • Mal so ne allgemeine Frage: Hast du mal selbst an der Datenbank etwas geändert ?
    Denn Die fehlermeldung sagt aus dass du keinen standart stil definiert hast was so meines wissens nach gar nicht möglich sein dürfte...

  • Nein, nicht an der Stelle. Lediglich in der wcf Application, der wcf1_session und der wcf1_session_virtual

    Ich hab jetzt aber nochmal von vorne begonnen.
    Ich habe eben gerade einen dump von unserer funktionierenden Produktivdatenbank (php5.5) gezogen und in unser Testsystem (php7.0) eingespielt.
    Das einzige, was ich daran verändert habe, war die domainName und cockieDomain in der wcf Application. Die wcf1_session und wcf1_session_virtual hab ich geleert.
    Mehr habe ich datenbankseitig nicht getan.

    Im Filesystem habe ich folgende Ordner geleert:
    /wcf/templates/compiled
    /wcf/cache
    /wcf/language
    /wcf/acp/templates/compiled

    Jetzt stehe ich aber wieder vor dem ursprünglichen Problem unter php7, dass er in der Klasse \wcf\lib\system\database\statement\PreparedStatement.class.php aussteigt.

    Wenn ich die php Version auf 5.6 wechsel, ist das Forum sofort verfügbar und ich muss nichts anpassen.

    Code
    sudo a2dismod php7.0 ; sudo a2enmod php5.6 ; sudo service apache2 restart


    Wenn ich wieder zurück wechsel, steigt er wieder aus.

    Code
    sudo a2dismod php5.6 ; sudo a2enmod php7.0 ; sudo service apache2 restart

    Also entweder stimmt irgendwas nicht mit der php7 Installation/Konfiguration oder liegt am Burning Board selbst.
    Ich sollte vielleicht dazu sagen, dass auf der gleichen Maschine auch Typo3 und Wordpress Applikationen laufen. Bei denen konnte ich mit php 7.0 noch keine Probleme feststellen.

  • kann ich so ehrlich gesagt nicht nachvollziehen, ich kenn viele Foren die völlig problemlos das wbb mit php7 im einsatz haben.
    Aber lass mal zunächst klären ob du denn wirklich keinen default stil hast oder ob gar mehr als einer eingetragen ist:
    Schau dazu bitte in der Tabelle wcf1_style nach ob du genau einen Stil hast der eine 1 in der Spalte isDefault hast.

  • Morik:
    Ich sage ja nicht, dass ich alles richtig gemacht habe. Deswegen hatte ich auch nochmal von vorne begonnen.
    Den Fehler mit dem fehlenden default Style hatte ich nicht mehr, vermutlich aber nur, weil er schon voher aussteigt.
    Aber ja in der Tabelle wcf1_style sind 4 Einträge und genau ein Eintrag hat eine 1 bei isDefault. Das war auch das Erste, das ich kontrolliert hatte.

    Ich glaube auch nicht, dass der Fehler in der Datenbank liegt, weil ja alles funktioniert, wenn ich die php Version wechsele.

    @MysteryCode:
    Ein Ticket habe ich parallel schon eröffnet. Dachte nur, vielleicht hat in der Community jemand eine Idee.

  • @Sonnenspeer
    Ja, das hatte ich schon versucht. Hat leider nicht geholfen.
    Habe es eben auch nochmal probiert.

    • php5.6
    • cache über backend gelöscht
    • Wechsel zu php7.0
    • nochmal die template, cache und language Ordner geprüft und Dateien gelöscht
    • Seite liefert Fehler
    • Wechsel zu php5.6
    • Seite funktioniert
    • Offizieller Beitrag

    @Finanztip Ich tippe an dieser Stelle auf defekte PHP-Binaries, denn weder mit den Original-Sources von php.net, noch mit den Binaries von dotdeb.org sind derartige Probleme reproduzierbar. Alleine schon die Tatsache, dass man Probleme dadurch umgeht in dem man den Rückgabewert in eine Variable schreibt und diese direkt zurückgibt, ist einfach unsinnig. Ich habe bis jetzt noch nie mit den Binaries von deb.sury.org gearbeitet, würde aber unter dem aktuellen Hintergrund eher zu den dotdeb.org Repositories raten. Die Seite gibt es schon ewig und verfügt über eine ausgezeichnete Reputation, sowohl in Hinblick auf Stabilität als auch Zuverlässigkeit.

    PS: Ich habe jetzt bewusst nicht das Ticket zum antworten genutzt, da mir nicht bekannt ist ob Zugang zum passenden E-Mail-Konto besteht. Gerne kann ich meine Antwort der Vollständigkeit halber zusätzlich ins Ticket übernehmen.

  • Hallo Alexander,

    ja, sowas in der Art vermute ich auch. Wir verwenden die Repositories, die direkt von Ubuntu bereitgestellt werden. Lediglich für den Parallelbetrieb von php 5.6 und 7.0 hab ich das Repository von ondrej hinzugefügt aber es hat auch schon davor nicht funktioniert.

    Ich versuche mich mal da durchzukämpfen. Wenn ich es lösen konnte, werde ich es posten.

    Beste Grüße
    Michael

    P.S. Ich hätte die Ticket Antwort auch lesen können, aber du brauchst es nicht nochmal schicken, die Antwort hab ich ja.

    • Offizieller Beitrag

    Ich versuche mich mal da durchzukämpfen. Wenn ich es lösen konnte, werde ich es posten.

    Es wäre auch denkbar vorerst auf 5.6 zu bleiben und erst mit dem nächsten Point-Release von 7.0 erneut zu wechseln. Wie ich oben bereits beschrieb, ist das Verhalten von PHP vollkommen fehlerhaft und impliziert eine defekte Binary. Wie ich aus der Ausgabe oben entnehmen kann, so wird die xdebug-Erweiterung geladen. Diese ist für den Einsatz in einem Produktivsystem nicht geeignet und sollte deaktiviert werden (am besten auch gar nicht erst geladen).

    P.S. Ich hätte die Ticket Antwort auch lesen können, aber du brauchst es nicht nochmal schicken, die Antwort hab ich ja.

    Ich habe das Ticket erstmal geschlossen. Ich hielt es für sinnvoller dieses Thema direkt weiterzuführen, damit nicht an zwei Stellen die selben Vorgehensweisen erläutert werden und dieses Thema kann auch Dritten mit einem vergleichbaren Problem als Hilfestellung dienen.

  • Wie ich aus der Ausgabe oben entnehmen kann, so wird die xdebug-Erweiterung geladen. Diese ist für den Einsatz in einem Produktivsystem nicht geeignet und sollte deaktiviert werden (am besten auch gar nicht erst geladen).

    Ja, ich weiß. Ist nur das Entwicklungs-/ Testsystem. Auf dem Produktivsystem wird xdebug nicht geladen. Trotzdem danke für den Hinweis.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!