Beiträge von nie-key

    Ich bin soeben über das gleiche Problem gestolpert. Da hebeln sich die Optionen gegenseitig aus. Wenn man bei der Gruppe Jeder die Konversationen komplett deaktiviert, dann ist dieser Bereich zwar ausgegraut - aber wenn man vorab nicht auch noch "neue Konversation starten" auf Nein gesetzt hatte, dann bleibt diese Option auf JA stehen und wird vererbt.

    Wir scheitern aktuell an einem Update von WBB 4.1 auf WSC 3.0.

    In der letzten Woche hatten wir uns ausführlich auf dieses Update vorbereitet. Wir haben das komplette Verzeichnis des Forums in einen anderen Ordner auf dem Webspace kopiert. Dabei haben wir darauf geachtet, dass die chmod Rechte der Ordner und Dateien richtig übernommen wurden. Das war der Fall. Außerdem haben wir die Datenbank kopiert.

    Auf dieser Basis haben wir das Update auf unserer Test-Umgebung mithilfe der Updateserver (vortex) durchgeführt.

    Soweit hat das alles gut funktioniert. Im Anschluss wurde auch ein Update auf 3.1 durchgeführt was ebenfalls gut funktioniert hat.

    Nun zu unserem Problem:

    Um das Forum heute nun tatsächlich auf WSC 3.0 zu bringen haben wir den Wartungsmodus aktiviert und nach gleichem Schema eine weitere Kopie des Original-Verzeichnisses und der originalen Datenbank erstellt.

    Die neue Kopie wirft uns nun - trotz gleichem vorgehen wie in unseren Tests - nach 3 Versuchen jedes mal den selben Fehler (bei 72% des Woltlab Burning Boards):

    include(/kunden/xxxxx/projekte/projekt_wsc3/acp/update_com.woltlab.wbb_5.0_dropColumns.php): failed to open stream: No such file or directory

    include(/kunden/xxxxx/projekte/projekt_wsc3/acp/update_com.woltlab.wbb_5.0_dropColumns.php): failed to open stream: No such file or directory

    Datum

    6. November 2019, 16:09

    Aufgerufene URL

    /acp/index.php?install-package/&t=f14e12580d25909cd82adb32f0bd1a52c1feef28&s=cb710c01138dad66e9e74c8d8bc640964c09a2f3

    Referrer

    https://wsc3.projekt.de/acp/index.php?…bc640964c09a2f3

    Browser

    Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

    Arbeitsspeicher

    1,67 MiB / 1 GiB

    Fehlermeldung

    include(/kunden/xxxxx/projekte/projekt_wsc3/acp/update_com.woltlab.wbb_5.0_dropColumns.php): failed to open stream: No such file or directory

    Art

    wcf\system\exception\ErrorException

    Datei (Zeile)

    /kunden/xxxxx/projekte/projekt_wsc3/wcf/lib/system/WCF.class.php (335)

    Stacktrace

    /kunden/xxxxx/projekte/projekt_wsc3/wcf/lib/system/package/plugin/ScriptPackageInstallationPlugin.class.php (72): wcf\system\WCF::handleError(…)

    /kunden/xxxxx/projekte/projekt_wsc3/wcf/lib/system/package/plugin/ScriptPackageInstallationPlugin.class.php (72): include(…)

    /kunden/xxxxx/projekte/projekt_wsc3/wcf/lib/system/package/plugin/ScriptPackageInstallationPlugin.class.php (50): wcf\system\package\plugin\ScriptPackageInstallationPlugin->run(…)

    /kunden/xxxxx/projekte/projekt_wsc3/wcf/lib/system/package/plugin/AbstractPackageInstallationPlugin.class.php (70): wcf\system\package\plugin\ScriptPackageInstallationPlugin->install(…)

    /kunden/xxxxx/projekte/projekt_wsc3/wcf/lib/system/package/PackageInstallationDispatcher.class.php (603): wcf\system\package\plugin\AbstractPackageInstallationPlugin->update(…)

    /kunden/xxxxx/projekte/projekt_wsc3/wcf/lib/system/package/PackageInstallationDispatcher.class.php (141): wcf\system\package\PackageInstallationDispatcher->executePIP(…)

    /kunden/xxxxx/projekte/projekt_wsc3/wcf/lib/acp/action/InstallPackageAction.class.php (72): wcf\system\package\PackageInstallationDispatcher->install(…)

    /kunden/xxxxx/projekte/projekt_wsc3/wcf/lib/action/AbstractDialogAction.class.php (68): wcf\acp\action\InstallPackageAction->stepInstall(…)

    /kunden/xxxxx/projekte/projekt_wsc3/wcf/lib/action/AbstractAction.class.php (47): wcf\action\AbstractDialogAction->execute(…)

    /kunden/xxxxx/projekte/projekt_wsc3/wcf/lib/system/request/Request.class.php (83): wcf\action\AbstractAction->__run(…)

    /kunden/xxxxx/projekte/projekt_wsc3/wcf/lib/system/request/RequestHandler.class.php (94): wcf\system\request\Request->execute(…)

    /kunden/xxxxx/projekte/projekt_wsc3/acp/index.php (9): wcf\system\request\RequestHandler->handle(…)

    Merkwürdig an der ganzen Sache:

    Die Datei ist zum Zeitpunkt der Fehlermeldung tatsächlich nicht vorhanden.

    Beim 3. Update-Versuch haben wir explizit darauf geachtet ob die Datei im Verlauf des Update-Prozesses verfügbar ist oder nicht.

    Und siehe da. Sie war vorhanden. Wir hatten bereits Hoffnung, dass es dieses mal bis zum Ende durchlaufen könnte.

    Leider wurden wir wieder mit dieser Fehlermeldung konfrontiert. Zum Zeitpunkt der Fehlermeldung war die Datei auch im 3. Versuch nicht mehr vorhanden.

    Die chmod Rechte der Ordner stimmen mit der Originalversion überein, da sind wir uns ganz sicher.

    Die PHP-Version können wir eigentlich auch ausschließen, da es im Test-Verzeichnis der letzten Woche ja reibungslos funktioniert hat.

    Sowohl die originale alte Version, die Test-Version und die neue Version von heute liegen auf dem selben Server und haben die selben Bedingungen.

    Burning Board®-Version: 4.1.21

    Betriebssystem: Linux
    Webserver: Apache/2.4.41
    PHP-Version: 7.0.33
    MySQL-Version: 5.6.19

    Vielleicht haben Marcel Werk und Alexander Ebert hier ja eine Lösung für uns?

    Hallo zusammen,

    ich habe vor einigen Tagen ein Forum von der Version 4.1 auf die 5.1 upgedated.

    Seit dem beschweren sich die Mitglieder darüber, dass sie beim Klick auf einen der Threads in der Box "Letzte Beiträge" (Parameter firstnew) nicht immer an der richtigen Stelle landen. Beim ersten Klick scheint alles Ok zu sein klicken sie jedoch später nochmal darauf dann führt der Link entweder auf die erste Seite oder mitten in den Thread (was noch seltsamer ist).

    Ist dieses Verhalten in irgend einer Form erklärbar oder steuerbar?

    Habe ich vielleicht vergessen, etwas zu aktualisieren oder eine Einstellung falsch gesetzt?

    Danke & Grüße

    nie-key

    Hallo,

    meine User beschweren sich darüber, dass in der Forumsübersicht der Klick auf "zum ersten neuen Beitrag springen" nicht immer funktioniert. Obwohl es mehrere neue Beiträge gab, die auch schon gelesen wurden, landen sie immer auf einem bereits gelesenen Beitrag. Bei mir hat es glaube ich immer gepasst, daher konnte ich das nicht reproduzieren, aber nun habe ich einen Fall, in dem ich auch auf dieses Phänomen stoße.

    Hat jemand eine Idee, an was das liegen kann?

    Auf dem Server existiert nur elasticsearch 2.4.0.

    Ich habe den Fehler soeben gefunden: Damit der Suchindex mit Elasticearch aktualisiert wird, muss CLI mit PHP 7 aufgerufen werden.
    Das Problem hat sich somit erledigt!

    Ich sage trotzdem danke - weil mich die Suche nach der Versionsnummer auf den richtigen Weg gebracht hat.

    @Andrea Berg also irgendwie scheint die Sache mit dem Elastic Search noch nicht ganz rund zu sein. Ich wollte den Suchindex erneut per CLI aktualisieren, jedoch komme ich nicht über 0% hinweg. Das Script läuft über Stunden aber nichts passiert. Auch eine Fehlermeldung ist nicht zu erkennen.

    Die Server-Einstellungen wurden seit unserem letzten Kontakt nicht verändert.

    Irgendwelche Ideen?

    Kosteneinsparung ist jetzt weniger das Thema. Bei uns liegt jedes größere Forum auf einem eigenen Server mit massig Speicherplatz.

    Wir haben über eine Million private Nachrichten, wovon sehr viele schon über 15 Jahre alt sind. Die User sind schon längst nicht mehr aktiv und kein Mensch benötigt diese Nachrichten.
    Bei jedem Update und bei jedem Backup müssen diese Daten mit verarbeitet werden. Wenn dann mal ein Update schief geht (hatten wir neulich bei einem Forum), dann muss man den ganzen unnötigen Kram wieder einspielen und das kostet alles nur jede Menge Zeit und Nerven. Die Ausfallzeit wird dann ebenfalls deutlich länger, was mich am meisten nervt.

    Kurz gesagt: Ich möchte das Forum mit der Löschaktion aller Nachrichten, die älter als 12 Monate alt sind schlanker und flexibler in der Wartung machen.
    Bevor jetzt jemand meckert: Die User wurde schon vor Monaten darüber informiert und hatten Gelegenheit ihre Nachrichten zu sichern.

    Dafür ist die Anzeigenaktualisierung „Konversationsnachrichten aktualisieren” zuständig, wie du auch aus dessen Beschreibung im ACP entnehmen kannst.

    Danke fürs Feedback. Wie du meinem Posting entnehmen kannst, habe ich ja nach CLI gefragt.

    Die entsprechende Anzeigenaktualisierung müsste dort "workerwcf\\system\\worker\\ConversationMessageRebuildDataWorker" heißen, denke ich. Aber dies hat zu keiner Veränderung bei der Tabelle geführt.

    Ich frage mich daher, ob es etwas bringe, wenn ich die Tabelle lösche und dann den Worker nochmal laufen lasse?

    @Andrea Berg wir haben nun schon diverse Updateversuche hinter uns und alle erdenklichen Parameter des Servers, der Datenbank usw. erhöhen lassen. Das Update steigt jedes mal bei 62% mit einem "Gateway Timeout" aus.

    Was passiert bei 62% genau?
    Wir sind langsam mit unserem Latein am Ende und für jegliche Tipps und Ratschläge offen.

    Sofern es eine Möglichkeit gibt, uns gegen Bezahlung unter die Arme zu greifen, soll es auch daran nicht scheitern!

    Hallo zusammen,

    ein Forum mit rund 60.000 Mitglieder und 1 Mio Beiträgen soll von WBB 4.0 auf WBB 4.1 upgedated werden.
    Erfolgt dabei ein Datenimport oder kann dieses Update problemlos im ACP gestartet werden, sobald man die neuen Update-Server hinzufügt?

    Falls ein Datenimport erfolgt:
    Gibt es die Möglichkeit, das Update per CLI zu machen?

    Danke & Grüße

    Alles andere als CLI würde bei uns keinen Sinn machen, @Andrea Berg

    Aber hier gerne nochmal der Beleg, dass keine Fehlermeldung erscheint. Bei 2% springt er zurück zur Konsole ohne eine Meldung auszugeben. Das passiert auch jedes mal, wie man im Screenshot sehen kann.

    In den Logs vom WCF steht ebenfalls nichts - und das gleiche gilt für die Logs von ElasticSearch. Das habe ich soeben nochmal überprüft.