Hallo,
wenn Google nicht schon wieder etwas geändert hat, dann sollte diese Anleitung funktionieren: https://manual.woltlab.com/de/third-party-logins/#google
Also der Teil für Facebook ist definitiv nicht mehr aktuell
Hallo,
wenn Google nicht schon wieder etwas geändert hat, dann sollte diese Anleitung funktionieren: https://manual.woltlab.com/de/third-party-logins/#google
Also der Teil für Facebook ist definitiv nicht mehr aktuell
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.
Zur Vollständigkeit, falls irgendwann mal jemand auf den gleichen Fehler stößt.
Problem war in unserem Fall die PHP Laufzeit. Wir haben Sie für das Update deutlich erhöht, was für uns zum Erfolg geführt hat.
Vielen Dank an Alexander Ebert
Warum es in der Test-Version ohne Probleme funktioniert hat, wird wohl ein Rätsel bleiben.
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
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?
Alexander Ebert so wie es aussieht, lag es tatsächlich am Expires Header. Konkret an der folgenden Zeile:
ExpiresDefault "access plus 24 hours"
Vielen Dank für den Tipp.
Leider konnte ich keine Empfehlung für die htaccess für WBB5 bzw. Woltlab Suite 3.1 finden. Gibt es dies evtl. und ich habe sie übersehen?
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?
Hallo,
wir haben zahlreiche veraltete Konversationen mit Hilfe von einem Plugin gelöscht und möchten den Suchindex daher neu erstellen.
Wie und wann wird die Tabelle wcf1_conversation_message_search_index befüllt und aktualisiert?
Gibt es dafür eine Anzeigenaktualisierung per CLI oder wird dies mit einer anderen Aktualisierung durchgeführt?
@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
Danke für die Unterstützung und die rasche Problemlösung.
Ich denke, es wäre aber von Vorteil, eine ausführliche Anleitung zur Einrichtung von ElasticSearch anzubieten.
Ich hatte letzte Woche kurzfristig einige Auswärtstermine, daher war das wenig sinnvoll. Ich richte nachher einen SSH Zugang ein und erstelle ein Supportticket.
Wie ist das mit Kategorien?
Hier im Woltlab Community-Forum kann ich die ausblenden aber bei mir im Forum finde ich, wenn ich die Kategorie bearbeite, kein Häkchen "Benutzer können dieses Forum ignorieren" so wie das bei Foren vorhanden ist.
Ich werde morgen einen Zugang einrichten und mich per Support Ticket melden.
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.